Re: globals
Quoting David N. Welton [EMAIL PROTECTED]: Massimo Manghi wrote: Quoting David N. Welton [EMAIL PROTECTED]: Remember that they are persistent *within the particular instance of Apache* - and since Apache usually runs with several child processes, you can't count on something like a counter working reliably. Persistent in the case of globals in Rivet means that, in one particular child process, a variable will not be deleted between requests. Since it's tied to a system process and not a user, it's not useful for user information. On the other hand, it is useful for things like database handles - you can define a proc to check if it exists, create it if it doesn't, and return it in either case. ok, I'm going to expose my vast ignorance in web programming: what do you mean for 'request' in this context? Apache child processes have no knowledge of concepts as 'session', so when the link (and the 'request' context) between client and server's child process is dropped? ok...to many questions...sorry, but I'm growing eager to understand 'conversational'. Colloquial is something else in english. 'false friends' Something more 'brutal' but effective would be a simple statement of the shift in the meaning of the keyword in connection with the issue of persistence. But what is 'persistence' in Rivet anyway? As described above - at least with regards to 'global'. Writing manuals for software you know intimately is often difficult, because it's hard to imagine what it's like to not know everything about it:-) yes, this is related also the general problem of 'teaching' -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: globals
Quoting David N. Welton [EMAIL PROTECTED]: ok, I'm going to expose my vast ignorance in web programming: what do you mean for 'request' in this context? Apache child processes have no knowledge of concepts as 'session', so when the link (and the 'request' context) between client and server's child process is dropped? A request is one client to server round trip. For example: GET /index.rvt HTTP/1.0 That asks for just that one page, no pictures, nothing else - all that is fetched separately. This looks like an ok description, and has some promising links. http://en.wikipedia.org/wiki/HTTP In any case, that's correct, there is no state unless you create it artificially, by using the session package for instance. thank you, the first part of your explanation made it clear. -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session and DIO Package used with MySql and Oracle
David N. Welton wrote: Arnulf Wiedemann wrote: Am Samstag 14 Januar 2006 16:55 schrieb David N. Welton: [...] Hi David, thanks for the offer to update. I did not hear anything form Karl or Damon. Here are the modified files and one new file: dio_Oracle.tcl Hi, sorry I haven't had the time to chase after this, but could you please re-send those files either as text attachments or diff -u patches? BTW...Karl, Damon? 'DIO' is really your turf, if you wanted to take a few minutes to look at what Arnulf has done. It would be most welcome. I worked out some changes of this code myself in order to get it working with mysql (on a Debian machine) I'm interested in using both packages and if Arnulf is willing to share his work i'm ready provide my own patches and help him doing some new work. regards -- -- Massimo Manghi -- Dipartimento di Biologia Evolutiva e Funzionale -- Università degli Studi di Parma -- Parco Area delle Scienze 11A - 43100 Parma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
coding style rationale
Hi riveters I was looking at the DIO and SESSION packages code more closely than I did before and found out that there are some methods in dio.tcl where Tcl keywords like 'list' and 'array' are replaced and reused as names for simbolic entities like a specific list or array. Reading such code is puzzling but I'm unwilling to think that the fellows who wrote it did it without a good and specific reason. Just out of curiosity someone would explain why it was done this way? thank you -- -- Massimo Manghi -- Dipartimento di Biologia Evolutiva e Funzionale -- Università degli Studi di Parma -- Parco Area delle Scienze 11A - 43100 Parma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: coding style rationale
Damon Courtney wrote:
Do you mean the 'list' and 'array' methods? They were named that
way for two reasons. One, to jive with what ns_tcl was already doing,
and two to jive with what they do and what Tcl'er would expect them
to do based on name.
There was no scientific (or even good) reason other than that. 0-]
Damon
I didn't mean specifically the methods, in that case it does make
sense to call them this way. It became much clearer to me since I read
the word 'jive'
look at this method from dio.tcl (I hope I'm not messing up with the
indentation).
protected method table_check {list {tableVar myTable} {keyVar myKeyfield}} {
upvar 1 $tableVar $tableVar $keyVar $keyVar
set data(-table) $table
set data(-keyfield) $keyfield
::array set data $list
if {[lempty $data(-table)]} {
return -code error -table not specified in DIO object
}
if {[lempty $data(-keyfield)]} {
return -code error -keyfield not specified in DIO object
}
set $tableVar $data(-table)
set $keyVar $data(-keyfield)
}
the 'list' argument is not making anything that one would
expect from the tcl command *list*, it's *a list* placed
as a first argument in the method: as I saw it it made me
think where the hell the braces are?
--
-- Massimo Manghi
-- Dipartimento di Biologia Evolutiva e Funzionale
-- Università degli Studi di Parma
-- Parco Area delle Scienze 11A - 43100 Parma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache child process crashes
Quoting David Welton [EMAIL PROTECTED]: Odd... looks like something to do with removing the namespace, although that could be a false lead. I tried to isolate every possible point where Itcl class deletion is invoked but found no offending object destruction. I put various marker messages in the template: I can only say that the template is parsed to the end and the code in it gets executed, but the child exit procedure gets never invoked by the server process. Again: might it be a sign of an error in the ::request namespace deletion? Should the following line imply that Itcl stuff is involved (but I could not figure out where...) #9 0x422a4bb3 in Itcl_DeleteClass () from /usr/lib/libitcl3.2.so.1 One thing you could do to help track this down is check this out of subversion and use it to create your Apache module: https://svn.apache.org/repos/asf/tcl/rivet/branches/1_0 I'm afraid that my knowledge of svn goes as far as its commands have the same switches and syntax as cvs. Using cvs syntax for svn would do the work in this case? And Rivet doesn't compile on Debian using the autotools because of a macro problem...(I know you are laden by this task too, I'm sorry, I did not intend to overload you with too many things to think of) That's the last 'good' version of Rivet before I added Eckhard Lehmann's Apache 2.0 stuff. Looks like the recent DIO/other stuff changes haven't been back ported though... More work I don't have time for:-( Does the Rivet package for Debian 'unstable' include this 2.0 things? -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: apache child process crashes
David Welton wrote:
On 7/18/06, Massimo Manghi [EMAIL PROTECTED] wrote:
Some more things to try:
Launch apache with the -X flag to put it in single process mode.
I obtained the backtrace running in single process mode.
Keep eliminating code to see if you can get it to crash with less and
less code (and thus an easier test case for me to replicate).
I'm getting close to the target. First of all: I checked
the code in the template is executed from the beginning
up to the last line. The last line in the template puts a message
in the process logfile. This message appears in the log of
every crashed process.
Here is what I found (I hope I don't get too specific)
The line that screws everything up is in a method where various
parts of a page are dynamically generated. The 'modules'
that generate these sections of the page are implemented through
classes which in turn are sourced by a method invoked by the
main template.
I verified that the 'sourcing' of these classes' files
breaks the rivet process (although the code 'per se'
is functioning!).
Let me show you the code snippet.
Commenting out the whole code block makes the child
processes robust as they can get. Commenting the instantiation,
execution and destruction lines breaks apache again.
source[file join $::request::site_root
${fun(filename)}.tcl]
set module [$fun(function_class) #auto $dioObject $sessionStatus]
$module displayModule
$module destroy
It seems that Itcl classes namespace definitions are not properly cleaned up
in this case. I'm trying to see what happens if I force the class definition
to happen in the ::request namespace, not in my class' namespace.
Should the following line imply that Itcl stuff is involved
(but I could not figure out where...)
#9 0x422a4bb3 in Itcl_DeleteClass () from /usr/lib/libitcl3.2.so.1
Could well be... What OS and version are you running on? Debian stable?
yes, precisely.
One thing you could do to help track this down is check this out of
subversion and use it to create your Apache module:
https://svn.apache.org/repos/asf/tcl/rivet/branches/1_0
I'm afraid that my knowledge of svn goes as far as its commands
have the same switches and syntax as cvs. Using cvs syntax for
svn would do the work in this case? And Rivet doesn't compile
on Debian using the autotools because of a macro problem...(I know
you are laden by this task too, I'm sorry, I did not intend
to overload you with too many things to think of)
You want to do:
svn checkout https.. local-rivet-directory-name
Is this Debian unstable/testing then?
no, it's stable. The problem is similar on the laptop running
'testing' but the messages in the log complain about the
child exiting upon a segfault.
--
-- Massimo Manghi
-- Dipartimento di Biologia Evolutiva e Funzionale
-- Università degli Studi di Parma
-- Parco Area delle Scienze 11A - 43100 Parma
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
escape_string in 1_0
I'm using a rivet module obtained by compiling the 1_0 code from repository. I looked in the code for the (un)escape_string commands that are available in the trunk and noticed that their file (rivetWWW.c IIRC) is included in the build process. These commands seem to be unknown to the interpreter anyway. Where did i get it wrong? -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: escape_string in 1_0
Quoting David Welton [EMAIL PROTECTED]: I don't know what happened. I also tried by wiping out the the whole source tree and checking out from repository. I applied that simple patch but ...nope sorry it doesn't compilebut this is not related to your patch, of course. -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: escape_string in 1_0
Quoting Massimo Manghi [EMAIL PROTECTED]: David Welton wrote: You could try adding this patch and see if it works: --- src/mod_rivet.c (revision 449811) +++ src/mod_rivet.c (working copy) @@ -885,6 +885,8 @@ exit(1); } +Rivet_Init(interp); + I managed to recompile the module (I switched from from Debian 3.1 to 4.0). Well, no, it's not working. -- Massimo Manghi This message was sent using IMP, the Internet Messaging Program. Imp3 - Webmail del Dipartimento di Biologia Evolutiva e Funzionale - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build error with Ubuntu Edgy
David Welton wrote: Thanks, but I just changed lib_libexecdir to /usr/lib/rivet0.7.0 by hand and it works fine for me. Yeah... I think it's certainly not %100 correct (obviously!), but it could probably be fixed with some tweaking, without redoing everything. At least for the 1.0 branch... Considering the obvious lack of time what release goals have to be matched in order to make the tweaking of a 1.0 relaese worthwhile? -- -- Massimo Manghi -- Dipartimento di Biologia Evolutiva e Funzionale -- Università degli Studi di Parma -- Parco Area delle Scienze 11A - 43100 Parma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
manipulating http headers with rivet
Hi, I posted a question about the 'headers set' command last week which went unanswered. Although this is against the netiquette I'm so helpless about this problem that I try again (David, if you can pay attention to this I promise I rework and extend another 2 sections of the docs ;-)) I'm not able to get the headers set the way I needed. The problem is simple: 'headers set ' commands seems to have no effect on the actual headers. I looked at the source code for this command but it didn't help: TclWeb_HeaderSet(char *header, char *val, TclWebRequest *req) is simply a wrapper of the proper call to the apache server and it gave me no clue on how to use it. I wrote a trivial rvt page for test htmlhead ? headers set Content-Type application/pdf ? /headbody ? set poster [open Poster.pdf r] fconfigure $poster -translation binary set pdf[read $poster] close $poster puts $pdf ?/body/html the actual headers sent over by the server are ~/www HEAD http://localhost/~manghi/serveposter.rvt 200 OK Connection: close Date: Mon, 19 Feb 2007 11:11:12 GMT Server: Apache/1.3.34 (Debian) Rivet Content-Type: text/html; charset=iso-8859-1 Client-Date: Mon, 19 Feb 2007 11:11:12 GMT Client-Peer: 127.0.0.1:80 Client-Response-Num: 1 which gets the browser confused about what to do with the resource. -- -- Massimo Manghi -- Dipartimento di Biologia Evolutiva e Funzionale -- Università degli Studi di Parma -- Parco Area delle Scienze 11A - 43100 Parma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: manipulating http headers with rivet
Daniel Baker wrote: This command will allow your users' browsers to do estimated download times: headers set Content-Length [file size $fileName] FWIW, my implementations of Content-Disposition have the filename included inside filename=filenamehere.xyz rather than just having the filename as the value of the Content-Disposition field Thank you Daniel, I had fixed the 'Content-Disposition' issue after I found a working example in a PHP programming manual (and it wasn't an easy job to find a manual that cleanly explains the headers programming). The 'Content-Length' header was already ok. Yesterday I started to work on a page to be included in the documentation that recaps the experience I made. -- -- Massimo Manghi -- Dipartimento di Biologia Evolutiva e Funzionale -- Università degli Studi di Parma -- Parco Area delle Scienze 11A - 43100 Parma - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PATCHES: apache2 related patches.
Valery Masiutsin wrote: Hello. One more short patch. I forgot to propagate new variables to src/apache-1/Makefile.am Here is the patch which does that. Regards Valery Thank you Valery, after applying this patch i was able to build rivet for apache-1. I'm going to test it on apache-1.3 and see what happens. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PATCHES: apache2 related patches.
David, did you apply all the patches? I'm not able
to rebuild the module for apache 1 from a clean
checkout. (and in order to get a working 'configure'
i have to rebuild it with aclocal and autoconf)
-- Massimo
On Sun, 9 Sep 2007 19:37:21 +0200, David Welton wrote
Here are fresh patches against trunk.
I've gone ahead and committed them.
4.src/apache-2/mod_rivet.c
Changed a bit Rivet_ParseFileArgString a bit, it fixed segfaults, but
still needs some work.
I've added apr_pool_t pointer to parameters we are passing to function.
I think we should go away from malloc/calloc usage to apr_*
equivalents, (It is a subject to discuss).
Most of the code in the apache 2 mod_rivet.c file is from Eckhard
Lehmann [EMAIL PROTECTED], who did the initial work and then abandoned
it. You should not consider it as something that must be there, or
must work the way it does. You are indeed correct that where
possible you should use either the apr_* functions, or the Tcl
functions (be careful of mixing the two). His code, truth be told,
looks kind of messy - you should investigate what things apr_*
gives you, as well as consider using anything from this that helps out:
http://httpd.apache.org/apreq/
Things like this:
/*
* Rivet_IsRivetFile(char*)
*
* small helper function to get the file type. Returns 1 if
* the file ends with .rvt, 0 otherwise.
*/
static int
Rivet_IsRivetFile (char *filepath)
{
char *fileCopy = (char*) malloc((strlen(filepath)+1) *
sizeof(char));char *cPtr;
strcpy (fileCopy, filepath);
cPtr = fileCopy + (strlen(fileCopy) - 3);
if (*(cPtr-1) != '.') {
char *ePtr = fileCopy + (strlen(fileCopy) - 1);
while (*ePtr-- != '?')
;
ePtr++;
*ePtr = '\0';
cPtr = ePtr - 3;
}
if (strcmp (cPtr, rvt) == 0) {
return RIVET_FILE;
}
else if (strcmp (cPtr, tcl) == 0) {
return TCL_FILE;
}
return 0;
}
Just look a bit dodgy to me. In Rivet for Apache 1.3, these things
are handled by Apache, as they should be:
AddType application/x-httpd-rivet .rvt
AddType application/x-rivet-tcl .tcl
Of course, maybe I'm missing something, but... I'm just saying - feel
*very* free to improve things as you see fit!
Module successfully builds on OpenBSD and Debian for me, it is able
to puts bHello Worldb , still there's a lot of work left.
Cool!
--
David N. Welton
http://www.welton.it/davidw/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Universita' degli Studi di Parma (http://www.unipr.it)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: more patches for rivet
I can't commit because I'm forbidden to do so. Before you ask: ** my working copy was checked out with https **, so it's not that simple. I googled part of the error message svn: MKACTIVITY of '/repos/asf/!svn/act/5ad899cc-883a-4609-bf57-9362e65411d4': 403 Forbidden (https://svn.apache.org) and found out that this problem is common for the apache committers. A thread in the developers list of a project called 'tuscany' doesn't explain why but suggest that some people (project managers?) can or even must do something to enable a commiter. Check this 3 message long thread http://www.mail-archive.com/[EMAIL PROTECTED]/msg19286.html -- Massimo On Tue, 18 Sep 2007 19:17:23 +0200, David Welton wrote I'm going to commit soon. David, do you think that the version of the docs in 1_0 can be merged with that in trunk? For what I know there is no 1_0 specific documentation there. Going from 1_0 to trunk is generally ok as long as it's not reverting something. Be more careful about moving something from trunk to 1_0, as 1_0 ought to be more or less 'releasable'. -- David N. Welton http://www.welton.it/davidw/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more patches for rivet
David Welton wrote: svn: MKACTIVITY of '/repos/asf/!svn/act/5ad899cc-883a-4609-bf57-9362e65411d4': 403 Forbidden (https://svn.apache.org) and found out that this problem is common for the apache committers. A thread in the developers list of a project called 'tuscany' doesn't explain why but suggest that some people (project managers?) can or even must do something to enable a commiter. Check this 3 message long thread http://www.mail-archive.com/[EMAIL PROTECTED]/msg19286.html Oops, my fault - sorry about that, but it's been a while since we've added anyone - try now. it's ok now , the commit succeeded. Thank you. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
branch 1_0 development status
Hi Folks
I've been working a bit on what seemed to me a bug at first
(we discussed on the list this problem about one year ago).
Some of the documented commands of rivet ('[un]escape_string'
and others) where not available to the interpreter.
A close look at the code shows that librivet.so (which has
the functions for these commands) was not meant to be a
shared library linked to mod_rivet.so but a full fledged
Tcl package that can be yanked in by tcl scripts with the
usual 'package require' command.
The package name is 'Rivet'. It looks to me an arguable choice
unless the authors had in mind some sort of major reorganization
of the rivet commands. 'Rivet' (the package) provides 2 other
(undocumented ?) sets of commands: a simple cryptographic
system (a data obfuscation method ?) and a set of improved
list objects manipulation methods inspired by Tclx.
I don't even know if the code for these module is tested.
To say the least a minimal documentation for these commands
is needed and the current documentation should be updated
for those commands that need a 'package require Rivet' in order
to be available. I can do it, but I was wondering what the
authors had in mind: continuing the pursuit of their goals
would probably be a good option and could be part of the work
we are doing
My opinion is that coming up with a 1_0 release that
compiles only for apache1.x is not a option anymore.
Apache2 has been out for too long now and we have to
continue the development. Nonetheless having a 1_0
with complete documentation, a good code structure
and build system could help the work in trunk.
looking forward to read your opinion
regards
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: branch 1_0 development status
David Welton wrote: The package name is 'Rivet'. It looks to me an arguable choice unless the authors had in mind some sort of major reorganization of the rivet commands. 'Rivet' (the package) provides 2 other (undocumented ?) sets of commands: a simple cryptographic system (a data obfuscation method ?) and a set of improved list objects manipulation methods inspired by Tclx. I don't even know if the code for these module is tested. As far as I'm concerned, you can change the name. If anyone squawks, we'll know that they didn't like it. But they should probably be on this list in any case... Rivetlib! At one point in time, my idea was a minimalistic core, with lots of readily available extensions. I don't think that's the wisest course of action these days. Who cares about saving a few bytes. yes, I agree My opinion is that coming up with a 1_0 release that compiles only for apache1.x is not a option anymore. I think that's a sensible point of view. It would look a little bit ridiculous. Let's call it 2.0 :-) you've been selling used cars lately! :-) Rivet0.6 for apache1, Rivet2 for apache2, Rivet2 for apache1:- what an headache! It sounds ridiculous but I thought of the same thing. After all it makes life easier to whom have to pick the right version of the module...let put it in this way -- Massimo -- M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rivet tcl auto_path
I believe the answer to this question must be found
in the way extensions are loaded by tcl. The problem
still exists in various cases:
- for developers wanting to have more rivet installations
to switch from a module version to another without
reinstalling the whole set of libraries (the current scripts
in 'trunk' copy everything in /usr/lib/rivet and don't handle
this case)
- It might also be a problem for users who compile
and install the module on their own if they don't remove
a previous release's directory.
-- Massimo
Massimo Manghi wrote:
Hi,
what is the way by which the module understands where
the tcl code is located? I'm trying to figure out
how the module determines the path to the init.tcl
script when calling
if (Tcl_PkgRequire(interp, RivetTcl, 1.1, 1)) {
...
}
For example: on my system the 1_0 is labeled as 0.7.0
in configure.ac, still after apache is started
auto_path had /usr/lib/rivet0.5.0 (from another installation).
Since I found no erroneous references to that version
number in the code I simply wiped out the /usr/lib/rivet0.5.0
directory, restared apacheet voila...the /src/lib/rivet0.7.0
got into the auto_path. Is it a magic of Tcl_PkgRequire?
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: rivet tcl auto_path
Valery Masiutsin wrote: Hello, Massimo ! If you are runing different versions of rivet simultaneously, and they keep same versions of packages inside auto_path, you have to either change their numbering and go with strict 'package require blah version' (on Tcl or on C level does not matter), or you have to do some tricks with auto_path to exclude pathes searching of which could cause the problem. Regards Valery. Yes, like inserting the specific path as first element in auto_path, which is done by init.tcl, which is in /usr/lib/rivetx.x.x/ . It fetches the directory name from the directory where it was placed. If this is wrong the whole set of rivet commands have the wrong rivet directory in auto_path. Removing the package version from the directory name from the code in 'trunk' might have been a way to cope with this problem (anyone out there can recall why?), but raises a problem in the 2 cases I described. A possible way to get around this might be manipulating auto_path at the C level before init.tcl is run. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in load_response.tcl?
Cristian wrote: Hi, I see that the actual implementation of load_response.tcl produces a increasingly nested list when parsing multiple values for a given key. I've corrected this by changing it to use concat instead of list (diff attached to be run in rivet/rivet-tcl/). I also saw that no test files were present for this command, so I wrote them too (attached load_response.rvt and load_response.test to be copied in tests/). the load_response problem was discussed last February. IIRC David explained that changing this function in that way would have some side effects in case list valued parameters are passed to the server (see the list archives). Still I need something different and I wrote a 'load_response' method in the root class of my pages that overrides in the rivet standard proc. This method is the library function modified in the very same way you did. For tcltest I can't help: my ignorance about this package is vast. -- Massimo When running the tests, it was quite annoying that the results from previous tests was shown when a regexp didn't match. So I included set match all over the place, so now it is more clear that the regexp didn't match. I attached the diff also ( tests.diff to be applied in tests/). When time allows, I will be checking the other commands and their tests. Till now all the I18n tests fail on my utf-8 encoding system. Could someone check this and commit if it applies? Thanks. Cristian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bug in load_response.tcl?
Cristian wrote:
Hi massimo,
I finaly found the archives by googling for rivet-dev and archive. It
is even searchable! Will check there in the future before posting...
So if I understand it correctly, wouldn't the following solve the problem?
i suspect the answer depends on what you expect from load_response.
I can understand from the archive is that the debate was not only about
load_response per se, but how everyone expected to use it to suit their
approach to the problem.
A strong point was that load_response is taken from NeoWebScript,
a Tcl based web development tool which could be already familiar to
the a new Rivet user and it wouldn't make sense to confuse him/her.
Having many procs that make the same job in a different way would
be a possible solution (indroducing switches like -opt1 -opt2 received
little appreciation)
proc load_response {{arrayName response}} {
upvar 1 $arrayName response
array set response {}
foreach {var elem} [var all] {
if {[info exists response($var)]} {
set response($var) [lappend response($var) [list $elem]]
} else {
set response($var) [list $elem]
}
}
}
In my personal case your code would work, but as I said, this is
only the way in which I used load_response.
I made a test feeding your code and the code in Rivet with a series
of list valued elements and the output is radically different.
Cristian's:
for {set i 0} {$i10} {incr i} { if {[info exists lista]} { set lista
[lappend lista [list elemento $i]] } else { set lista [list elemento $i] }}
the first element is treated as a 2 elements list whereas the others are
nested lists appended as sibling elements
Rivet's:
for {set i 0} {$i10} {incr i} { if {[info exists lista]} { set lista
[list $lista [list elemento $i]] } else { set lista [list elemento $i] }}
the output in 'lista' is a series of deeply nested elements...
file load_response_test.rvt:
---
load_response
if { [ array exists response ] } {
foreach { ck } [ array names response ] {
puts response($ck) = $response($ck)\n
}
}
---
which for a
http://localhost:8081/load_response_test.rvt?foo=bar+bazfee=batfoo=bak
http://localhost:8081/load_response_test.rvt?foo=bar+bazfee=batfoo=bak
produces:
response(fee) = bat
response(foo) = {bar baz} bak
Or will the load_response proc be deleted from the sources?
Cristian
I think the answer to the last question is negative, this would break
the code and
it wouldn't be a sensible approach to the problem.
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rivet docs
Comprehensive patch that fixes a couple of spelling errors, changes the front page and expands the description of 'load_response'. I will commit 'load_response' (the procedure) when i commit the docs also. -- Massimo Index: rivet.xml === --- rivet.xml (revision 584150) +++ rivet.xml (working copy) @@ -37,6 +37,9 @@ year2002/year year2003/year year2004/year + year2005/year + year2006/year + year2007/year holderApache Software Foundation/holder /copyright author @@ -49,11 +52,11 @@ /affiliation /author /articleinfo - para + !--para This document is also available in the following languages: ulink url=index.it.htmlItalian/ulink, ulink url=index.ru.htmlRussian/ulink - /para + /para-- para Document revision: $Revision$, last modified $Date$ by $Author$. @@ -914,7 +917,21 @@ refsect1 titleDescription/title Load any form variables passed to this page into an - array. + array. If commandload_response/command is called without + arguments the array optionresponse/option is created in + the scope of the caller. If the variables var1,var2,var3... + having values val1,val2,val3... are passed to the page, the + resulting array will be a collection mapping var1,var2,var3... + to their corresponding values. commandload_response/command + was inspired by the same NeoWebScript procedure in the way + it deals with multiple assignments: if a variable + is assigned more than once the corresponding array element will be a + list of the values for the variable. This can be useful in the case + of forms with checkbox options that are given the same name. + Calling commandload_response/command several times for the same + array results in adding more values to the array at every call. + When needed it is left to the caller to empty the array between + two subsequent calls. /refsect1 /refentry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacement of Rivet_IsRivetFile patch
Valery Masiutsin wrote: Hello, guys ! Here is small patch which replaces questionable (ugly ?) Rivet_IsRivetFile function, with cleaner equivalent. It compiles fine for me. Please review and test. Regards Valery. Hi Valery, your patch looks more than reasonable. If the association between .tcl/.rvt and the 'content_type' header is correctly done by the server (through the module conf), I don't see why we should check the file type in the empirical way Rivet has done so far. The question is, as usual, for the people who know the history of the module: is there any tricky reason (that we may be overlooking) for adopting the basic method of scanning the whole file name in order to extract the file type? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacement of Rivet_IsRivetFile patch
a quick test of the patch didn't work to me. An .rvt file is passed verbatim to the client. I enabled the debug message you had introduced and then commented out. fprintf(stderr, content_type: %s\n, req-content_type); fflush(stderr); in apache2/error.log the server keeps printing content_type: (null) rivet.conf in /etc/apache2/mods-available/ is IfModule mod_rivet.c AddType application/x-httpd-rivet .rvt AddType application/x-rivet-tcl .tcl RivetServerConf ChildInitScript source /home/manghi/www/webdev/childinit.tcl RivetServerConf ChildExitScript source /home/manghi/www/webdev/childexit.tcl /IfModule -- Massimo Valery Masiutsin wrote: Hello, guys ! Updated version of patch. 1.Added one more check inside the Rivet_CheckType function (When file does not exist req-content_type is NULL, well at least i hope so, we have to check for NULL, before trying to do dereference). 2.Corrected file existence check in Rivet_SendContent Regards Valery. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Replacement of Rivet_IsRivetFile patch
Hi Valery, I found out that my apache2 had a problem with the conf files. Actually the former check for the rivet files kept the problem submerged. If you didn't change it I would not realized it. Rivet is working on apache2 now and, as a matter of fact, i was able to run the whole site I developed some time ago for my department. It seemed to work fine. good job Valery, ciao -- Massimo On Tue, 16 Oct 2007 14:17:41 +0300, Valery Masiutsin wrote Hello, guys ! Updated version of patch. 1.Added one more check inside the Rivet_CheckType function (When file does not exist req-content_type is NULL, well at least i hope so, we have to check for NULL, before trying to do dereference). 2.Corrected file existence check in Rivet_SendContent Regards Valery. -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fresh patches (Rivet_IsRivetFile patch included)
Valery Masiutsin wrote: Hello,guys ! Here's more patches. 1.doc_Makefile_am.diff - simple oneliner fixes make clean in docs. 2.src_apache-2_Makefile_am.diff Fixes includes, otherwise macros expansion breakes, ApacheRequest_upload is a good example, it compiles fine but you are getting undefined symbol once you are calling it. N.B. probably mod_rivet for apache-1 in trunk suffers this as well, need to check. Would you tell me more about this? Your patch is doing this change -INCLUDES = [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ +INCLUDES = -I. [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ I can see the -I . switch during the compilation process for every file (I presume this is a byproduct of automake) I've deleted Rivet_ParseUri function - dont see much sense in its existence at this moment - it's broken anyway. Added ap_chdir_file function implementation for apache2 - did not reinvent the wheel, and grabbed it from mod_ruby, we can rewrite it if ap_chdir_file was simply commented out (why?). In fact I noticed yesterday that some pages that had nested templates in them were broken. Printing the output of 'pwd' showed that templates were stuck to the documentRoot it needs so, or include it as it is, with clearly marked credits. I don't see why we should keep it. 5.src_apache-2_apache_request_h.diff Changed prototype of ApacheRequest_tmpfile function to return apr_file_t instead of FILE, also modified ApacheUpload structure - did same change. ok 6. src_apache-2_apache_request_c.diff Completely rewrote ApacheRequest_tmpfile function using apr functions, questionable part is a filename generation for tmp files. Next some changes to ApacheRequest_parse_multipart (enough to make it work). Ideas were taken from apache module book. BB? (Bucket Brigade) Are you already doing it? 7.src_apache-2_TclWebapache_c.diff Rewrote TclWeb_UploadSave function - i did not found the way to get fileno() handler from apr_file_t() so i replaced all stuff with single apr_file_copy() function, which just copies file from tmp to target one, probably need to add here checks for maxsize and UploadDirectory. Because of changes ApacheUpload* stuff i had to do some typecasting on functions in TclWebapache.c - just to repair the build, they are not usable at the moment. With all this i was able to perform file upload using doc/examples/upload* pages. My intension is to leave function interface in TclWebapache as it is for apache2, but all internals probably will be rewritten using apr_* functions equivalents. Apache/apr community insists that they are cross-platform safe, may be they right, but anyway it will simplify things a good bit. All comments are welcome. Regards Valery. I'm adding a small patch for a macro in configure.ac (a simple message to be printed for the apxs program found) I've done a fresh checkout to try the build system (as it would be now for a newcomer) and found out that lib_libexec in src/Makefile.am is expanded into '/usr/lib /rivet' (please note the space char between '/usr/lib' and '/rivet'). This breaks the installation of librivet, but it seems that I'm the only person who is having this problem (I can handle it only hacking the Makefile by hand, a humbling experience) -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fresh patches (Rivet_IsRivetFile patch included)
David Welton wrote: ap_chdir_file was simply commented out (why?). In fact I noticed yesterday that some pages that had nested templates in them were broken. Printing the output of 'pwd' showed that templates were stuck to the documentRoot Keep in mind that there are also Tcl_ functions, but mixing them can be dangerous. My test was at the Tcl level in a .rvt file. Do you refer to the ap_chdir_file call? In mod_rivet.c there are lots of calls to both ap_ and Tcl_. For what I can say there is no obvious overlapping in the way mod_rivet uses these 2 libraries. But my opinion should be matched to Valery's opinion. Yes, you are on the right track. Any OS level stuff should be done through either the apr_ or the Tcl api's. apr_ and Tcl_ give you a lot of functionality, so it's often wise to look there prior to doing something 'by hand'. Massimo - do you have the time to commit Valery's patches? yes, I'll do it soon. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fresh patches (Rivet_IsRivetFile patch included)
In this case we should include the copyright notice in mod_rivet.c (after ASF copyright notice, I presume) -- M Valery Masiutsin wrote: Hello, David ! On 10/18/07, David Welton [EMAIL PROTECTED] wrote: What's the license for mod_ruby? As far as i see from source code it is a BSD-like licence. Here it is. The apachereq bits is under apache-2.0 licence. -- /* * $Id: apachelib.c 93 2005-08-03 01:32:41Z shugo $ * Copyright (C) 2000 ZetaBITS, Inc. * Copyright (C) 2000 Information-technology Promotion Agency, Japan * Copyright (C) 2001-2003 Shugo Maeda [EMAIL PROTECTED] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fresh patches (Rivet_IsRivetFile patch included)
Valery Masiutsin wrote: Hello, Massimo ! The story with ap_chdir_file is that it was considered useless by apache (2 version) developers, and declined. I grabbed a look into mod_ruby and mod_python source code to find out how did they sorted the issue with its absence. I found that they wrote their own implementation of ap_chdir_file for apache2, licence allow us to re-use that code. I think it should be moved to separate file with full text of original licence, and included by preprocessor if its needed. ok, I see now. Is there anything we can do using apache2 infrastructure? Hooking into the 'translate_name' phase? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fresh patches (Rivet_IsRivetFile patch included)
David Welton wrote: Massimo - do you have the time to commit Valery's patches? I'm going to commit. I bumped up the version in AC_INIT because trunk was behind 1_0 and it didn't make sense. I also reestablished the version number in the target directory of the libraries. I didn't ask permission from the list in order to limit the traffic which is unusually high for rivet-dev ( wow :-) ) and because it seems to me reasonable if one has more the one rivet version around in the system. I also fixed a message in configure.ac. The commit is taking place soon. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tests in test directory
It also may help to keep the development of the apache-1 and apache-2 together, at least to fix their behavior in well defined common tests as long as we imagine the 2 modules as providing the same functionalities in 2 different webservers. After all is this what we want? Having just apache-2 to take care of would give much more freedom to the development and simplify the tests. David, you're the policy maker here, what do you think? Maybe 1_0 is stable enough to be the final release for apache1.x? -- Massimo On Fri, 19 Oct 2007 19:22:07 +0300, Valery Masiutsin wrote Hello, guys ! During the next week i'll try to concentrate my attention on tcl/rvt test scripts that could be found in tests directory. First of all it needs to be tuned for apache 2 support, after that i'll need to revue the scripts, probably add a number of new ones. The purpose of this is to create some sort of automated suite which will allow us to test different aspects of rivet2 module. And will clear show up what does not work, and will make easy to catch up regressions. All thoughts on this topic are welcome. Regards Valery -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tests in test directory
Hi Valery, As usual your opinions exhibit strong points. I accept your point of view if Rivet must have new and absolutely necessary features that are missing now and for which we don't have any other option except for bringing them into a future architecture. I mean feature for the application level For this development we may add new features for the apache1.x module developing in pure Tcl or use the strategy of encapsulating them into packages (like in the package Rivet that maybe should be renamed as Rivetlib) At that level adding more feature to the 1_0 should be easy. Valery Masiutsin wrote: Hello, Massimo ! I disagree. I think we should support apache-1.3.x version, as long as it will be used. And it will be used, because apache-1.3.x is the only version of apache that has been properly audited for security holes, and spent enough time in world wide production to be considered sort of reliable. I have nothing against neither apache2, nor by against folks who are using or developing it but here is my short list of contras: -- first and most important - apache2 is a bad known by its api changes which break backward compatibility with in apache2 itself, just recall apache 2.0 - apache 2.2 switch. this is sad, but we have to put up with it. -- second introduction of this threading stuff - very questionable from my point of view, of course there are some benefits on platforms with expensive process creation, but on unix - it just makes things much more complicated, threading support varies between different common unixes greatly. this looks like the focal point of every future development. Threads were on the heap years ago and now everybody seem to have fallen out with them. Even though I still like the concept I won't make any advocacy, lest a war of religion would break out ;-) What i am thinking about is to make rivet so called apr-centric not apache-centric - most of action code should be redone using apr and tcl functions and made apache independent, leaving apache dependent bits as thin as it will be possible. IMHO 2.0-2.2 apache API breakage was not the last one :) I dont want to be dependant on it in the future. seriously this can happen again? Maybe Rivet made the right thing: pausing the development and waiting for Apache3.0 :-) ciao -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning
David Welton wrote: As I already told David, I'd like if we started to think about a planning of the project (as Valery suggested some weeks ago) That would give me a chance to concentrate myself on some aspects or modules and maybe be productive. What is there to plan, really? Some coordination is necessary, such as I'm going to be working on this file today, but aside from architectural questions, Rivet needs doing rather than planning, IMO:-) something like that is already a form of planning, but we should do things to make rivet work also keeping the architectural problems in mind (when possible): the more we can reuse in the future the better is. -- M - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chdir
David Welton wrote: Hi, I just wanted to add a note about chdir. The reason it's not in the apr_ stuff is that Apache 2 has the potential to be run 'threaded' - which means that having a cwd is not really possible. However... I think that it's better to get something working rather than worrying about it being perfect - that's the big mistake I made with Apache 2 in the past, worrying about all the threading stuff instead of getting something working and then improving it. Do keep it in mind as something to work on in the future, though. I hope I'm not being rebuked too hard by David for having wasted time trying to understand how to approach this problem in a new way: I was simply doing some practice in order to get familiar with this stuff. Yesterday night I was playing around with the request_rec fields. I could not figure out in what cases the 'filename' and 'canonical_filename' are different... Apache2 docs simply say that 'filename' gets canonicalized into 'canonical_filename' if they don't match. I thought they could be different when a URI makes a reference to an alias or the path contains a reference to an aliased directory but I always get the real file path for both fields. My attempt was seeking to understand if we could use Tcl_ calls in order to extract the full path to the current page, put this information into the TclWebRequest and use it later on in the 'parse' and 'source' commands. Just for the benefit of the time when the problem will be addressed in our original way. I wrote this message as a future reference for that day... -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
rivetlib, directory config and exit handler
First of all I apologize for this lengthy message but I stacked quite a few things to talk about. I've been working on a few problems that I thought had to be fixed or at least tested. I want to make public on the list what I'm doing, before I pursue goals that are not shared or maybe are being addressed by Valery independently. I've already expressed my opinion about rivet's tcl procedures: I think they should end up in a directory specific to a release following the scheme already adopted in 1_0: ie to append the version number as suffix to the target directory. The advantages are clear if someone (like me) is running 2 instances of apache. I patched configure.ac and Makefile.am for this purpose: the install mechanism is working as expected and a new preprocessor symbol (RIVETLIB_DESTDIR) with the target directory gets defined in config.h, but what is the most proper way for telling Tcl_PkgRequire to load the right init.tcl? Manipulating 'auto_path' in Rivet_PerInterpInit prepending RIVETLIB_DESTDIR as first element in the list before 'package requiring' Rivetlib would make unnecessary doing it at the Tcl level in Rivetlib::Init. The only other method I can imagine is to run Tcl_EvalFile on the init.tcl using the preprocessor macro to determine the path. The more I think of this the less I like it. David I'm sure you have thoughts about this. Rivet_GetConf had lines of code for merging server and directory configurations. It shouldn't. Actually the merge code was shunned away by an unconditioned 'return' but anyway for the merging Apache has its own methods defined in the module descriptor. I commented away the spurious code and tested the merging on a few page. It seems to work. I tried also to reintroduce the exit handler which was excluded. I think the child handler has a bug when called upon child exit: in fact as Jeff Hobbs highlighted on this list in the past, interpreters must be deleted before Tcl_Finalize is called. I'm testing this patch and I had no crashes for now. again sorry for the bulky message. Have a nice weekend. -- Massimo -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: rivetlib, directory config and exit handler
Valery Masiutsin wrote: Hello, Massimo ! Hm would you like to point me to the conversations about exit handlers ? How much time ago that was happened ? December 2005 http://mail-archives.apache.org/mod_mbox/tcl-rivet-dev/200512.mbox/browser I am working on replacing libapreq bits with their libapreq2 equivalents now (apache_* files), API has been changed significantly (totally ?), so i presume it will take another week or even two. BTW those tests helped me a lot. Regards Valery I ask you for change to point me to the stuff about apreq2: I see only apreq_* calls in the docs I found on apache.org, no apache_* files. ciao -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: structured command synopsis
On Fri, 9 Nov 2007 12:11:33 +0100, David Welton wrote Hrm... I see what you're trying to do... that would match a lot of the Tcl docs. However, if it looks difficult, it probably is, and docbook is something you can easily waste days with if you're not careful. I'd just add a note somewhere prominent saying You must require the Rivet package with this command in order to gain access to these commands, or something like that. I used the note.../note element to mark up the warning. 'note' nicely indents the paragraph and puts an icon next to it. I also made small changes to some paragraph in the 'examples and usage' section. I won't send the patch on the list because the changes are small and clear I think. I'm committing soon if no objection is raised. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: structured command synopsis
On Fri, 9 Nov 2007 12:11:33 +0100, David Welton wrote Hrm... I see what you're trying to do... that would match a lot of the Tcl docs. However, if it looks difficult, it probably is, and docbook is something you can easily waste days with if you're not careful. I'd just add a note somewhere prominent saying You must require the Rivet package with this command in order to gain access to these commands, or something like that. I used the note.../note element to mark up the warning. 'note' nicely indents the paragraph and puts an icon next to it. I also made small changes to some paragraph in the 'examples and usage' section. I won't send the patch on the list because the changes are small and clear I think. I'm committing soon if no objection is raised. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rivet Tcl stuff removal and other issues
On Sun, 30 Dec 2007 17:31:43 +0100, David Welton wrote I know that putting this question I'm maybe destroying the residual reputation I have: what is 'ab'? It stands for 'apache benchmark', and the man page should be available with 'man ab'. You can use it to measure performance, but also to pound on a server a little bit. Wonderful, a meaningful name. It recalls the old joke about the VAX/VMS programmer who wanted his brain to be partially removed because he wanted to become an IBM mainframe programmer: by the late '80s that was the job where the money was. But the surgeons went a bit too further removing his brain and when he came out of the surgery he spoke like this Grep! awk bc! cc... happy new year to you guys. -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Timestamps in environment and 'server' array
Fixed the timestamps for DATE_LOCAL and DATE_GMT in apache-2/TclWebapache.c. The values of server(RIVET_DIR) and server(RIVET_INIT) have been fixed. I couldn't fix SERVER_CONF though and for what I can see from the docs and httpd.h, the apache server configuration filename isn't stored anymore in server_rec. I will check whether it can be found in one of the configuration records. I have to suspend my work on Rivet for the next 3-4 days, but I will stay tuned on the list. bye -- Massimo Index: src/apache-2/TclWebapache.c === --- src/apache-2/TclWebapache.c (revision 609225) +++ src/apache-2/TclWebapache.c (working copy) @@ -347,7 +347,7 @@ apr_table_t *table = req-req-subprocess_env; char *timefmt = DEFAULT_TIME_FORMAT; char *t; -time_t date = req-req-request_time; +apr_time_t date = req-req-request_time; #ifndef WIN32 struct passwd *pw; #endif /* ndef WIN32 */ Index: src/apache-2/mod_rivet.h === --- src/apache-2/mod_rivet.h(revision 609225) +++ src/apache-2/mod_rivet.h(working copy) @@ -7,9 +7,10 @@ #include TclWeb.h /* init.tcl file relative to the server root directory */ -#define RIVET_DIR rivet -#define RIVET_INIT RIVET_DIR/init.tcl +#define RIVET_DIR RIVETLIB_DESTDIR +#define RIVET_INIT RIVETLIB_DESTDIR/init.tcl + #if 0 #define FILEDEBUGINFO fprintf(stderr, Function __FUNCTION__ \n) #else -- Universita' degli Studi di Parma (http://www.unipr.it) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error installing rivet_0.4.0-1
On Tue, 05 Feb 2008 00:58:47 -0500, Tom Brown wrote I am configuring a web server on Slackware 12.0 which comes with Apache 2.x. Since Rivet 2.0 isn't quite ready, I compiled Apache 1.3.41 from source. Now I'm attempting to install rivet_0.4.0-1. When I run ./configure.tcl in /home/myname/tcl-rivet/src/, I get the following: Error in CFLAGS test: can't read TCL_EXTRA_CFLAGS: no such variable The error prevents me from running make.tcl. I Googled the error and got old changelogs and cvs submissions from the Rivet dev list of days past, plus a lot Mac/Darwin related stuff, but nothing which seems relevant. Any ideas on how to overcome this? Tom I would suggest that you check out the version in svn and build it yourself using the autotools based scripts svn co http://svn.apache.org/repos/asf/tcl/rivet/trunk rivet A typical build starting from a fresh working copy could be aclocal autoreconf ./configure --with-apache=/usr --with-apache-version=1 --with-tcl=/usr/lib/tcl8.4 there are more parameters for specifying where libapr headers reside and where your apxs binary is located. Rivet works with tcl 8.4, but I can't think of fundamental incompatibilities with 8.5 (David am i getting it wrong?) -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: outputting .rvt file
On Sat, 23 Feb 2008 16:02:30 -0800 (PST), crouzilles wrote Hi all, How do I output a .rvt file to the browser via TCL. I obviously need it to be parsed first, but I can't figure out how to send the .rvt file to the browser once the TCL has finished doing what it has to do. Thank you Just a question to clarify the problem: why don't you simply let apache parse and transmit the rvt file to the browser? If you properly configured apache using the 'AddType application/x-httpd-rivet .rvt' you should get it right. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache Notes table, Apache tables in general, and Rivet
Beside cgi environment I can't see a real difference
between 'notes' and 'subprocess_env', thus I can't make up
an opinion about what is preferable. I can understand
that 'notes' is free from the burden of supporting
various things related to cgi, but that's all. Do
you think your code is already at the stage to be tested?
-- Massimo
On Thu, 3 Apr 2008 11:40:01 -0500, Karl Lehenbauer wrote
There's a key-value Apache table called notes that's part of
request_rec structure.
It's used to communicate various stuff between modules.
We came across a need to be able to interface to it from Tcl. We
want to stuff the authenticated username into Apache logs using the
% {varname}n option of CustomLog formatting. To do that we'd stuff
a note with the username and then invoke that note's name in the log.
There are various bits of code to interface to certain tables
defined in the request_rec: headers_in, headers_out, and
err_headers_out. Not currently used are subprocess_env and notes.
I propose adding a single new C command to Rivet/Tcl to provide
interfaces to all these tables for getting, setting and inventorying
their contents.
Something like
table get tablename key
table set tablename key value
table unset tablename key
table list tablename
I know there is some ability to support multiple entries with the
same key. Right now I'm punting on that but I suppose it might
need that. Perhaps
table add tablename key value
Anybody have any thoughts, concerns, objections, accolades, remarks,
hot buttons, flames, etc?
Really I only need an interface to notes but I figured
subprocess_env could be a good one to be able to mess with as well,
at least. Conceivably we could eventually simplify by using a more
uniform interface at the C level as well. I've got it coded but
haven't tested it yet.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Universita' degli Studi di Parma (http://www.unipr.it)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
charset handling in rivet configuration
I've beein working a bit to enable Rivet to infer the default charset using the 'AddType' lines in the conf files. 'AddType' first argument is a mime-type specification, which can include a charset definition. For Rivet this could be AddType 'application/x-httpd-rivet; charset=utf-8' rvt Rivet doesn't handle a line like this at all. As a matter of fact this line would completely bust rivet templates parsing and execution. I think that some functions in mod_rivet have to be slighly changed in order to handle a new generalized type definition, and since the argument to AddType is passed to the mod_rivet on every request (rivet has to tell Apache if it's going to handle it) I think this info can be stored in the request record that extends apache's request_rec. I think i could send the patches on the list in the next few days. Any suggestion or objection? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accessing Apache core configuration
I think I need help about this I realized the CacheSize parameter is either defined in the configuration or set as '10', whereas the doc page says Sets the size of the internal page cache, where size is the number of byte-compiled pages to be cached for future use. Default is MaxRequestsPerChild / 5, or 50, if MaxRequestsPerChild is 0. I thought fixing it could be as simple as calling a core function that returns the MaxRequestsPerChild parameter's value, but I haven't found a core function that returns core's parameters values. Being able to accessing apache's core configuration would help my work in giving a solution to my task about charset specification handling. I've been able to do it in a way I don't like and i this module's and server's default charset definitions. regards -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: charset handling
A detailed description of the patches sent around in my previous message. Regards. -- Massimo 2008-06-30 Massimo Manghi [EMAIL PROTECTED] * src/rivet.h: added macro STRNEQU(s1,s2) which efficiently compares 2 strings. Unlike STREQU(s1,s2) this new macro compares at most strlen(s2) characters. * src/TclWeb.h: added charset field to TclWebRequest. This new property gets initialized to NULL every time this structure is instantiated. If used it stores a pointer to a string that specifies a header value fragment for the page being generated. * src/apache-2/TclWebapache.c: request_rec is treated as an opaque structure and the field 'content_type' is set by calling the ap_set_content_type apache core function * src/apache-2/mod_rivet.h: a 'honor_header_only_reqs' is added to the rivet_server_conf for handling of the HonorHeaderOnlyRequests configuration option * src/apache-2/mod_rivet.c: Every content_type is checked for possible charset specifications. When found this is stored in the TclWebRequest structure to be processed later. If a script or template doesn't set a content type on its own (with the 'headers type ctype' command) the charset is written in the http headers. Added support for the 'HonorHeaderOnlyRequests' switch. Other minor changes include better code formatting in some functions and commenting out some cruft left around. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error installing rivet_0.4.0-1
Thank you Tom, having his and your feedback would help a lot. Your direction could be useful for writing an INSTALL.Slackware file, I will try to write it down and will sent it to you for a check. David, what is your degree of commitment with Debian now? Having in testing a .deb automatically generated by a slackware utility would offend your pride of old-timer skillful Debian Project member? :-) -- Massimo On Wed, 09 Jul 2008 21:19:59 -0400, Tom Brown wrote Massimo: I waited a long time to reply. I am working with both apache 1.3 and 2.2 on Slackware. httpd 2.2.8 rivet 0.8.0 slackware 12.1.0 httpd 1.3.41 rivet 0.5.0 slackware 12.0 A friend is working with Debian, apache 2.2 and rivet 0.8.0. Following is my half of a recent correspondence with him. I am encouraging him to let me post his Debian experience for you. We are using Sqlite3 and PostgreSQL with apache-rivet. My experience on Slackware 12.1 was different. INSTALLING RIVET Following Goose's subversion instructions got me rivet version 0.8.0 files in /usr/local/rivet. Then I used these steps to install rivet. 1. aclocal 2. autoreconf 3. ./configure --with-apache-version=2 \ --with-tcl=/usr/lib \ --with-apxs=/usr/bin/apxs 4. make 5. checkinstall --fstrans=no 6. installpkg rivet-0.8.0-i386-1.tgz Comments: Steps 1 and 2 issue warnings, but they can be ignored. I suspect these steps do what genconf.sh accomplishes in Goose's protocol. checkinstall (#5) creates a Slackware .tgz file to install with any of the Slackware package management tools. Checkinstall also makes .rpm and .deb packages. Installpkg (#6) is the default utility built into Slackware. Later, if I want to remove a package, I can use any of the Slack package management tools for that too. Removepkg is the default. CONFIGURING APACHE 2 This turns out easy in Slackware. You can probably eliminate steps 2 and 3 below and do fine. If you never use index.rvt, you can eliminate step 5 as well. 1. Add LoadModule rivet_module lib/httpd/modules/mod_rivet.so to the end of the dynamic shared object (DSO) support list. 2. Make sure your DocumentRoot is set properly. Mine is: DocumentRoot /var/www/htdocs. 3. Make sure the controls for Directory /var/www/htdocs are set correctly. The defaults work for me. 4. Add handlers for .rvt and .tcl files to IfModule mime_module. AddType application/x-httpd-rivet .rvt AddType application/x-rivet-tcl .tcl 5. Add index.rvt and index.tcl to IfModule dir_module. DirectoryIndex index.html index.rvt index.tcl 6. Restart apache with either of the following. apachectl restart /etc/rc.d/rc.httpd restart That's it. Unless you want to use .tcl CGI files, you're done. Tom Tom Brown Free Geek Michiana Massimo Manghi wrote: You're welcome, just out of curiosity: are you working with apache 2.x or 1.3? -- Massimo Tom Brown wrote: Massimo: Your suggestion worked perfectly. Thanks. Tom -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Accessing Apache core configuration
On Wed, 9 Jul 2008 11:40:10 +0200, David Welton wrote Truth be told... I'm not sure if there is really a good fix. The user hasn't set the cache size, and the max requests per child isn't set either, so we just pick a number. Perhaps in this day and age a bigger number might be better. Do you think a value of 50 would be enough? For my needs 20/25 slots in the cache would suffice, but I made only a few small Projects -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fixed problem with recursive 'parse' calls
I noticed Rivet failed to parse complex
templates composed by several nested .rvt files.
It turned out the problem occurred only when at least
2 templates were parsed within the same nesting level.
I put into apache-2/mod_rivet.c a test condition
taken from the apache-1/mod_rivet.c that fixes
the problem.
The patch also sets as 50 the default for the cache size
-- Massimo
Index: ../../trunk/src/apache-2/mod_rivet.c
===
--- ../../trunk/src/apache-2/mod_rivet.c(revision 685960)
+++ ../../trunk/src/apache-2/mod_rivet.c(working copy)
@@ -302,9 +302,9 @@
* Prints the error buffer if any.
*/
static int
-Rivet_ExecuteAndCheck(Tcl_Interp *interp, Tcl_Obj *outbuf, request_rec *r)
+Rivet_ExecuteAndCheck(Tcl_Interp *interp, Tcl_Obj *outbuf, request_rec *req)
{
-rivet_server_conf *conf = Rivet_GetConf(r);
+rivet_server_conf *conf = Rivet_GetConf(req);
rivet_interp_globals *globals = Tcl_GetAssocData(interp, rivet, NULL);
if( Tcl_EvalObjEx(interp, outbuf, 0) == TCL_ERROR ) {
@@ -477,7 +477,7 @@
}
}
-if (Rivet_CheckType(req-req) == RIVET_FILE)
+if ((Rivet_CheckType(req-req) == RIVET_FILE) || !toplevel)
{
/* toplevel == 0 means we are being called from the parse
* command, which only works on Rivet .rvt files. */
@@ -494,8 +494,7 @@
}
if (toplevel) {
if (rsc-rivet_after_script) {
-Tcl_AppendObjToObj(outbuf,
-Tcl_NewStringObj(rsc-rivet_after_script, -1));
+
Tcl_AppendObjToObj(outbuf,Tcl_NewStringObj(rsc-rivet_after_script, -1));
}
}
@@ -525,7 +524,7 @@
Tcl_DeleteHashEntry(delEntry);
free(rsc-objCacheList[*(rsc-cache_size) - 1]);
memmove((rsc-objCacheList) + 1, rsc-objCacheList,
-sizeof(char *) * (*(rsc-cache_size) -1));
+sizeof(char *) * (*(rsc-cache_size) - 1));
//hkCopy = (char*) malloc ((strlen(hashKey)+1) * sizeof(char));
//strcpy (rsc-objCacheList[0], hashKey);
@@ -945,8 +944,6 @@
return Tcl_GetStringFromObj( objarg, NULL );
}
-
-
/*
* Implements the RivetServerConf Apache Directive
*
@@ -1371,7 +1368,7 @@
if (ap_max_requests_per_child != 0) {
*(rsc-cache_size) = ap_max_requests_per_child / 5;
} else {
-*(rsc-cache_size) = 10; /* FIXME: Arbitrary number */
+*(rsc-cache_size) = 50; /* FIXME: Arbitrary number */
}
}
@@ -1634,9 +1631,6 @@
apr_collapse_spaces(charset,charset);
globals-req-charset = charset;
-
-// fprintf(stderr,conf charset -- %s\n,conf_charset);
-// fflush(stderr);
}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
small patch rivet.xsl, rivet.xml
I changed a couple of rule in rivet.xsl: they
basically make example boxes a bit more flexible
for html browsing and made their background color
a bit more neutral. I also made the character
in them slighly smaller in order to have more
space for code lines.
I'm working on apache_multipart_buffer, but
I think the next week is going to be busy.
-- Massimo
Index: doc/rivet.xsl
===
--- doc/rivet.xsl (revision 689778)
+++ doc/rivet.xsl (working copy)
@@ -120,7 +120,7 @@
xsl:template match=cmdsynopsis
div class={name(.)} style=width:80%
- div style=background:#ff ; margin:1ex ; padding:.4ex ;
+ div style=background:#ff ; margin:1ex ; padding:.4ex;
padding-left: 0.8ex;
word-spacing:1ex
xsl:call-template name=anchor/
xsl:apply-templates/
@@ -302,9 +302,9 @@
/pre
/xsl:when
xsl:otherwise
- pre style=background:#bbffbb ; width:90ex ; margin: 2ex ;
- padding: 1ex; border: solid black 1px ; white-space: pre;
- font-family:monospace ; class={name(.)}
+ pre style=background:#ccc; margin: 2ex; margin-right: 10%;
+ padding: 1ex; border: dashed black 1px ; white-space: pre;
+ font-family: monospace; font-size: 90%; class={name(.)}
xsl:apply-templates/
/pre
/xsl:otherwise
@@ -327,4 +327,4 @@
/xsl:choose
/xsl:template
-/xsl:stylesheet
\ No newline at end of file
+/xsl:stylesheet
Index: doc/rivet.xml
===
--- doc/rivet.xml (revision 689778)
+++ doc/rivet.xml (working copy)
@@ -40,6 +40,7 @@
year2005/year
year2006/year
year2007/year
+ year2008/year
holderApache Software Foundation/holder
/copyright
author
@@ -75,6 +76,7 @@
meet these goals, we have chosen the Tcl programming language to
combine with the Apache Web Server.
/para
+
para
In this manual, we aim to help get you started, and then
writing productive code as quickly as possible, as well as
@@ -252,6 +254,16 @@
filename.rvt/filename and filename.tcl/filename
extensions as Rivet files.
/para
+ para
+ The characters encoding can be changed using the commandheader
type/command command,
+ but if you want to change the default charset for the whole site or
directory hierarchy
+ a new charset can be embedded in a AddType line in a way similar to
the
html pages encoding.
+ /para
+ programlistingAddType 'application/x-httpd-rivet;charset=utf-8'
rvt/programlisting
+ para
+ Pages which this configuration applies to send back to the client
+ a commandContent-Type:'text/html;charset=utf-8'/command header.
+ /para
paraYou may also wish to use Rivet files as index files for
directories. In that case, you would do the following:/para
programlistingDirectoryIndex index.html index.htm index.shtml
index.cgi
index.tcl index.rvt/programlisting
@@ -1790,9 +1802,9 @@
(Firefox,Safari,Opera...) uses the XMLHttpRequest class to create it,
whereas IE uses the ActiveXObject class.
note
- With the release of IE7 Microsoft introduced
+ With the release of IE7 Microsoft introduced native support for
ulink
url=http://blogs.msdn.com/ie/archive/2006/01/23/516393.aspx;
- native support/ulink for XMLHttpRequest class objects
+ XMLHttpRequest/ulink class objects
/note
By creating an instance of this class a POST or GET request can be sent
to the server, whose response is stored in a
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: small patch rivet.xsl, rivet.xml
On Fri, 29 Aug 2008 22:28:05 +0200, David Welton wrote I'm working on apache_multipart_buffer, but I think the next week is going to be busy. The thing to look at with that is this: apache-1/apache_multipart_buffer.c the file in apache-2 basically differs only for the api calls towards apache and other calls that have been removed because deleted from apache 2 api. Which comes from here: http://httpd.apache.org/apreq/ Which I'm sure is now compatible with Apache 2.x I was taking inspiration from Nick Kew's mod_upload.c which is an input filter with a simple but neat implementation of the multipart parser. I imagine moving to a filter the whole mechanism could be an approach, but before we fancy about major reorganization I'd like to have a rivet version reasonably stable for every feature. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rivet and TK GUIs
On Wed, 1 Oct 2008 18:14:30 -0300, Ricardo Aiello wrote Hi, I'm a newbie to Rivet, and I'd like to ask a couple of questions: welcome in the business - Can I embed TK graphical interfaces in HTML pages using Rivet? This question in not specifically related to Rivet's capabilities. The only tool I know for adding Tk graphics to webpages is the Tcl plugin (http://wiki.tcl.tk/12719). I haven't been using the plugin for a long time now, therefore I can't say anything about it, but in case you can use it even if you're developing pages using other languages (PHP, etc) or even if you're writing pure html pages. - Is it possible to run Rivet on Apache 2 over Win32? For what I know nobody tried to compile the code in trunk for apache2 on windows so far. I wish someone volunteered to do it, that would help us a lot. - Is Rivet still being developed? I'm personally involved in actively maintain the code. In the last year we have been able to make rivet compile and work for Apache2 and added some minor features. I have some changes in my working copy that have to commited yet, but the code in svn compiles and builds a functioning module. I've started also to work on the website. - Are there any newer/better solutions for implementing server-side TCL/TK scripts into HTML? http://tcl.apache.org/ Thanks in advance for any help, Ricardo you're welcome -- Massimo Manghi - Dipartimento di Biologia Evolutiva e Funzionale Università degli Studi di Parma (Italia) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
pointer corruption while executing Tcl_FSStat
As I resumed some maintenance on Rivet's code I found out
the code that was quite nicely working last summer segfaults
when rivet templates parse other embedded templates. The gcc
compiler and the C library have been upgrade since then but no
other applications, either mine or shipped with debian, seem to
have suffered from that.
The way the segfault occurs is simple: in Rivet_Parse a call
to Tcl_FSStat blasts the pointer value in the first
argument. Arguments being passed in have been
checked running Apache under debugger control
and are valid.
This is the relevant code
TCL_CMD_HEADER( Rivet_Parse )
{
char *filename;
Tcl_StatBuf buf;
Tcl_Obj *fnobj;
...
fnobj = Tcl_NewStringObj(filename, -1);
Tcl_IncrRefCount(fnobj);
retval = Tcl_FSStat(fnobj, buf);
Tcl_DecrRefCount(fnobj);
...
}
and the backtrace after the process returns from the call
(gdb) bt
#0 Rivet_Parse (clientData=0x0, interp=0x9014e50, objc=2,
objv=0x9018a7c) at rivetCore.c:142
#1 0xb6c44926 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#2 0xb6c6e7cf in ?? () from /usr/lib/libtcl8.4.so.0
#3 0x09014e50 in ?? ()
#4 0x0002 in ?? ()
#5 0x09018a7c in ?? ()
#6 0x in ?? ()
(gdb)
being fnobj no more pointing to a valid Tcl object
the process segfaults on the call to Tcl_DecrRefCount.
The code retval is successful and the buf structure contains the
actual file status. Allocating the pointer on the heap (through the
apr pool) fixes the problem, but it looks a way to put the head
in the sand and pretend the problem is not around
What I ask you for are hints that may help me to single out the culprit
of this behavior.
thank you
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pointer corruption while executing Tcl_FSStat
Thank you Damon for the quick answer.
On Fri, 7 Nov 2008 13:10:36 -0600, Damon Courtney wrote
TCL_CMD_HEADER( Rivet_Parse )
{
char *filename;
Tcl_StatBuf buf;
Tcl_Obj *fnobj;
...
fnobj = Tcl_NewStringObj(filename, -1);
Tcl_IncrRefCount(fnobj);
retval = Tcl_FSStat(fnobj, buf);
Tcl_DecrRefCount(fnobj);
...
I believe that the Tcl_FSStat() call is actually decr'ing the
refcount for you. I couldn't tell you why, but I've run into a
number of occasions where the FS calls do this. The code is pretty
simple, so from looking at it, it's the only explanation I can come
up with. 0-]
Damon
Isn't the value of pointer (not its address) that is passed
to Tcl_FSStat? I might be discovering my knowledge of the C
language fundamental mechanisms is overly naive, but how the
pointer value get set to 0 in the caller's scope?
-- Massimo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pointer corruption while executing Tcl_FSStat
Index: src/apache-2/rivetCore.c
===
--- src/apache-2/rivetCore.c(revision 712202)
+++ src/apache-2/rivetCore.c(working copy)
@@ -41,6 +41,7 @@
#include tcl.h
#include string.h
#include stdio.h
+#include apr_errno.h
#include apache_request.h
#include mod_rivet.h
@@ -52,6 +53,7 @@
#define COOKIES_ARRAY_NAME cookies
extern module rivet_module;
+extern char* TclWeb_GetRawPost (TclWebRequest *req);
#define POOL (globals-r-pool)
@@ -105,10 +107,10 @@
TCL_CMD_HEADER( Rivet_Parse )
{
-char *filename;
-Tcl_StatBuf buf;
-Tcl_Obj *fnobj;
-int retval = 0;
+char*filename;
+apr_status_tstat_s;
+apr_finfo_tfinfo_b;
+
rivet_interp_globals *globals = Tcl_GetAssocData(interp, rivet,
NULL);
if( objc 2 || objc 3 )
@@ -124,8 +126,7 @@
Tcl_WrongNumArgs( interp, 1, objv, ?-virtual? filename );
return TCL_ERROR;
}
-filename = TclWeb_GetVirtualFile( globals-req,
-Tcl_GetStringFromObj(objv[2], (int *)NULL) );
+filename =
TclWeb_GetVirtualFile(globals-req,Tcl_GetStringFromObj(objv[2],(int
*)NULL));
}
if (!strcmp(filename, globals-r-filename))
@@ -134,13 +135,12 @@
return TCL_ERROR;
}
-fnobj = Tcl_NewStringObj(filename, -1);
-Tcl_IncrRefCount(fnobj);
-retval = Tcl_FSStat(fnobj, buf);
-Tcl_DecrRefCount(fnobj);
-if (retval != 0)
+stat_s = apr_stat(finfo_b,filename,APR_FINFO_NORM,globals-r-pool);
+if (stat_s != APR_SUCCESS)
{
-Tcl_AddErrorInfo(interp, Tcl_PosixError(interp));
+char apr_error_message[256];
+
+
Tcl_AddErrorInfo(interp,apr_strerror(stat_s,apr_error_message,256));
return TCL_ERROR;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload data and upload channel problem solved / fixed for Apache 2
Hi Karl, as you are one of Rivet's masterminds it's good to hear from you again. Actually 'upload channel' works for me (apache2 and rivet code from svn trunk) but, as you said, 'upload data' complains about the server configuration variable not being set. Karl Lehenbauer wrote: This was tricky. Apache has its own portable I/O library http://apr.apache.org/docs/apr/1.2/group__apr__file__io.html that apparently is just a FILE * in Apache 1.3 but is an Apache-defined C structure in 2.2. Rivet made some assumptions about it that it shouldn't have, like that it could use the fileno() library call to get the UNIX file descriptor. I've got a fix working such that upload channel works with Apache 2 and upload data which has not been working in Apache 1.3 or 2. I've also added a new subcommand, upload tempname, to get the name of the temporary file that contains the uploaded file for those who want to roll their own. In addition to working, it is now system independent without any special code, like it'll work on NT and stuff. The cost is that it opens the temp file that contains the uploaded file, rather than grabbing the file handle out of the Apache portable runtime file structure. There appears to be no legal way to grab the file descriptor out of the apr_file_t structure, so I think it's a small cost in overhead for something that's intrinsically relatively high overhead anyway (uploading files), and IMHO it's worth it to use the Apache file API in a standard manner. With your agreement I'd like to commit these changes. no objection, I'm curious to see what difference caused one subcommand to fail. By the way, the raw_post command doesn't seem to work. thank you for pointing this out. I never used this undocumented command but this could be an opportunity for doing it along with the fix. By the way, I remember you came up with an idea about exploiting a field in 'request_rec' to pass custom data to the server for subsequent logging. IIRC you had already coded it, are you still willing to share it with Rivet? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
rivet.xml reorganized
Before more commits to rivet.xml are done I submit to your approval the splitting of the manual in 12 xml files bound toghether in a single small new rivet.xml. This should make the manual more flexible for future changes. I won't attach here the new rivet.xml because I guess everyone can image what (simple) operations it implied: - the original text was broken up (one file for every toplevel section) - new entities have been defined for the new files - every entity was added to the document in the same order the corresponding text had in the large current rivet.xml Karl's recent addition to the manual has been preserved. -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
examples in toc and another customization
I've managed to get a list of the examples in the TOC of the manual. This was done changing the docbook xsl param 'generate.toc'. I wanted to have the examples listed as items in the tree of the toc, but chose to go this way, given the minimum effort and maximum future portability (being this param a feature of docbook) As a consequence of the splitting of the manual the timestamp on the front page was updated only when the main rivet.xml was modified. This implied the timestamp would not have reflected most of the new changes, being the totality of the contents in the files bound toghether by rivet.xml. I replaced the svn Date property with the component ?dbtimestamp=... ? that calls a timestamp function of the xslt processor. It seems that this processing istruction is supported by most xslt processors except for MSXSL though. -- Massimo Index: doc/rivet.xml === --- doc/rivet.xml (revision 722819) +++ doc/rivet.xml (working copy) @@ -73,7 +73,7 @@ /para-- para -Document revision: $Revision$, last modified $Date$ by $Author$. +Document revision: $Revision$, last modified ?dbtimestamp format=Y-m-d X ?$ by $Author$. /para !-- Introduction -- Index: doc/rivet.xsl === --- doc/rivet.xsl (revision 722819) +++ doc/rivet.xsl (working copy) @@ -29,6 +29,7 @@ xsl:param name=admon.graphics select=1/ xsl:param name=generate.section.toc.level select=1/ xsl:param name=refentry.separator select=1/ + xsl:param name=generate.tocarticle toc,title,example/xsl:param !-- xsl:param name=refentry.generate.title select=1/ @@ -52,6 +53,7 @@ xsl:variable name=group.rep.repeat.str.../xsl:variable + xsl:template name=inline.underlineseq xsl:param name=content xsl:call-template name=anchor/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: examples in toc and another customization
On Wed, 3 Dec 2008 22:50:01 +0100, David Welton wrote I replaced the svn Date property with the component ?dbtimestamp=... ? that calls a timestamp function of the xslt processor. It seems that this processing istruction is supported by most xslt processors except for MSXSL though. Since we run the xslt processor ourselves to generate the HTML, it's not that big a deal if other people have to fiddle a bit to get it right. If we can make it easier, great, but it's not like building the source code where everyone *needs* to be able to do it. Actually I don't see the point in having the generated html in repository. I think we may generate the pages when needed and build an archive out of them to be placed on the website (or anywhere the Apache organization requires so, I'm still not familiar with these aspects of Apache). The doc/html directory may be given an 'ignore' property to tell svn to leave it alone. Anyone wanting to build their own manual will be enable to do it exactly like they do it now. Any thoughts? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
upload tempname commands
I made some attempt to use the new 'tempname' subcommand and found out that actually it is not in the interpreter. In fact it seems that Karl forgot to commit the updated rivetCore.c with the new command. Am I getting it wrong? Karl, do you want me to add the code in that file? -- Massimo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
raw_post command
I had a chance to look into the code to understand what
raw_post does and why didn't work (as KL pointed out).
The reason for raw_post not returning data (I don't have
tcl errors) is that the command actually is implemented
only for uurlencode form data. Multipart/form-data parsing
simply doesn't set a the pointer to a buffer with the
whole data posted by the client. Actually such a buffer
doesn't even exist for multipart messages: multipart data
are read in chunks from the client and parsed as they are
handed in by the apache framework. Being raw_post chiefly
a command for debugging (as far as I can understand)
I imagine there was no necessity to give a full
implementation and documentation.
with the last commit of TclWebapache.c Karl changed the
following test in this way
int TclWeb_UploadSave(char *varname, Tcl_Obj *filename, TclWebRequest *req)
{
apr_status_tstatus;
@@ -569,25 +577,27 @@
rsc = RIVET_SERVER_CONF( req-req-server-module_config );
/* This sucks - we should use the hook, but I want to
get everything fixed and working first */
-if (rsc-upload_files_to_var)
+if (1 || rsc-upload_files_to_var)
{
- /* char *bytes = NULL; */
disabling the test on upload_files_to_var altogether. I
suppose this was for test and was meant to be restored
in its pristine form.
-- Massimo
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
upload tempname handling added to rivetCore.c
I made the simple changes that were needed to have the
subcommand 'upload tempname' handled by the interpreter.
I think I'm going to commit soon
Index: src/apache-2/rivetCore.c
===
--- src/apache-2/rivetCore.c(revision 728469)
+++ src/apache-2/rivetCore.c(working copy)
@@ -584,6 +584,7 @@
type,
filename,
names,
+ tempname,
NULL
};
@@ -595,25 +596,27 @@
SIZE,
TYPE,
FILENAME,
- NAMES
+ NAMES,
+ TEMPNAME
};
rivet_interp_globals *globals = Tcl_GetAssocData(interp, rivet,
NULL);
command = Tcl_GetString(objv[1]);
Tcl_GetIndexFromObj(interp, objv[1], SubCommand,
- channel|save|data|exists|size|type|filename|names,
+ channel|save|data|exists|size|type|filename|names|
tempname,
0, subcommandindex);
/* If it's any of these, we need to find a specific name. */
/* Excluded cases are EXISTS and NAMES. */
-if ((enum subcommand)subcommandindex == CHANNEL ||
- (enum subcommand)subcommandindex == SAVE ||
- (enum subcommand)subcommandindex == DATA ||
- (enum subcommand)subcommandindex == EXISTS ||
- (enum subcommand)subcommandindex == SIZE ||
- (enum subcommand)subcommandindex == TYPE ||
- (enum subcommand)subcommandindex == FILENAME)
+if ((enum subcommand)subcommandindex == CHANNEL||
+ (enum subcommand)subcommandindex == SAVE||
+ (enum subcommand)subcommandindex == DATA||
+ (enum subcommand)subcommandindex == EXISTS ||
+ (enum subcommand)subcommandindex == SIZE||
+ (enum subcommand)subcommandindex == TYPE||
+ (enum subcommand)subcommandindex == FILENAME||
+ (enum subcommand)subcommandindex == TEMPNAME)
{
varname = Tcl_GetString(objv[2]);
if ((enum subcommand)subcommandindex != EXISTS)
@@ -683,6 +686,9 @@
case FILENAME:
TclWeb_UploadFilename(result, globals-req);
break;
+case TEMPNAME:
+ TclWeb_UploadTempname(result,globals-req);
+ break;
case NAMES:
if (objc != 2)
{
@@ -693,7 +699,7 @@
break;
default:
Tcl_WrongNumArgs(interp, 1, objv,
-channel|save ?name?|data|exists|size|type|
filename|names);
+channel|save ?name?|data|exists|size|type|
filename|names|tempname);
}
Tcl_SetObjResult(interp, result);
return TCL_OK;
-- Massimo
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
DESTDIR coded in Automake.am
DESTDIR has been coded into the install-data-local and uninstall-local rules following the patch provided by kik...@gmail.com and accordingly to Automake documentation and directives Index: Makefile.am === --- Makefile.am (revision 730501) +++ Makefile.am (working copy) @@ -16,11 +16,11 @@ $(SHELL) ./config.status --recheck install-data-local: - $(mkinstalldirs) $(RIVETLIB_DESTDIR) - cp -r rivet/* $(RIVETLIB_DESTDIR) - -( cd $(RIVETLIB_DESTDIR) ; echo 'eval pkg_mkIndex -verbose [pwd] init.tcl [glob [file join packages * *.tcl] [file join *[info sharedlibextension]]]' | @TCLSH_PROG@ ; ) + $(mkinstalldirs) $(DESTDIR)$(RIVETLIB_DESTDIR) + cp -r rivet/* $(DESTDIR)$(RIVETLIB_DESTDIR) + -( cd $(DESTDIR)$(RIVETLIB_DESTDIR) ; echo 'eval pkg_mkIndex -verbose [pwd] init.tcl [glob [file join packages * *.tcl] [file join *[info sharedlibextension]]]' | @TCLSH_PROG@ ; ) uninstall-local: - rm -fr $(RIVETLIB_DESTDIR) + rm -fr $(DESTDIR)$(RIVETLIB_DESTDIR) # -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: apache_table command for Rivet access to notes table
The syntax you have depicted here seems to be a very natural approach to the problem: easy to read and easy to use. This command has to signal a few potential error conditions though: table-key-value not existing, but also more specifically improper table names or not existing key in a valid table. I welcomed the new 'try/catch/finally' construct recently introduced for Tcl8.6. I wonder if it's possible to adopt a style for raising errors that might encourage the programmer to exploit it. Personally I don't like the idea of checking for an empty string in order to understand if a key-value pair exists (but i'm sure long time Tcl programmers will shrug at my attitude) -- Massimo Karl Lehenbauer wrote: Hi Guys, I last brought this up a little over a year ago and other priorities intervened but I have now implemented an apache_table command and I want to get y'alls' feedback on it. apache_table as currently implemented provides read/write access to four tables in Apache: notes, headers_in, headers_out, err_headers_out and subprocess_env. Here's the syntax of the command: apache_table get tableName key returns the value of the specified key or an empty string apache_table set tableName keyValueList apache_table set tableName key value In the first case, takes zero or more key-value pairs in keyValueList and sets each key in the table with its corresponding value. In the second case, takes one key and one value and sets that key and value into the specified table. apache_table unset tableName key Unsets the specified key-value pair from the table. It is not an error to unset a key that doesn't exist. apache_table names tableName Returns a list of all the keys in the specified table. apache_table array_get tableName Returns the key-value pairs of the specified table as a list, suitable for array set. For instance: array set notes [apache_table array_get notes] apache_table clear tableName Invokes apr_table_clear to clear the contents of the specfied table. I think the above syntax is pretty reasonable. The part that's questionable is providing access to headers_in, headers_out, err_headers_out and subprocess_env. I know we already have a mechanism for access to subprocess_env and would be more than willing to remove any or all of these, or potentially add access to other tables, although I'm not aware of other tables that would be candidates. - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: apache_table command for Rivet access to notes table
On Fri, 1 May 2009 11:07:36 -0500, Karl Lehenbauer wrote So you would prefer for it to work like an array? Have an apache_table exists tableName key and make apache_table get tableName key force an error ? in a word: yes. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: coredumps on shutdown with separate virtual interps
I read the log of your last commit and it looks like I introduced this bug because I missed the implications of having the SVI switch turned on. I apologize. -- Massimo Karl Lehenbauer wrote: Separate virtual interpreters are amazingly cool. Using them, fiddling with auto_path, and using git we're able to give each developer their own Rivet interpreters with a private library path that gets searched first, their own webpages, and so forth. It's great. But we're having a problem that when we do an apachectl stop all of the children that have served webpages dump core. The problem is that outputproc is getting called by the flush activities triggered by the call to Tcl_Finalize() as part of the shutdown. There isn't really a request structure so it quickly dereferences a null pointer and that triggers a coredump. Doing some debugging, I've determined that the Tcl channel that Rivet maps to Apache's ap_rwrite and such, its close routine is getting called prior to the attempt to flush this data. What's weird is that the data that it's trying to write is the same as the last webpage the child generated. I'm continuing to investigate because I want to know why it's happening, although it's also reasonable to make the closeproc set a closed flag that the outputproc would honor. The outputproc could also very easily detect that the request structure isn't real, but the big question is why is it getting called in the first place. I mention it here in the hopes that someone will have a flash of insight and/or knows the answer. Karl - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Rivet website
while i was recovering from a flue i worked on the scripts i used to regenerate the website. I originally wrote these scripts along with my students as a case of study for developing a small, slowly changing website and keeping it manageable. the experimental website is (temporarily) hosted at http://rivet.biol.unipr.it/index.rvt or at http://rivet.biol.unipr.it/ through the latter link the same pages are shown but their local path turns into a static html page (mod_rewrite maps these urls to the template :e.g. /about.html - /index.rvt?show=about). By pointing a mirroring tool to the static form of the site should generate a static image of it. I haven't done much on the content of the pages, except for creating a web page for each example already in the docs (by clicking the 'examples' link the 'hello world' example appears and a new menu linking to all the examples shows up). The core of the site generation is a template and a site map, an xml document where links are organized into groups incidentally called menus ;-). Page contents are stored in XML files along with other metadata (Author, Last Changes timestamp etc). In every XML file a central role is played by the content tag elements. These elements *must* be nodes to which a valid xhtml fragment representing the page main content is attached. Actually there are some extensions (e.g. to include program code, rivet templates or other non xml-compliant html code) that are handled and reworked internally into valid xhtml. (More on this in docs I am writing) For those who might be interested in testing the scripts: a feature available is that the website can go multilingual. An example is shown here: http://rivet.biol.unipr.it/index.rvt?show=shaded_table the page is visible also in italian http://rivet.biol.unipr.it/index.rvt?show=shaded_tablelang=it At the moment the site doesn't map properly static pages of the form (page).(language).html into the corresponding parameters for the template, but it should be easy and straightforward to do it. I'd like to commit the scripts and pages to Rivet's svn repository as an example of possible development with Rivet and other Tcl related tools. I would like to commit also the html pages to the website. Comments and suggestions are welcome. If a competent person in styling a website had a better template (and associated style sheet) it would be an excellent way to prepare the website for the new release of Rivet. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: OK got AX_PREFIX_CONFIG_H
I can't remember what exactly I did introducing this macro and svn.apache.org seems to be down at the moment to read the logs. I'm quite certain I added ACLOCAL_AMFLAGS = -I m4 to Makefile.am I tried to rebuild the configure script in the way you did and my libtool installation (2.2.6) suggested to put AC_CONFIG_MACRO_DIR([m4]) in configure.ac. It seems that a working 'configure' comes out of it. more recent libtool versions complain a lot with warnings like this configure.ac:93: warning: AC_CACHE_VAL(lt_prog_compiler_pic_works, ...): suspicious cache-id, must contain _cv_ to be cached tclconfig/libtool.m4:568: AC_LIBTOOL_COMPILER_OPTION is expanded from... tclconfig/libtool.m4:4559: AC_LIBTOOL_PROG_COMPILER_PIC is expanded from... I hope the new libtool.m4 will silence these messages, but I still can't get to svn.apache.org to find out -- Massimo On Wed, 24 Jun 2009 14:34:24 -0500, Karl Lehenbauer wrote I added m4_include([m4/ax_prefix_config_h.m4]) to acinclude.m4, and the configure script works now. -karl - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org -- - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Problems
'Session' is a pure IncrTcl package. It might be worth checking whether you're loading an Itcl package that goes along with the Tcl library against which you have compiled Rivet. I had problems with this issue and could not move my applications to Tcl8.5 until Debian started to ship Itcl packages build for that version. -- Massimo Tom Lloyd wrote: I have identified that the problems start with apache when i have added this to my httpd.conf RivetServerConf ChildInitScript package require Session; Session SESSION \ -cookieLifetime 120 -debugMode 1 When apache tries to spawn new processes they do not work anymore. Thanks Tom - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Session Database
Hi Tom Thomas Lloyd wrote: Hi Massimo, Again your right about mysqltcl. I am working on two systems one at work and one at home testing my set-up in both locations. I thought I had installed mysqltcl at both locations. I had not at home where I was getting this error message. Not knowing how DIO works also threw me. So I now have Rivet, DIO, Session and mysqltcl all working together. My next question comes about the database that DIO/Sessions uses. Do I have to create a database in mysql to hold the session data? yes, the Session package won't create the database structure, but if you look at trunk/rivet/packages/session/ you'll find sql scripts for each backend supported by DIO. If you have mysql I recommend you have mysql-server 5.1 installed. Do I have to define the structure of the tables and database? You certainly have to create a database with authorization privileges that grant to your scripts adequate rights for the session tables (at least privilege to insert, delete and update rows) If I have to define the structure then is there a template or a minimum structure to work from? I think this question basically got answered already. 'Session' has already methods for storing your application data represented as strings. Needless to say the whole point about sessions is that you want a method for associating client and application state. The session class instance has the methods for doing it, understanding what data and in which form is up to your design. Or does Session create the data fields as required in the named database on the fly? again I think I answered Does session clean up the old data from the database? yes, every page of your application should call the method 'activate' in order to refresh the session status. Within this method a clean up of expired sessions data is carried out randomly. Thanks again, Tom hope I understood your problems. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: /manual more recent than /docs on the website
Karl Lehenbauer wrote: We should nuke or at least redirect http://tcl.apache.org/rivet/docs/ since http://tcl.apache.org/rivet/manual/ is more recent. I would opt for wiping out the old docs, unless some relevant resource outside our control is retaining a link to it. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: /manual more recent than /docs on the website
On Fri, 19 Mar 2010 13:23:56 +0100, Ronnie Brunner wrote Karl Lehenbauer wrote: We should nuke or at least redirect http://tcl.apache.org/rivet/docs/ since http://tcl.apache.org/rivet/manual/ is more recent. I would opt for wiping out the old docs, unless some relevant resource outside our control is retaining a link to it. As we have the httpd config under our control, I guess a simple redirect that redirects all deep links to /rivet/docs/* to the new top page /rivet/manual/ should be good enough, don't you think? Ronnie -- This is more than I hoped for. I'm still worried that with time passing old stuff might be left around carrying disorder. I also would commit and transfer to the website the new manual pages that are still missing (new additions made by Karl about errors logging and apache table manipulation). -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Who maintains Rivet
Tom, you have to check consistently if you're using a compatible itcl
package before doing anything. Check with your preferred package manager
which dependencies has your itcl installation or, from the shell, run
'dpkg -s itcl3'. It should tell you every relevant information.
I don't know how Debian packages map to Ubuntu's, but package itcl3
(3.4~b1-2) from 'squeeze' is compiled against tcl8.5. If you can get the
corresponding package for your installation you might end up with a
usable system.
-- Massimo
Thomas Lloyd wrote:
Well that is impressive I like the site
What I am trying to do is probably too complicated based on my skill
level.
I have taken Ubuntu 10.04 LTS as it is supported for the next three
years. Maybe a bad choice. It is officially released at the end of the
Month.
I have got Rivet to Compile using tcl8.5 this has been driven by itcl3
on Ubuntu being compiled on Ubuntu using tcl8.5, even though tcl8.4 is
still the default version of tcl in Ubuntu go figure. Anyways...
I have been unable to get itcl to compile under ubuntu it's moaning
about:
/generic/itcl2TclOO.c:16:19: error: tclOO.h: No such file or directory
./generic/itcl2TclOO.c:17:22: error: tclOOInt.h: No such file or
directory
So i have given up on that line of thought as i came up short on how to
fix that.
Are you planning to move to tcl8.5 anytime soon? ;)
Every thing seems to work nicely until i do a session_delete command.
Then i get:
can't upvar from variable to itself
while executing
variable conf
(object ::VALIDATED method ::Session::delete_session body line 2)
invoked from within
VALIDATED delete_session
(in namespace eval ::request script line 13)
invoked from within
namespace eval request {
puts -nonewline
# VALIDATED activate
puts [VALIDATED id]
parse header.html
parse script_start.co...
OUTPUT BUFFER:
namespace eval request {
puts -nonewline
# VALIDATED activate
puts [VALIDATED id]
parse header.html
parse script_start.code
parse script_end.code
parse login.html
puts Logout Sucessful.
parse footer.html
VALIDATED status
VALIDATED delete_session
puts -nonewline
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: RPM created for Rivet -- some questions
The projects is slowly changing lately. I can only suggest we pick one of the latest snapshots, rename it as rivet-0.8.0.tar.gz (perhaps we may add a 'b1') and put it on the website. The websites I made cannot be compared to filghtaware to any extent, but I've been running rivet on apache2.2 for a year now and not even once Rivet was the cause of serious problems. -- Massimo On Thu, 15 Apr 2010 18:37:41 +, Karl Lehenbauer wrote Hey Gang, Jeff Lawson aka Cow has made an RPM of Rivet and has rpmforge.net, the largest third-party RPM repo for CentOS/Fedora/RHEL (and other RHEL-based) distros, willing to carry it. The issue is right now we only have the snapshots. They need tarballs to stay around longer... weeks, at least. I'm not familiar with the resources that are available to the project or much of the release engineering. Is there an official place we can lodge tarballs to solve this issue? Regards, -karl http://lists.rpmforge.net/pipermail/packagers/2010-April/001177.html http://svn.rpmforge.net/viewvc/rpmforge/trunk/rpms/mod_rivet/ --
missing dir in auto_path
Hi
I'm preparing a training session on Apache and Rivet for my students and
I'm going to teach them how install a trial webserver in their user disk
space (we don't have root access to these computers).
On a test installation my scripts could not load the 'Rivet' package
anymore because the rivet0.8.0 was, as requested, located out of
standard libraries tree. Packages in other subdir were correctly loaded
though, because init.tcl added their path to auto_path.
So I added explicitly to auto_path the directory that contains the
script init.tcl. The patch is trivial and harmless
Index: init.tcl
===
--- init.tcl(revision 936195)
+++ init.tcl(working copy)
@@ -85,6 +85,11 @@
lappend auto_path ${pkgpath}$::tcl_version
}
+ ## Likewise we have also to add to auto_path the directory
containing
+ ## this script since it holds the pkgIndex.tcl file for package
Rivet.
+
+ set auto_path [linsert $auto_path 0 [file dirname [info script]]]
+
## This will allow users to create proc libraries and tclIndex files
## in the local directory that can be autoloaded.
## Perhaps this must go to the front of the list to allow the user
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
inaccurate or missing docs
I've played around with the form package, which is very handy. Writing a docbook page for this package shouldn't take too long. I would be bothered writing it, but not before the end of the week. Another not yet documented package is Crypt, a package written in C that provides (to my understanding) a way to encrypt data by obfuscation. Logs say that the initial author was Damon. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: TODOs before releasing [Re: RPM created for Rivet -- some questions]
1.1 was also my proposal. Damon suggested 2.0 instead on the argument that such a version number would make clear that this release is meant to work also with Apache 2.x. -- Massimo On 04/27/2010 10:44 PM, Jeff Lawson wrote: How about calling it version 1.1 instead? Then it won't seem like such a large jump. Publishing a fresh tarball with an identifiable version number will allow more users to begin trying it out and giving feedback, even if we know there might be issues. It's not practical for some people to use software that is not available as an RPM, FreeBSD port, deb, etc--lacking published tarballs is currently blocking those distribution methods from existing. - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Announcing Rivet 2.0.0
Dear Rivetters a vote has been held on the pmc list and the proposal to release the code in trunk accepted. The release will be named 2.0.0, following David and Damon (D-D) suggestion. They fathered Rivet and still hold a golden share on the project. We are in the process of fulfilling ASF requisites for official releases. These are the various usual steps needed to ensure proper authenticity of the distribution. As soon as the process has completed a signed tarball will be uploaded to asf for distribution and we will send a new announce on this list and publish it on the website. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Announcing Rivet 2.0.0
I beg your pardon for adding noise to the list. On Thu, 29 Apr 2010 10:20:56 +0200, Massimo Manghi wrote Dear Rivetters a vote has been held on the pmc list and the proposal to release the code in trunk accepted. The release will be named 2.0.0, following Actually I meant the code in the new 2_0 branch that will stem from the current code in trunk. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet 2.0.0 tarball uploaded to www.apache.org
Hi Ronnie, good questions that make me critically examine what I did. First of all, we can still tag the code in trunk to follow your suggestion, if we deem it as a good course of action. I would consider the possibility and, in case, tag it before new commits happen. Second reason: since a 1_0 branch has existed now for quite a long time I assumed this was a policy D-D had decided sometime in the past. Admittedly I had to ask explicitly. The third reason is that we still can copy further developments from trunk into 2_0 at will, as long as we think they won't break anything. I expect trunk to diverge from 2_0 though, at least we have to keep the possibility open. Sooner or later the support for apache 1.x will be dropped in trunk making room for support of new apache versions, whereas I think of the 2_0 branch as something that will maintain the apache 1 code even though we will make fixes, adjustments and improvements on it. Unlike in the typical example for a branch I don't see 2_0 as a branch that will join in the future the development in trunk. I hope I passed the exam. :-) regards -- Massimo On Thu, 29 Apr 2010 18:40:24 +0200, Ronnie Brunner wrote prevent a user from building the module though. It's been corrected in the 2_0 branch and will be commited soon. Actually, just wondering: why did you create a 2_0 branch (especially since it's copied from head. Don't you expect to continue development on the trunk? I'd have thought that it might have made more sense to just create a 2.0.0 tag on the trunk and then continue in the trunk. Or do you expect independent development happening on trunk and the 2_0 branch? Or are there other reasons to create a branch instead of just a tag (Even if it's technically the same in SVN anyway...)? Regards Ronnie -- Ronnie Brunner | ronnie.brun...@netcetera.ch phone +41-44-247 79 79 | fax +41-44-247 70 75 Netcetera AG | 8040 Zürich | Switzerland | http://netcetera.ch - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org -- - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet 2.0.0
Hi Arnulf, I'm glad to see your interest in trying Rivet 2.0. Any feedback about your impressions on Rivet, also working in conjunction with itclng, would be much welcome. cheers -- Massimo On 05/03/2010 10:03 AM, Arnulf Wiedemann wrote: Thanks, as current maintainer of itclng, I was just fixing a bug, which I had implemented myself ;-) It was not related to rivet, but there it was the first time the bug did show up with a segmentation violation. Arnulf - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
'headers type' command in BeforeScript
Hi folks I'm working on a project where documents will be served encoded with UTF-8. I thought that I could simply add headers type 'text/html; charset=utf-8 in the 'BeforeScript' evaluated at every request. It did not work. Instead the Content-Type: header value is returned corrupted. I remember this command worked well and I've been using it in tcl scripts for a long time now. As a matter of fact, moving the 'headers' call to the very beginning of the requested template restores the correct header, but this is matter for investigation, not just because I prefer to keep the template clean before the DOCTYPE declaration. Just asking if someone has any clue (D-D?): ParseExecFile (IIRC) apparently concatenates BeforeScript+ParsedRvtTemplate+AfterScript without manipulation in between. Still something goes wrong. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet and Apache 2
Actually Rivet can be compiled for Apache 1.3 too using the switch --with-apache-version=1. You can't build a mod_rivet.so that works with both versions though. I never compiled Rivet for a version 1.3: these historical releases are not linked on apache's download page either and 1.3 has been declared as 'end-of-life' (last release 1.3.42, feb.2010). As things will become incompatible (or too time expensive in order to keep them compatible) we will drop support for apache 1.3. -- Massimo On 05/11/2010 04:05 PM, Harald Oehlmann wrote: On http://tcl.apache.org/ there is stated, that Rivet is for Apache 1.3. I suppose, this should be changed to 2.0. - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: Rivet and Apache 2
On 05/11/2010 04:39 PM, Ronnie Brunner wrote: On http://tcl.apache.org/ there is stated, that Rivet is for Apache 1.3. I suppose, this should be changed to 2.0. I guess Harald just meant that the statement on the web site should be changed and read for Apache 1.3. and 2.x instead of for Apache 1.3. I fixed that in index.rvt and manually changed index.html Regards Ronnie ok, sorry for the misunderstanding -- M - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
'headers type' command problem: *solved*
Fixes in TclWebapache.c
- wrong assumption about 'ap_set_content_type' called in
TclWeb_SetHeaderType: this function allows opaque handling of the
content_type field in 'request_rec', but does not duplicate the string passed
in by the caller whereas the pointer can be invalidated by Tcl. String is now
duplicated through call to apr_pstrdup.
- calls to 'ap_send_http_header' centralized in function TclWeb_SendHeaders
(also in src/apache-1/TclWebapache.c)
- added includes to silence some compilation warning.
-- Massimo
Index: src/apache-2/TclWebapache.c
===
--- src/apache-2/TclWebapache.c (revision 939494)
+++ src/apache-2/TclWebapache.c (working copy)
@@ -30,6 +30,8 @@
#endif
#include tcl.h
+#include sys/types.h
+#include pwd.h
#include httpd.h
#include http_request.h
@@ -69,7 +71,9 @@
TclWeb_SendHeaders(TclWebRequest *req)
{
//TODO: fix ap_send_http_header
+
ap_send_http_header(req-req);
+
return TCL_OK;
}
@@ -85,11 +89,13 @@
int
TclWeb_SetHeaderType(char *header, TclWebRequest *req)
{
+
if(req-headers_set)
return TCL_ERROR;
//req-req-content_type = (char *) apr_pstrdup(req-req-pool, header);
-ap_set_content_type(req-req,header);
+
+ap_set_content_type(req-req,apr_pstrdup(req-req-pool, header));
req-headers_set = 1;
return TCL_OK;
}
@@ -102,13 +108,18 @@
return TCL_ERROR;
if (req-headers_set == 0)
+{
TclWeb_SetHeaderType(DEFAULT_HEADER_TYPE, req);
-
+}
+
/*
* seems that ap_send_http_header is redefined to ; in Apache2.2
* ap_send_http_header(req-req);
*/
-ap_send_http_header(req-req);
+
+TclWeb_SendHeaders(req);
+/* ap_send_http_header(req-req); */
+
req-headers_printed = 1;
return TCL_OK;
}
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
proposal: creating a '2_0_0' snapshot in a 'tags' directory
Hi Rivetters the subject of the message should be self explaining and my proposal comes after Ronnie's question about the choice of branching instead of tagging. I put forward the proposal to create a 'tags' directory in the repository where we can create tagged versions when we release (e.g. current '2_0' in branches would become tags/2_0_0). Benefits of the operation: - Even though we have the tarballs, keeping tagged branches in the repository allows for better and faster code analysis. - We can carry on the development in trunk, copying compatible changes to the 2_0 branch when we know it can be done, and at the same time we can follow threads of development in 2_0 and trunk separately, still having the milestone of the tag branch around. - Keeping a tagged branch makes docs and informational files (INSTALL, README, html pages, etc) of a release available through svn. This enables us to link into the website the right version of those documents, instead of copying. This can be done by simply creating a directory in the our site, putting it in control of svn, and editing its 'external' property: a much faster and error proof operation when new releases happen. This probably sounds like too much for a project that had only a few active committers in the last years, but given the very small cost and difficulty of the operation and the improved project management the would ensue, I think we should consider it carefully. feedback is welcome. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: proposal: creating a '2_0_0' snapshot in a 'tags' directory
On 05/12/2010 03:46 PM, Harald Oehlmann wrote: Am 12.05.2010 15:36, schrieb Massimo Manghi: I put forward the proposal to create a 'tags' directory in the repository where we can create tagged versions when we release (e.g. current '2_0' in branches would become tags/2_0_0). - this is recommended by svn guidelines but forgotten in Rivet ever since - it is senseful, even if you are alone - tag and branch is the same, only the folder makes the difference I know this very well, the semantics you give to the same operation is different though. So different that is a good thing to even pretend you don't know, as if one was working with cvs instead of svn. thanks for the feedback. Very sharp and precise -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
replacing current install-sh
I'm going to replace tclconfig/install-sh with the same script shipped with automake 1.11. I've tested it in Rivet and had no visible side effects. comments by autotools experts are welcome -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rpm at least for OpenSuSE
Great, thanks Harald, I will be out of town in the next 2 days, I will put a link on the website to yours and Jeff's rpm as soon as I'm back. -- Massimo On 05/14/2010 03:45 PM, Harald Oehlmann wrote: Here are rpm's for OpenSuSE 11.0, 11.1, 11.2 and current factory and SLE11 (SuSE Linux Enterprise): http://software.opensuse.org/search?baseproject=ALLp=1q=apache2-mod_rivet This link might be put on the rivet web site. --- - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Advances in packaging of Rivet for OpenSUSE
Hi guys Harald Oehlmann and Max Reinhard (the person at SuSE in charge for the Tcl related stuff) have been doing a tremendous job packaging Rivet for SuSE. Rivet now builds successfully on almost every major platform supported by SuSE for both 32 and 64 bits architectures. The status page of the package is at https://build.opensuse.org/package/show?package=apache2-mod_rivetproject=Apache:Modules https://build.opensuse.org/package/show?package=apache2-mod_rivetproject=Apache:Modules viele Danke Harald und Max. -- Massimo
Re: Installation Complete
Yes, it's true, the install-sh now in trunk comes from automake 1.11. The former one was part of the X11 distribution and looked very old. Even though no significant advance has been done since release time I think that planning a bugfix release (2.0.1) would help given the minimal cost of the operation. Issues aldready addressed are the new install-sh, the missing manual (for some reason which I should be blamed for it's not in the tar archive) and a bugfix in TclWebapache.c I committed weeks ago. Some other minor issues could be addressed easily: manual pages for package 'form' and package 'Crypt' and the installation procedure which complains annoyingly about a 'dir' variable not being set. -- Massimo On Fri, 18 Jun 2010 13:35:43 -0500, Jeff Lawson wrote This is due to an obsolete install-sh script being included with Rivet. I think this has already been fixed in CVS, but you could have worked around it by replacing the tclconfig/install-sh with a newer version (you probably have several on your system from other programs if you use locate to find them). - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org -- - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
warning messages during installation process
I focused the problem of the 3 types of messages being generated on installation: 'dir' variable not set: this harmless, yet confusing message is issued by pkg_mkIndex when the whole rivet tcl library is sourced in to find Tcl packages and create their pkgIndex.tcl files. The problem is that these index files are also in the source tree, are copied to the install directory and get sourced as well along with the packages code. Still they are not supposed to be there by the time we generate them. Possible solutions are to remove the pkgIndex.tcl files from repository, since they are automatically generated, or skip the generation process upon installation (assuming these files are generated by the developers and kept in svn) 'argv' variable not set: package 'commserver' has a server.tcl script in it which the code uses the 'argv' variable that, as customary, gets set when the file is run by command line and filled with the arguments to the command. Adding a test on this variable and exiting if not set should work out a safe check. not existing librivetparser.so file: this was actually an error that prevented librivetparser.so to be loaded by tclrivet. The file packages/tclrivet/tclrivet.tcl attempts to load this library using a wrong relative path: determining the correct path is simple. if no objections are raised I will take the first solution for the first problem and commit the changes needed -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
form package
In the process of documenting the 'form' package I found a few things that
looked like small bugs.
- the 'field' method should treat checkbox and radiobuttons alike, printing
the label for the button
- the -labels switch in the radiobuttons menthod shouldn't propagate to the
html attributes, IMO.
- a few comments have been corrected: they were cut and paste of other comments
below the differences
I also think that the class should be reformed allowing a more flexible use.
I'm probably pondering too much about some details, but I don't like the way
'form' leaves you with the only option of sending the html to the client as
object methods are invoked. Rivet Channel does that, it simply wraps ap_rputs
within a tcl 'puts' command with no buffering and, first of all, no xml
awareness.
I took the habit of sending xml code down the output chain in a consistent and
controlled way, presuming the pipelining of xml text by processors that might
be downstream could benefit from the fact that xml fragments are already well
formed and not too small. Experts in xml processors internals would have a
better opinion on this and I'd like to know what they think.
In general, I'd like to have the option of creating content generators that
send data in a controlled way, something like
form myform
set xmlcode [myform start ]
append xmlcode [myform text ...]
append xmlcode [myform submit ]
append xmlcode [myform end]
puts $xmlcode
Perhaps it's too late to merge the 2 approaches, but I wanted to
bring up the issue anyway
-- Massimo
Index: rivet/packages/form/form.tcl
===
--- rivet/packages/form/form.tcl(revision 956657)
+++ rivet/packages/form/form.tcl(working copy)
@@ -102,7 +102,7 @@
foreach {var val} $list {
set var [string range [string tolower $var] 1 end]
set data($var) $val
- if {$var == values} { continue }
+ if {($var == values) || ($var == labels)} { continue }
lappend return -$var $val
}
return $return
@@ -223,7 +223,7 @@
append string /
# ...and emit it
- if {$type == radio} {
+ if {($type == radio) || ($type == checkbox)} {
html $string$data(label)
} else {
html $string
@@ -273,14 +273,14 @@
}
#
-# reset -- emit an HTML image field
+# image -- emit an HTML image field
#
method image {name args} {
eval field image $name $args
}
#
-# reset -- emit an HTML checkbox form field
+# checkbox -- emit an HTML checkbox form field
#
method checkbox {name args} {
eval field checkbox $name $args
--
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
rivet.html (no-chunk manual)
I no one opposes this I will drop the no-chunk target (html/rivet.html) from the 'make docs' command and leave it as an option to the user (docs aren't built by default anyway) I'm trying to improve the manual xml structure in order to ease the styling and removed it for good in my working copy, but I don't see the point in generating the manual always in 2 forms -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: rivet.html (no-chunk manual)
On Thu, 1 Jul 2010 14:14:24 +0200, David Welton wrote I no one opposes this I will drop the no-chunk target (html/rivet.html) from the 'make docs' command and leave it as an option to the user (docs aren't built by default anyway) I'm trying to improve the manual xml structure in order to ease the styling and removed it for good in my working copy, but I don't see the point in generating the manual always in 2 forms Works for me. BTW ,what are you using to edit the XML? bluefish. I'm progressively dismissing the habit to use vim as editor for html and xml. -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
package 'calendar' and latest changes in manual pages
I've just committed a not-so-complete, but readable manual page for package 'form'. I also added to rivet/packages a new package named 'calendar'. Calendar is a package that came out as a result of an exercise I wrote for my students. The approach adopted for creating html calendar tables is probably an overkill and perhaps the oo design is a bit old-style, but it works, it creates html calendar tables configurable with css styling, it offers some flexibility, it's entirely Itcl based and easy to use (just one public method). A manual section has been written and added to the manual. comments are welcome. If appreciative they are mre than welcome ;-) I'm going to call soon a vote on a new bugfix release (2.0.1) that will include this new toy along with the changes I made after we released 2.0.0 -- Massimo - To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
bugs in session package postgres support
Even though a vote has been held on the pmc list, with a general
consensus to release Rivet 2.0.1 I think these two bugs should make it
into the new release, as their impact is such that Session package
wouldn't work for a Postgres installation. I will ask the pmc list
members to swiftly express a new vote and then release this time. These
are the bugs
1) the rivet_session_cache were created with key_ and package_ columns
still named 'key' and 'package'. These columns had been renamed because
Mysql and Oracle (iirc) consider these as keywords,therefore they are
reserved words. session-create.sql needed to be changed accordingly
2) Suprisingly also rivet/packages/dio/dio_Postgresql.tcl had a typo in
a variable name causing method 'store' to fail
Index: rivet/packages/session/session-create.sql
===
--- rivet/packages/session/session-create.sql (revision 961366)
+++ rivet/packages/session/session-create.sql (working copy)
@@ -16,8 +16,8 @@
create table rivet_session_cache(
session_id varchar REFERENCES rivet_session(session_id) ON
DELETE CASCADE,
-packagevarchar,
-key varchar,
+package_ varchar,
+key_varchar,
datavarchar,
UNIQUE( session_id, package, key )
Index: rivet/packages/dio/dio_Postgresql.tcl
===
--- rivet/packages/dio/dio_Postgresql.tcl (revision 961366)
+++ rivet/packages/dio/dio_Postgresql.tcl (working copy)
@@ -138,7 +138,7 @@
# did, put that in in place of numrows, hiding a postgresql
# idiosyncracy from DIO
if {$numrows == 0} {
- set cmdrows [pg_result $resultId -cmdTuples]
+ set cmdrows [pg_result $resultid -cmdTuples]
if {$cmdrows != } {
set numrows $cmdrows
}
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
Re: bugs in session package postgres support
On Sat, 10 Jul 2010 13:42:28 -0500, Karl Lehenbauer wrote
Looks good, Massimo. Is that all that's needed?
It should be all to fix the problem in new installations. Still we have to
write in the release notes using capital letters that existing Postgres
installations must rename 'key' and 'package'. It's trivial, but perhaps we
ought to provide a conversion script...
-- Massimo
On Jul 10, 2010, at 12:39 PM, Massimo Manghi wrote:
Even though a vote has been held on the pmc list, with a general consensus
to release Rivet 2.0.1 I think these two bugs should make it into the new
release, as their impact is such that Session package wouldn't work for a
Postgres installation. I will ask the pmc list members to swiftly express a
new vote and then release this time. These are the bugs
1) the rivet_session_cache were created with key_ and package_ columns
still named 'key' and 'package'. These columns had been renamed because Mysql
and Oracle (iirc) consider these as keywords,therefore they are reserved
words. session-create.sql needed to be changed accordingly
2) Suprisingly also rivet/packages/dio/dio_Postgresql.tcl had a typo in a
variable name causing method 'store' to fail
Index: rivet/packages/session/session-create.sql
===
--- rivet/packages/session/session-create.sql (revision 961366)
+++ rivet/packages/session/session-create.sql (working copy)
@@ -16,8 +16,8 @@
create table rivet_session_cache(
session_id varchar REFERENCES rivet_session(session_id) ON
DELETE CASCADE,
-packagevarchar,
-key varchar,
+package_ varchar,
+key_varchar,
datavarchar,
UNIQUE( session_id, package, key )
Index: rivet/packages/dio/dio_Postgresql.tcl
===
--- rivet/packages/dio/dio_Postgresql.tcl (revision 961366)
+++ rivet/packages/dio/dio_Postgresql.tcl (working copy)
@@ -138,7 +138,7 @@
# did, put that in in place of numrows, hiding a postgresql
# idiosyncracy from DIO
if {$numrows == 0} {
- set cmdrows [pg_result $resultId -cmdTuples]
+ set cmdrows [pg_result $resultid -cmdTuples]
if {$cmdrows != } {
set numrows $cmdrows
}
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
--
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
