Re: Rivet 3.2.3rc1

[Damon Courtney]

 Hey, Massimo!

Can we get a link to the change submission on raw_post? I’ve had a few
problems with that one myself over the years, and I’d like to review the
changes.

Damon


On Oct 3, 2023 at 10:09:52 AM, Massimo Manghi 
wrote:

> Hi everyone,
>
> a release candidate for rivet 3.2.3 is available from
> http://www.rivetweb.org/~manghi/rivet/
>
> This bugfix release of Rivet ships with the contributions made by Scott
> Pitcher concerning the incomplete and faulty implementation of
> ::rivet::raw_post, the correct logging of messages during the ChildInit
> stage and the new tests connected to these improvements
>
>
>  -- Massimo
>
>
> -
> To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
> For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
>
>

Re: [VOTE] Release rivet-3.2.1

[Damon Courtney]

+1

Damon


> On Nov 11, 2021, at 5:18 AM, Massimo Manghi  wrote:
> 
> Still waiting to see if George, David, Damon and Ronnie want to cast their 
> ballots. Formally we could call the vote but I'd like to have them have their 
> say
> 
>  -- Massimo
> 
> On Tue, Nov 9, 2021 at 10:00 AM Massimo Manghi  > wrote:
> My +1 was implicit but I'm reaffirming it here. 
> 
>  -- M
> 
> On Mon, Nov 8, 2021 at 1:58 PM Brice Hamon  > wrote:
> Yes. +1 for me. Thank you Massimo.
> Brice.
> 
> On Mon, Nov 8, 2021, 4:04 AM Harald Oehlmann  > wrote:
> 
> Am 08.11.2021 um 10:00 schrieb Massimo Manghi:
> > Dear PMC members, I kindly ask you to vote to release the artifact
> > 
> > http://www.rivetweb.org/~manghi/rivet/rivet-3.2.1rc3.tar.gz 
> >   
> >  > >
> > 
> > as Rivet 3.2.1 GA software
> > 
> > [X] +1 Yes, Oui, Ja, Sì
> > [ ] 0  Abstain
> > [ ] -1 No, Non, Nein, No
> > 
> > 
> >-- Massimo
> > 
> 
> Massimo,
> uno trabacho mui bien, gracias !
> [X] Si
> 
> Harald
> 
> -
> To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org 
> 
> For additional commands, e-mail: rivet-dev-h...@tcl.apache.org 
> 
> 

Re: Vote to release rc3 as rivet-3.2.0

[Damon Courtney]

I vote yay. Great work, Massimo.

Damon


> On Nov 2, 2020, at 5:38 PM, Massimo Manghi  wrote:
> 
> One more RC available from brubeck.rivetweb.org/~manghi/rivet/ (3.2.0rc3)
> 
> I kindly ask the PMC members to express a vote to release this artifact as 
> Rivet 3.2.0 GA software
> 
> thank you
> 
> -- Massimo
> 
> 
> 
> -
> 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: [VOTE] Release Rivet 3.0.2

[Damon Courtney]

+1

Damon


> On Jul 2, 2018, at 3:53 AM, Massimo Manghi  wrote:
> 
> Dear PMC members
> 
> this is the vote for releasing the artifact
> 
> http://www.rivetweb.org/~mxm/rivet/rivet-3.0.2rc2.tar.gz
> 
> as Rivet 3.0.2 GA software
> 
> [ ] +1 OK
> [ ] 0  abstain
> [ ] -1 Needs more work
> 
>  -- Massimo
> 
> -
> 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: Mirroring rivet svn to git/github...

[Damon Courtney]

I think that’s a great idea. I didn’t know Apache had that, or I think we would 
have jumped on it years ago. :)

Damon


> On May 27, 2018, at 5:41 AM, Georgios Petasis  wrote:
> 
> Hi all,
> 
> I see that many projects have a read-only git mirror. These projects are 
> listed here:
> 
> http://git.apache.org/
> 
> Rivet is not included, and I think that creating such a mirror will be a good 
> idea.
> 
> What do you think?
> 
> George
> 
> 
> -
> 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: Session issue behind load balancer

[Damon Courtney]

There’s no real reason to include IP address. Anything random will do. I always 
use a combination like this:

set s [clock seconds][pid][clock clicks][info cmdcount][info hostname]

Any of those will do, so a bunch of them together is probably overkill, but 
that should produce a significantly random string to use as a session 
identifier.

D


> On Feb 5, 2018, at 10:28 AM, Brice Hamon  wrote:
> 
> Hi Massimo,
> 
> That was my point. 
> 
> In our application, we had to disable it because of the load balancers 
> introduction.
> 
> Damon's proposal will most likely solve the problem, but not entirely for us 
> as rivet powers also mobile apps and IP may change as the users move.
> 
> I  think we should by default enable it so we keep backward compatibility, 
> and add a new session call to disable the IP check.
> 
> That way the session package is more flexible.
> 
> My 2 cents.
> 
> Thank you,
> Brice.
> 
> 
> 
> 
> On Mon, Feb 5, 2018 at 1:41 AM, Massimo MANGHI  
> wrote:
> The IP number is one of the piece of information assembled together to 
> generate a session id, afterwards this session id is stored in a cookie. At 
> every request the cookie is fetched from the browser to establish the session 
> and it goes into a key made by session_id,ip_number to read the data from the 
> database. I wonder if it's absolutely necessary to include the IP in the key. 
> The MD5 session id should be reasonably safe as to avoid key duplication for 
> different sessions. The MD5 sum is composed already by a pretty composite set 
> of data.
> 
> set sessionIDkey "$uniqueID[clock clicks][pid]$args[clock 
> seconds]$scrambleCode[get_entropy_bytes]"
> return [::md5::md5 -hex -- $sessionIdKey]
> 
> where uniqueID is generated by mod_unique (check this module is loaded)
> 
> and the entropy bytes are generated by /dev/urandom (I guess this is 
> incompatible with Windows)
> 
> do we need the IP number to achieve reasonable uniqueness of the key in 
> session table?
> 
>  -- Massimo
> 
> 
> Da: Brice Hamon 
> Inviato: venerdì 2 febbraio 2018 05:22
> A: Massimo MANGHI
> Cc: Rivet_dev
> Oggetto: Re: Session issue behind load balancer
>  
> Hi Massimo,
> 
> No please don't wait as I think Damon's Apache configuration will solve the 
> issue and won't require a Session's package modification.
> We will have to try first in staging.
> 
> However I wonder what happens when a mobile user change tower and if the IP 
> could change. Then a change in the Session package would be required and we 
> would submit it.
> 
> Thank you
> 
> Brice.
> 
> 
> On Thu, Feb 1, 2018 at 5:18 AM, Massimo Manghi  
> wrote:
> I rolled out a 3.0.1 without waiting for this interesting new feature of the 
> Session package, but if you feel you can make it in a definite time I will 
> wait with pleasure for your contribution and then include it into this release
> 
>  -- Massimo
> 
> 
> On 01/31/2018 09:10 PM, Brice Hamon wrote:
> Thank you Damon.
> 
> This is an interesting suggestion. I'll look into it and report.
> 
> Thanks again,
> Brice.
> 
> 
> 
> 


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Session issue behind load balancer

[Damon Courtney]

Not a bad idea, I meant. :)

Damon


> On Jan 31, 2018, at 2:02 PM, Damon Courtney <da...@tclhome.com> wrote:
> 
> Wouldn’t you want to check the X-Forwarded-For header and use the user’s real 
> IP address instead? Not that your request isn’t valid, but you generally want 
> to ignore the IP address of your proxy and instead get the real IP. 
> Especially in your logs. You can make Apache do it automatically with 
> something like this in your config:
> 
> 
>RemoteIPHeader X-Forwarded-For
> 
> 
> Then Apache will pick up the header and use the real IP when logging and 
> everywhere else, including what Rivet sees in its environment.
> 
> Proposing a patch to the session package is not a idea either. :)
> 
> Damon
> 
> 
>> On Jan 31, 2018, at 1:59 PM, Brice Hamon <normandvik...@gmail.com> wrote:
>> 
>> Hi guys,
>> 
>> We ran into a small problem and wanted to share our findings.
>> 
>> We introduced http load balancers upstream of our apache servers to balance 
>> the requests.
>> 
>> The result of this is that new user session were created randomly and that 
>> was an issue for us.
>> 
>> The session package does a look up by IP and sessionID to identify a given 
>> user. 
>> But with the load balancers, the incoming IP is always the IP of one of the 
>> LB.
>> 
>> So Rivet session was creating new session for that user, who was already 
>> logged in.
>> 
>> We made a quick hack to disable the IP check and that solved the issue.
>> We could have made the request sticky but we didn't want that in production.
>> 
>> So should we make this session lookup by IP and sessionID optional with some 
>> type of flag?
>> 
>> Thank you
>> Brice.
> 


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Session issue behind load balancer

[Damon Courtney]

Wouldn’t you want to check the X-Forwarded-For header and use the user’s real 
IP address instead? Not that your request isn’t valid, but you generally want 
to ignore the IP address of your proxy and instead get the real IP. Especially 
in your logs. You can make Apache do it automatically with something like this 
in your config:


RemoteIPHeader X-Forwarded-For


Then Apache will pick up the header and use the real IP when logging and 
everywhere else, including what Rivet sees in its environment.

Proposing a patch to the session package is not a idea either. :)

Damon


> On Jan 31, 2018, at 1:59 PM, Brice Hamon  wrote:
> 
> Hi guys,
> 
> We ran into a small problem and wanted to share our findings.
> 
> We introduced http load balancers upstream of our apache servers to balance 
> the requests.
> 
> The result of this is that new user session were created randomly and that 
> was an issue for us.
> 
> The session package does a look up by IP and sessionID to identify a given 
> user. 
> But with the load balancers, the incoming IP is always the IP of one of the 
> LB.
> 
> So Rivet session was creating new session for that user, who was already 
> logged in.
> 
> We made a quick hack to disable the IP check and that solved the issue.
> We could have made the request sticky but we didn't want that in production.
> 
> So should we make this session lookup by IP and sessionID optional with some 
> type of flag?
> 
> Thank you
> Brice.


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: [VOTE] Release rivet 3.0.0

[Damon Courtney]

+1 from me. I’m going to implement it on some of my servers very soon. The new 
internals are VERY nice, good job, Massimo. :)

D


> On Jan 17, 2018, at 9:58 AM, Massimo Manghi  wrote:
> 
> Thank you Harald, Brice and Ronnie
> 
> George, David and Damon, will you express a vote anyway? Can I consider the 
> vote as closed?
> 
> -- Massimo
> 
> On 01/15/2018 03:32 PM, Harald Oehlmann wrote:
>> +1
>> Happy to be a friend ;-)
>> Harald
>> Am 15.01.2018 um 11:31 schrieb Massimo Manghi:
>>> Dear friends
>>> 
>>> I ask the PMC members to vote for releasing the artifact
>>> 
>>> http://www.rivetweb.org/~mxm/rivet/rivet-3.0.0rc1.tar.gz
>>> 
>>> as Rivet 3.0 GA software.
>>> 
>>> [ ] +1 OK
>>> [ ] 0  abstain
>>> [ ] -1 Needs more work
>>> 
>>>  -- Massimo
>>> 
>>> -
>>> 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: [VOTE] Release rivet 2.3.5

[Damon Courtney]

+1


> On Nov 7, 2017, at 10:05 AM, Massimo Manghi  wrote:
> 
> Please, PMC members, vote to release rivet-2.3.5rc2.tar.gz as GA software of 
> Rivet. The archive is located at
> 
> http://www.rivetweb.org/~mxm/rivet/
> 
> [ ] +1 OK
> [ ] 0  abstain
> [ ] -1 Needs more work
> 
>  -- Massimo
> 
> -
> 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: [VOTE] Release Apache Rivet 2.3.4

[Damon Courtney]

+1


> On Jul 26, 2017, at 9:09 AM, Massimo Manghi  wrote:
> 
> OK guys, PMC menbers please vote for releasing the artifact available from
> 
> http://www.rivetweb.org/~mxm/rivet/rivet-2.3.4rc1.tar.gz
> 
> as Apache Rivet 2.3.4 GA software. Please express you're vote as +1 for 
> releasing -1 not releasing it. The vote will be kept open for 3 days starting 
> from now. I will publish on the same location the cryptographic signatures 
> that I have on my home machine. Just allow a few more hours for me to get 
> back home
> 
> This release includes:
> 
> * various minor corrections/improvements in the manual
> * Tcl interpreters are re-seeded in order to have different random
> sequences generated
> * The form broker package now natively handles also boolean values
> 
> -- Massimo
> 
> -- 
> Università di Parma
> Dipartimento di Medicina e Chirurgia
> Unità di Neuroscienze
> via Volturno 39
> 43125 Parma
> 
> -
> 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: [VOTE] release rivet 2.3.3

[Damon Courtney]

Sorry, Massimo. With the Thanksgiving holiday this last week, I just didn’t get 
a chance to test it, and I didn’t want to sign off without having at least 
compiled and given it a run through.

Damon


> On Nov 28, 2016, at 4:51 PM, Massimo Manghi  wrote:
> 
> On 11/22/2016 10:17 AM, Massimo Manghi wrote:
>> On 11/21/2016 04:31 PM, Harald Oehlmann wrote:
>>> Great Massimo !
>>> Here is the download location:
>>> http://www.rivetweb.org/~mxm/rivet/
>>> Harald
>>> 
>> 
>> Thank you Harald for quoting the link
>> 
>> -- Massimo
>> 
> 
> We have meager harvest of 3 votes, enough for releasing as per the bylaws. 
> Even though this first vote on the public forum of rivet-dev deserved a 
> larger turnout rivet 2.3.3 is approved as GA software of Apache Tcl. I will 
> add the usual entry in the ChangeLog as only modification of the artifact 
> before uploading to the ASF distribution
> 
> -- Massimo
> 
> 
> 
> -
> 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::inspect and mod_rivet_ng

[Damon Courtney]

Also, I have no idea what my SVN credentials are, so I can’t commit anything. I 
don’t particularly want to deal with the bureaucracy of all that, so can I just 
submit a patch?

D


> On Nov 12, 2016, at 12:23 PM, Damon Courtney <da...@tclhome.com> wrote:
> 
> The first thing I see is that we need to set some of the defaults. We have 
> some duplicating going on that can be cleaned up.
> 
> Examples:
> 
> ErrorScript should default to ::Rivet::handle_error
> 
> AfterEveryScript should default to ::Rivet::cleanup_request
> 
> Rather than looking for those scripts and then using the ::Rivet defaults 
> when we don’t find out, we should just default those values in the module, 
> and then we don’t have to do any of that dance.
> 
> The only breaking change is that ::Rivet::cleanup_request is currently called 
> on every request even if AfterEverScript has been specified. This would call 
> for only one, which breaks backward compatibility, but I don’t think in a 
> really significant way. Most everyone should be using AfterEveryScript 
> instead of the older way of redefining procs anyway.
> 
> It looks like we’re going to call this Rivet 3.0, so now is the time to 
> reevaluate some old decisions and make changes. I don’t think this is a big 
> one or that controversial. I could be shouted down if someone cared enough 
> though. :)
> 
> D
> 
> 
>> On Nov 12, 2016, at 11:52 AM, Massimo Manghi <man...@biol.unipr.it> wrote:
>> 
>> now the code its ready. You need to recreate an init.tcl script by running 
>> ./configure with the appropriate arguments. The key switch is
>> 
>> ./configure ... --with-rivet-core=mod_rivet_ng
>> 
>> the Tcl stuff in init.tcl.in pertaining only mod_rivet_ng is comprised 
>> between the lines
>> 
>>  mod_rivet_ng specific 
>> 
>> .
>> 
>>  mod_rivet_ng specific 
>> 
>> everything else is untouched therefore it should be compatible also with the 
>> traditional default core module
>> 
>> I'm looking forward to read you comments
>> 
>> cheers
>> 
>> -- Massimo
>> 
>> 
>> 
>> On 11/12/2016 06:34 PM, Damon Courtney wrote:
>>> Sure thing.
>>> 
>>> 
> 


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: ::rivet::inspect and mod_rivet_ng

[Damon Courtney]

Sure thing.


> On Nov 12, 2016, at 11:29 AM, Massimo Manghi <man...@biol.unipr.it> wrote:
> 
> good, but since you are willing to lay your hands on this code,please hold on 
> an hour or two: I'm going to remove much of the surplus code still around in 
> mod_rivet_ng.
> 
> There are still a few calls to Tcl_EvalObjEx for procedures already defined 
> at Tcl level that can be safely called from ::Rivet::request_handling
> 
> -- Massimo
> 
> On 11/12/2016 06:20 PM, Damon Courtney wrote:
>> Never mind. I found it.
>> 
>> D
>> 
>> 
>>> On Nov 12, 2016, at 9:57 AM, Damon Courtney <da...@tclhome.com>
>>> wrote:
>>> 
>>> EVERYTHING is a string, Massimo!
>>> 
>>> I don’t think is a breaking change. I don’t imagine anyone is using
>>> the “undefined” behavior, and an empty string is definitely the
>>> right answer for Tcl.
>>> 
>>> Is there anywhere I can browse this code on the web? I think this
>>> will be a great change and simplification, and I’d like to see if I
>>> can contribute to the efforts.
>>> 
>>> Also, I’ll be at the Tcl Conference next week if anyone on here
>>> wants to hang out. :)
>>> 
>>> D
>>> 
>>> 
>>>> On Nov 12, 2016, at 5:42 AM, Massimo Manghi <mxman...@apache.org>
>>>> wrote:
>>>> 
>>>> Hi guys, I've been working on the new request processing model
>>>> and I hit a problem caused by a silly choice I did when I wrote
>>>> the ::rivet::inspect command.
>>>> 
>>>> I've figured out that deep in my soul after all I'm a reluctant
>>>> tcler: I haven't accepted nor understood some of the EIAS
>>>> paradigm consequences. For example
>>>> 
>>>> [::rivet::inspect BeforeScript] returns the script stored in
>>>> 
>>>> (*(rivet_server_conf*) Rivet_GetConf(s))->rivet_before_script
>>>> 
>>>> which can be NULL. It's customary to return an empty string at
>>>> Tcl level but in this case I though it could be meaningful to
>>>> treat a NULL and a (utterly unlikely) empty script differently
>>>> and decided to return the "undefined" string if the pointer was
>>>> not set. Silly.
>>>> 
>>>> The new central procedure for handling a request
>>>> (::Rivet::request_handling) has a call to this procedure at its
>>>> heart
>>>> 
>>>> proc url_handler {} {
>>>> 
>>>> set script ""
>>>> 
>>>> set before_script [::rivet::inspect BeforeScript] if
>>>> {$before_script == "undefined"} { set before_script "" }
>>>> 
>>>> set script [::rivet::url_script]
>>>> 
>>>> set after_script [::rivet::inspect AfterScript] if {$after_script
>>>> == "undefined"} {
>>>> 
>>>> set after_script ""
>>>> 
>>>> }
>>>> 
>>>> set script [join [list $before_script $script $after_script]
>>>> "\n"] return $script }
>>>> 
>>>> this procedure is evaluated at every request and along with
>>>> ::Rivet::request_handling overrides a few hundreds lines of C
>>>> language code. I would like to see those useless if conditions go
>>>> away and therefore I would change the inspect command in trunk in
>>>> order to have it return empty strings when a pointer is NULL. I
>>>> doubt that anyone around is depending on those "undefined" string
>>>> in their code so I'm pretty confident this is not breaking a big
>>>> deal of software
>>>> 
>>>> The mod_rivet_ng code is reaching a decent degree of maturity:
>>>> it's still breaking a few tests but I can already run some of my
>>>> applications on it. The core of the Tcl code evaluation is the
>>>> ::Rivet::request_handling (I establish the ::Rivet namespace as
>>>> the place for anything that should be considered 'critical' and
>>>> 'fundamental' to mod_rivet). This procedure reproduces the basic
>>>> scheme (by using a Tcl ::try construct)
>>>> 
>>>> *  (::Rivet::url_handler) - >>> execution> - 
>>>> 
>>>> * 
>>>> 
>>>> In principle you may override these procedure and further
>>>> simplify (or develop) the request processing following your
>>>> needs. The current version in the repository has a few debugging
>>>> 'puts' around that have to be removed if you want to try it
>>>> yourself.
>>>> 
>>>> saluti
>>>> 
>>>> -- Massimo


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: ::rivet::inspect and mod_rivet_ng

[Damon Courtney]

Never mind. I found it.

D


> On Nov 12, 2016, at 9:57 AM, Damon Courtney <da...@tclhome.com> wrote:
> 
> EVERYTHING is a string, Massimo!
> 
> I don’t think is a breaking change. I don’t imagine anyone is using the 
> “undefined” behavior, and an empty string is definitely the right answer for 
> Tcl.
> 
> Is there anywhere I can browse this code on the web? I think this will be a 
> great change and simplification, and I’d like to see if I can contribute to 
> the efforts.
> 
> Also, I’ll be at the Tcl Conference next week if anyone on here wants to hang 
> out. :)
> 
> D
> 
> 
>> On Nov 12, 2016, at 5:42 AM, Massimo Manghi <mxman...@apache.org> wrote:
>> 
>> Hi guys, I've been working on the new request processing model and I hit a 
>> problem caused by a silly choice I did when I wrote the ::rivet::inspect 
>> command.
>> 
>> I've figured out that deep in my soul after all I'm a reluctant tcler: I 
>> haven't accepted nor understood some of the EIAS paradigm consequences. For 
>> example
>> 
>> [::rivet::inspect BeforeScript] returns the script stored in
>> 
>> (*(rivet_server_conf*) Rivet_GetConf(s))->rivet_before_script
>> 
>> which can be NULL. It's customary to return an empty string at Tcl level but 
>> in this case I though it could be meaningful to treat a NULL and a (utterly 
>> unlikely) empty script differently and decided to return the "undefined" 
>> string if the pointer was not set. Silly.
>> 
>> The new central procedure for handling a request (::Rivet::request_handling) 
>> has a call to this procedure at its heart
>> 
>> proc url_handler {} {
>> 
>> set script ""
>> 
>> set before_script [::rivet::inspect BeforeScript]
>> if {$before_script == "undefined"} {
>> set before_script ""
>> }
>> 
>> set script [::rivet::url_script]
>> 
>>  set after_script [::rivet::inspect AfterScript]
>>  if {$after_script == "undefined"} {
>> 
>>   set after_script ""
>> 
>>}
>> 
>>  set script [join [list $before_script $script $after_script] "\n"]
>>  return $script
>> }
>> 
>> this procedure is evaluated at every request and along with 
>> ::Rivet::request_handling overrides a few hundreds lines of C language code. 
>> I would like to see those useless if conditions go away and therefore I 
>> would change the inspect command in trunk in order to have it return empty 
>> strings when a pointer is NULL. I doubt that anyone around is depending on 
>> those "undefined" string in their code so I'm pretty confident this is not 
>> breaking a big deal of software
>> 
>> The mod_rivet_ng code is reaching a decent degree of maturity: it's still 
>> breaking a few tests but I can already run some of my applications on it. 
>> The core of the Tcl code evaluation is the ::Rivet::request_handling (I 
>> establish the ::Rivet namespace as the place for anything that should be 
>> considered 'critical' and 'fundamental' to mod_rivet). This procedure 
>> reproduces the basic scheme (by using a Tcl ::try construct)
>> 
>> *  (::Rivet::url_handler)
>>  - 
>>  - 
>> 
>> * 
>> 
>> In principle you may override these procedure and further simplify (or 
>> develop) the request processing following your needs. The current version in 
>> the repository has a few debugging 'puts' around that have to be removed if 
>> you want to try it yourself.
>> 
>> saluti
>> 
>> -- Massimo
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> -
>> 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::inspect and mod_rivet_ng

[Damon Courtney]

EVERYTHING is a string, Massimo!

I don’t think is a breaking change. I don’t imagine anyone is using the 
“undefined” behavior, and an empty string is definitely the right answer for 
Tcl.

Is there anywhere I can browse this code on the web? I think this will be a 
great change and simplification, and I’d like to see if I can contribute to the 
efforts.

Also, I’ll be at the Tcl Conference next week if anyone on here wants to hang 
out. :)

D


> On Nov 12, 2016, at 5:42 AM, Massimo Manghi  wrote:
> 
> Hi guys, I've been working on the new request processing model and I hit a 
> problem caused by a silly choice I did when I wrote the ::rivet::inspect 
> command.
> 
> I've figured out that deep in my soul after all I'm a reluctant tcler: I 
> haven't accepted nor understood some of the EIAS paradigm consequences. For 
> example
> 
> [::rivet::inspect BeforeScript] returns the script stored in
> 
> (*(rivet_server_conf*) Rivet_GetConf(s))->rivet_before_script
> 
> which can be NULL. It's customary to return an empty string at Tcl level but 
> in this case I though it could be meaningful to treat a NULL and a (utterly 
> unlikely) empty script differently and decided to return the "undefined" 
> string if the pointer was not set. Silly.
> 
> The new central procedure for handling a request (::Rivet::request_handling) 
> has a call to this procedure at its heart
> 
> proc url_handler {} {
> 
>  set script ""
> 
>  set before_script [::rivet::inspect BeforeScript]
>  if {$before_script == "undefined"} {
>  set before_script ""
>  }
> 
>  set script [::rivet::url_script]
> 
>   set after_script [::rivet::inspect AfterScript]
>   if {$after_script == "undefined"} {
> 
>set after_script ""
> 
> }
> 
>   set script [join [list $before_script $script $after_script] "\n"]
>   return $script
> }
> 
> this procedure is evaluated at every request and along with 
> ::Rivet::request_handling overrides a few hundreds lines of C language code. 
> I would like to see those useless if conditions go away and therefore I would 
> change the inspect command in trunk in order to have it return empty strings 
> when a pointer is NULL. I doubt that anyone around is depending on those 
> "undefined" string in their code so I'm pretty confident this is not breaking 
> a big deal of software
> 
> The mod_rivet_ng code is reaching a decent degree of maturity: it's still 
> breaking a few tests but I can already run some of my applications on it. The 
> core of the Tcl code evaluation is the ::Rivet::request_handling (I establish 
> the ::Rivet namespace as the place for anything that should be considered 
> 'critical' and 'fundamental' to mod_rivet). This procedure reproduces the 
> basic scheme (by using a Tcl ::try construct)
> 
> *  (::Rivet::url_handler)
>   - 
>   - 
> 
> * 
> 
> In principle you may override these procedure and further simplify (or 
> develop) the request processing following your needs. The current version in 
> the repository has a few debugging 'puts' around that have to be removed if 
> you want to try it yourself.
> 
>  saluti
> 
> -- Massimo
> 
> 
> 
> 
> 
> 
> 
> -
> 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: a new script execution model for mod_rivet

[Damon Courtney]

Agreed. We’re probably not buying much in that C code except a lot more code 
for the same thing.

I’m like Massimo in that almost all of my recent projects have consisted of a 
single index.rvt in some directory along with a mod_rewrite call to that file 
to route the request. I didn’t use the various script declarations, I just put 
a call out in that file, but it’s the same idea. Mine looks something like this:



And then all the magic happens. :)

D


> On Sep 21, 2016, at 5:23 PM, Karl Lehenbauer  wrote:
> 
> I think this is a good idea.  All the C code this would replace probably 
> provides very little in terms of performance.
> 
> On 9/21/16, 4:03 PM, "Massimo Manghi"  wrote:
> 
>  I will carry on my analysis on this proposal and I will try as much as 
>  possible to isolate into a single file the code to be changed for having 
>  a working version of the model (unless fundamental incompatibilities 
>  emerge). If this is possible I will create a branch with it.
> 
>  I have to set it aside for a while now
> 
>-- Massimo
> 
>  On 09/19/2016 03:09 PM, Massimo Manghi wrote:
>> I've been thinking lately of a rather radical revision of the Tcl code
>> execution as it's done currently in mod_rivet. I haven't checked the
>> feasibility of every detail but I don't see fundamental and forbidding
>> obstacles to the implementation of such scheme.
>> 
>> Let's imagine to have mod_rivet replace the current C language machinery
>> of script evaluation by simply Tcl_Evaluating this script
>> 
>> try {
>>  
>> } trap {RIVET ABORTPAGE} {
>>  
>> } trap {RIVET THREAD_EXIT} {
>>  
>> } on error {::rivet::error_code ::rivet::error_options} {
>>  
>> } finally {
>>  
>> }
>> 
>> The script could be composed in memory from configuration information,
>> for example omitting the  trap or the 'finally' branch if
>> such handlers have not been set up. Also the error-script handler
>> determination could be done during the configuration stage and the
>> branch would be always existing al least with the default handler
>> 
>> The content generation script should by default be made by the
>> concatenation of the sequence
>> 
>> ::Rivet initialize_request
>> eval 
>> namespace eval ::request {  }
>> eval 
>> 
>> which reproduces the current execution sequence. The script referenced
>> in the URL could be stored in the module status and in case accessed by
>> introducing a new command, something like
>> 
>> eval [::rivet::url_script]
>> 
>> the command should in case fetch the script from the cache. So far I can
>> see only problems impacting the performance, as I expect the C language
>> machinery to be faster, but in this case not dramatically faster than
>> the 'tryfinally' construct (after all most requests are successfully
>> processed without errors. At least we hope so). Of course there are
>> possible optimizations like chaining the before-url-after scripts in one
>> script requiring a single call to Tcl_EvalObjEx
>> 
>> Perhaps I've been influenced by years of mod_rewrite usage where the
>> local path is analyzed and the transformation output blended into the
>> list of argument-value pairs to become the final URL query arguments. I
>> ended up having virtual hosts running websites with a single empty root
>> index.rvt and every template is parsed from the main application script.
>> Furthermore the content generation script is shared between different
>> applications and by no means resides in any directory tree pointed by
>> DocumentRoot directives. The bottom line is that the segmentation in 3
>> scripts has no meaning to me (..and for what I need also the URL
>> referenced script has no interest. But that's my approach...).
>> 
>> My point is that we could take a further step ahead and make the default
>> request processing script shown above entirely replaceable by a user
>> defined script (either based on try...on error...finally... or on any
>> other solutions the user would deem fit for their applications). Some
>> optimization could be attained by introducing some mechanism for
>> building such script by inclusion of the code, not simply sourcing or
>> parsing other files. The script could be kept in a special cache
>> providing some methods for determining its depends on the files it was
>> built from, in case one of them is modified requiring the buffer to be
>> refreshed.
>> 
>> opinions and criticism are welcome (...well, actually the latter are
>> less welcome, but don't be afraid ;-))
>> 
>> regards
>> 
>> -- Massimo
>> 
>> -
>> 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: Tcl exit command in mod_rivet

[Damon Courtney]

I think the ability to create the interp up front (on startup) is really 
useful. Yes, “lazy” creation of the interp on first request could be a thing 
too, but I think maybe we need a preference here. In my case, I’m currently 
doing “lazy” loading, not of the interpreters, but of my code. So, the first 
time a request comes in, it sees I haven’t “init’d” this interp, and does the 
initialization.

The problem with this approach is that the “init” can take a couple seconds 
with all the bits I’m loading in, which means the first person to hit a new 
interp is getting a really crappy experience. I would prefer to do all the init 
on startup of the child and interp so that the child isn’t really even ready to 
serve requests unless it has already gone through my init.

I’m not ENTIRELY sure what I’ve just said is relevant to this conversation. If 
not, pleas excuse me and just consider them the ramblings of an old man. :)

D


> On Sep 11, 2015, at 1:22 PM, Anton Osennikov  wrote:
> 
> 11.09.2015 14:18, Massimo Manghi пишет:
> 
>> Interpreters will be created and initialized only when the first request
>> for a specific virtual host comes in
> 
> I doubt that to initialize an intrepreter when request comes is a good 
> solution.
> 
> I'm running a custom rivet child init script now which creates child 
> interpreter for a virtual host on the first request for this virtual host, 
> and loads Tcl code into this interpreter via "source".
> 
> It worked good enough for years.
> 
> After upgrade from Tcl8.5 + Itcl3 to Tcl8.6 + Itcl4 some Tcl source files are 
> loaded many times (>50) slower now. These are modules that create hundreds 
> (about 500) of Itcl objects. These objects describe implemented report items: 
> tables, columns, charts, etc.
> 
> As a possible workaround I'm looking for a way to pre-load my sources before 
> actual request comes now..
> 
> "source" times demo:
> 
> $ tclsh8.5
> % package require nemoweb
> 1178 us source -encoding utf-8 
> /opt/ActiveTcl-8.5/lib/teapot/package/tcl/teapot/tcl8/8.2/cmdline-1.5.tm 
> [27252]
> ...
> 39897 us source /usr/local/lib/nemo/nemoweb.tcl [27252]
> 2.6b3
> %
> 
> $  tclsh8.6
> % package require nemoweb
> 1150 us source -encoding utf-8 
> /opt/ActiveTcl-8.6/lib/teapot/package/tcl/teapot/tcl8/8.2/cmdline-1.5.tm 
> [27512]
> /..
> 2947621 us source /usr/local/lib/nemo/nemoweb.tcl [27512]
> 2.6b3
> %
> 
> -- 
> Best regards, Anton.
> 
> 
> -
> 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: Tcl exit command in mod_rivet

[Damon Courtney]

I’m with Anton here. I don’t think [exit] within a Rivet interp should be 
possible. It’s just not something you should be doing, and in almost all cases, 
you’re not doing what you think you’re doing.

I learned this hard lesson back in the NeoWebScript days. I would call [exit] 
to terminate serving the page, and it worked! It worked exactly like I hoped it 
would. What I didn’t understand was that I was causing the entire child to 
exit. Of course I was. I just didn’t know it because I hadn’t thought it 
through.

Most of the time when you want to exit a Rivet request, what you really want is 
to just stop serving the request and bail. But going to all the trouble to exit 
the interp and kill off the child in the proper way sounds unnecessary.

D


> On Sep 11, 2015, at 12:51 PM, Anton Osennikov  wrote:
> 
> 11.09.2015 14:18, Massimo Manghi пишет:
> 
>> Then, in order to mitigate the possible interpreter
>> termination/initialization storm that might ensue an inappropriate usage
>> of the 'exit' command
> 
> But what's the known *appropriate* usage of the 'exit' command inside rivet?
> 
> If there isn't one, maybe just code something like
> 
> ###
> 
> rename exit _exit
> 
> proc exit {args} {
>  error "application error: 'exit' called inside (threaded) Rivet application"
> }
> 
> -- 
> Best regards, Anton.
> 
> 
> -
> 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: load_response does what ?

[Damon Courtney]

It will all depend where the command is run, yes. The cleanest way to do it 
per-request is to use:

load_response ::request::response

Which will give you an array called response within your request namespace that 
automatically gets cleaned up after the request is served.

And, yes, load_response was originally thrown in as a compatibility command for 
NeoWebScript, but it really should have gone into the NWS compat library that 
we initially built. It’s still a nice convenience command, but given that it 
can sometimes create the array in confusing places (as seen here), it can be a 
little tricky.


 On Jun 17, 2015, at 4:52 PM, Massimo Manghi mxman...@apache.org wrote:
 
 On 06/17/2015 10:29 PM, Paolo Bevilacqua wrote:
 On Wed, Jun 17, 2015, at 04:43 PM, Damon Courtney wrote:
 I think we’ve found your problem. More information is always better. :)
 
 parray prints the array contents directly, it DOES NOT return a value.
 So, if you’re logging this to a log file, you will see nothing from
 parray.
 
 If you want to see what’s in an array, use
 
 puts $log [array get response]
 
 
 Of course. I must have left brain in parking.
 Interesting, load_response seems to keep adding data to the array, so
 'unset' is needed before calling Will work on that.
 Thanks Damon!
 iAlways striving to honor my word and commitments/i
 
 if you're running your script as a .tcl file then variables are created by 
 default in the global namespace, therefore they survive after a request is 
 processed. Moreover load_response was originally designed (and modified) so 
 that it behaved like the same command in NeoWebScript, a Tcl based scripting 
 environment that partially spurred the creation of Rivet (Damon and David can 
 be more accurate on this)
 
 I suggest you read the code in rivet/rivet-tcl/load_response.tcl, it's quite 
 simple
 
 now, what is the output once you fixed your test script?
 
 
 -- Massimo
 
 -
 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: load_response does what ?

[Damon Courtney]

I think we’ve found your problem. More information is always better. :)

parray prints the array contents directly, it DOES NOT return a value. So, if 
you’re logging this to a log file, you will see nothing from parray.

If you want to see what’s in an array, use

puts $log [array get response]

D


 On Jun 16, 2015, at 3:55 PM, Paolo Bevilacqua pbev...@fastmail.fm wrote:
 
 On Tue, Jun 16, 2015, at 10:55 AM, Massimo Manghi wrote:
 Just another test:
 
  replace
 
 ::rivet::var_post all
 
 with its unspecific counterpart
 
 ::rivet::var all
 
 is the output following the load_response line produced by
 ::rivet::parray?
 
 
 Below the output of all the four commands involved.
 For load_response I use
 ::rivet::load_response
 puts $log [parray response]
 
 because the output goes to a log file, not to a web page.
 
 Tue, 16-Jun-15 20:50:51 GMT raw_post -- destInProgress=99836238
 99130541 99064427 99102364 99005874 99410866 99821835 99582866 99635303
 99064748 99013514 99021301 99388471 99800788 99300255 99520863 99131362
 99733075 99685502 99388323 99624142 99572283 99850671 99834076 99754363
 99760843 99434675 99862175 99035851 99122540 99343247 99714766 99427236
 99568383 99041544 99302051 99146736 99767163 99270437 99607703 99087126
 99486428 99235447 99380185 99640205 99413881 99834102 99875851 99400545
 99272852 99732447 9914 99256107 99377023 99435352 99383574 99145625
 99282660 99682457 99331846 99484343 99636382 99425872 99716257 99740721
 99550623 99760873 99552013 99383514 99010646 99118430 99531358 99862450
 99610030 99551835 99265428 99826335 99022071 99872488 99031225 99053157
 99363604 99260428 99100014 99112310 99343052 99871531 99531367 99083124
 99441458 99083043 99572337 99645868 99344182 99262534 99085144 99502782
 99574440 99544804 99550807 99707218 99142587 99734580 99230725 99423882
 99213401 99738226 99265052 99302503 99813252 99503212operReady=CB57
 5B0D 410B 780B D7A5 4589 F832 AF51 6D39 248A D08D 86B0 563C 85BD ADFC
 80F9 F9FC ABE1 2FC7 BBB6 B72C 19C3 F59D 56CD 5194 D35A FFF3 74C9 EB2F
 B196 2F74 E0A5 5D29 C7A1 171C C78C 7A32 873F E2CF 07D7 75C3 7391 7715
 09FF FA3E 76A9 A8DC 3A13 C48B 5D2F 21BE 3925 72AB 55AB
 F887operConn=50E8 8543 D7C6 2218 8266 493C 2709 1E65
 50E1operRest=stats=noOp 0 dup 0 failCnt 35 httpErrCnt 0 setupCnt 155
 answerVM 13 connectCnt 9
 Tue, 16-Jun-15 20:50:51 GMT load_response --
 Tue, 16-Jun-15 20:50:51 GMT var_post all -- destInProgress {99836238
 99130541 99064427 99102364 99005874 99410866 99821835 99582866 99635303
 99064748 99013514 99021301 99388471 99800788 99300255 99520863 99131362
 99733075 99685502 99388323 99624142 99572283 99850671 99834076 99754363
 99760843 99434675 99862175 99035851 99122540 99343247 99714766 99427236
 99568383 99041544 99302051 99146736 99767163 99270437 99607703 99087126
 99486428 99235447 99380185 99640205 99413881 99834102 99875851 99400545
 99272852 99732447 9914 99256107 99377023 99435352 99383574 99145625
 99282660 99682457 99331846 99484343 99636382 99425872 99716257 99740721
 99550623 99760873 99552013 99383514 99010646 99118430 99531358 99862450
 99610030 99551835 99265428 99826335 99022071 99872488 99031225 99053157
 99363604 99260428 99100014 99112310 99343052 99871531 99531367 99083124
 99441458 99083043 99572337 99645868 99344182 99262534 99085144 99502782
 99574440 99544804 99550807 99707218 99142587 99734580 99230725 99423882
 99213401 99738226 99265052 99302503 99813252 99503212} operReady {CB57
 5B0D 410B 780B D7A5 4589 F832 AF51 6D39 248A D08D 86B0 563C 85BD ADFC
 80F9 F9FC ABE1 2FC7 BBB6 B72C 19C3 F59D 56CD 5194 D35A FFF3 74C9 EB2F
 B196 2F74 E0A5 5D29 C7A1 171C C78C 7A32 873F E2CF 07D7 75C3 7391 7715
 09FF FA3E 76A9 A8DC 3A13 C48B 5D2F 21BE 3925 72AB 55AB F887} operConn
 {50E8 8543 D7C6 2218 8266 493C 2709 1E65 50E1} operRest {} stats {noOp 0
 dup 0 failCnt 35 httpErrCnt 0 setupCnt 155 answerVM 13 connectCnt 9}
 Tue, 16-Jun-15 20:50:51 GMT var all -- destInProgress {99836238
 99130541 99064427 99102364 99005874 99410866 99821835 99582866 99635303
 99064748 99013514 99021301 99388471 99800788 99300255 99520863 99131362
 99733075 99685502 99388323 99624142 99572283 99850671 99834076 99754363
 99760843 99434675 99862175 99035851 99122540 99343247 99714766 99427236
 99568383 99041544 99302051 99146736 99767163 99270437 99607703 99087126
 99486428 99235447 99380185 99640205 99413881 99834102 99875851 99400545
 99272852 99732447 9914 99256107 99377023 99435352 99383574 99145625
 99282660 99682457 99331846 99484343 99636382 99425872 99716257 99740721
 99550623 99760873 99552013 99383514 99010646 99118430 99531358 99862450
 99610030 99551835 99265428 99826335 99022071 99872488 99031225 99053157
 99363604 99260428 99100014 99112310 99343052 99871531 99531367 99083124
 99441458 99083043 99572337 99645868 99344182 99262534 99085144 99502782
 99574440 99544804 99550807 99707218 99142587 99734580 99230725 99423882
 99213401 99738226 99265052 99302503 99813252 99503212} operReady {CB57
 5B0D 410B 780B 

Re: rivet error handling

[Damon Courtney]

 but it should be treated as an opaque structure for compatibility
 
 ::rvterr code $err_object
 ==
 redirect
 ::rvterr exists location
 == 1
 ::rvterr get var1
 ==
 url
 
 the dictionary itself is good but it doesn't encourage standardization
 and compatibility if it's not concealed within some interface

If you really, really want to create a separate command for checking errors, 
then ::rivet::err seems the likely candidate. This is Tcl, we’re not here to 
save a couple extra vowels. :)

That said, I don’t really know that you need it. Tcl’s ::errorCode variable is 
exactly what we’re talking about here, and it’s nothing more than a list with a 
CODE + some extras. Returning a dict is a perfectly Tcl’ish thing to do.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: new command redir and optimized buffer flushing

[Damon Courtney]

Forgive me, I’m not familiar with the internals of the code anymore, but I’m 
working on getting back up to speed.

What’s in the src/apache-2 directory that we’re dropping?

D


 On Dec 18, 2014, at 10:30 AM, Massimo Manghi mxman...@apache.org wrote:
 
 I had no feedback on my proposal of dropping trunk/src/apache-2. If nobody 
 opposes it (with a motivation ) I'm going to proceed soon
 
 -- Massimo
 
 Il 17/Dic/2014 11:31 Massimo Manghi massimo.man...@unipr.it 
 mailto:massimo.man...@unipr.it ha scritto:
 Hi
 
 I committed yesterday night (natürlich CET) the new ::rivet::redirect command 
 (thanks Damon for the swift and elegant solution!) and changed the buffer 
 flush centralizing the time when mod_rivet actually sends data to the very 
 last few lines before returning from Rivet_SendContent.
 
  I tested it and now you can redirect any time provided you haven't called 
 flush stdout either explicitly or implicitly by filling the I/O buffer
 
  I will port this improvements to branches/2.2, definitely. I ask for your 
 opinion on abandoning the code in src/apache-2 (which will be preserved in 
 branches/2.2 anyway) and promote the code to experimental as mainstream 
 development of mod_rivet (labeled 2.3.0)
 
  regards
 
  -- Massimo
 
 
 -
 To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org 
 mailto:rivet-dev-unsubscr...@tcl.apache.org
 For additional commands, e-mail: rivet-dev-h...@tcl.apache.org 
 mailto:rivet-dev-h...@tcl.apache.org
 

Re: To stay or not to stay [was: Hi. A suggestion.]

[Damon Courtney]

Tcl is not a popular language. It’s not GOING to be a popular language. Nothing 
we do in Rivet will change that. Although, Rails made Ruby popular, so who 
knows. I don’t care. I use what I like and will continue to do so.

The point was simply that the open source world is much more vibrant in places 
NOT ruled by bureaucracy. No, we’re not going to get a herd of programmers take 
a look at Rivet by going somewhere else, but having everyone jump through 
stupid hoops to even try can’t help. I’ll admit that this is purely 
self-serving on my part. I don’t want to have to jump through the stupid hoops 
either. Not when I can just grab any project off Github that I want and start 
working in minutes.

I suppose the Apache project lends some credibility (for some), but I don’t see 
it much these days. Any project that wants to attract attention now lives on 
Github. Do we really want to keep voting and submitting quarterly updates about 
how nothing is really happening? Or getting chastised for not sending said 
reports?

Also, holy shit, are we still f*cking using Subversion?! This makes the whole 
Apache Project look like asshats. Ridiculous.

D


 On Dec 18, 2014, at 3:40 AM, David Welton dav...@dedasys.com wrote:
 
 ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
 became tailored to let many large projects coexist. I wasn't a committer or
 member in the early times, but I always thought ASF was a collection of
 projects which had at the center the Apache HTTP Web Server. Apache Tcl fits
 exactly this model, and it would all the more so if we consider also the
 projects we dropped because unmaintained (mod_tcl, etc). But the web server
 (despite being still central for the Internet at large) is not the core of
 ASF anymore. There are ~150 projects in ASF, some of them really, really big
 and with large and thriving communities. I was impressed by the number of
 top level projects Apache Hadoop gave birth. We don't fit this picture
 anymore, unquestionable. Recently on the board list someone pointed out that
 Apache never accepted umbrella projects in order to have a more timely and
 accountable management. Well...Apache Tcl is an umbrella project, we
 declared it at the beginning of our home page, in very first statement.
 Definitely we are misplaced if you see it this way.
 
 I think at one point, being associated with the Apache web server had
 some cachet.  These days, most Apache projects are Java things that
 don't have any cross over with the web server, Tcl or Rivet.
 
 The rigidity and process and all that are a good thing for companies
 who want to interact with Apache, as there's a predictable, mostly
 friendly model for how things work, that produces code without legal
 issues.  I don't think those are advantages for Rivet.
 
 On the other hand we are tightly connected to the Apache web server and I
 see some danger ahead. It happened to me recently to show a young engineer a
 project I did using Rivet and Tcl. He didn't know of Tcl and became
 suspicious of it. I could only mitigate his perplexity when I showed Rivet
 is developed under the hat of ASF. Branding is a key problem, also in the
 Open Source world.
 
 Interesting - what kind of background does he have in terms of programming?
 
 OTOH, I'm not exactly sure there are vast herds of programmers just
 milling around waiting to start contributing to Rivet if only it
 weren't under the yoke of the ASF, either
 
 -- 
 David N. Welton
 
 http://www.dedasys.com/


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: To stay or not to stay [was: Hi. A suggestion.]

[Damon Courtney]

So, the message I’m getting is that I’m the only one here. :) That’s cool. Just 
throwing it out there as a suggestion.

Massimo is right that there should probably be a lot more sharing of what we’re 
working on. Honestly, though, I think one of the reasons we don’t hear much 
about Tcl (and, by extension, Rivet) is because all of the people using it are 
probably in the “I’m too old to brag about shit, I’m just here to get my work 
done” crowd. That’s my inclination anyway.

I’ve done a lot of work in Rivet. I’ve been working with Tcl in one form or 
another for the last 20 years (thanks, Karl!). I just don’t have much time for 
showing everyone, explaining it, and then supporting it for others who want to 
use it. That’s probably a selfish attitude, but I’ve been screwed by the open 
source crowd before. The whole “stone soup” idea is great, and I still believe 
in it, but more often than not, I see one or two people doing the work and 
everyone else complaining.

Sorry, that’s a bit of rant I didn’t mean to get off on. Yes, we should show 
off some of the stuff we’ve been working on. I know Flightaware has a repo on 
GitHub where the post some of their cool stuff. I’ve got a whole MVC framework 
I built in Rivet that I’m not ready to show wide, and it probably sucks, but I 
really like it. :)

Maybe we need a place on the website that points to projects connected to 
Rivet. Just a title and a link (probably to a GitHub repo) is good, but maybe a 
short description of the project as well.

Or, maybe we’re all gettin’ too old for this shit.

D


 On Dec 18, 2014, at 1:38 PM, Jeff Lawson j...@bovine.net wrote:
 
 I do think that the Apache relationship improves the perception of the 
 project to outsiders in a positive way, and separating would potentially 
 cause new users to have greater skepticism about Rivet. Also, just having to 
 explain the fact that it is no longer an Apache project could be perceived 
 slightly negatively.
 
 Some Apache projects choose to use git instead of subversion, which might 
 make it easier for other users to submit code changes via pull requests:
 https://git-wip-us.apache.org/ https://git-wip-us.apache.org/ 
 
 
 On Thu, Dec 18, 2014 at 11:05 AM, Damon Courtney da...@tclhome.com 
 mailto:da...@tclhome.com wrote:
 Tcl is not a popular language. It’s not GOING to be a popular language. 
 Nothing we do in Rivet will change that. Although, Rails made Ruby popular, 
 so who knows. I don’t care. I use what I like and will continue to do so.
 
 The point was simply that the open source world is much more vibrant in 
 places NOT ruled by bureaucracy. No, we’re not going to get a herd of 
 programmers take a look at Rivet by going somewhere else, but having everyone 
 jump through stupid hoops to even try can’t help. I’ll admit that this is 
 purely self-serving on my part. I don’t want to have to jump through the 
 stupid hoops either. Not when I can just grab any project off Github that I 
 want and start working in minutes.
 
 I suppose the Apache project lends some credibility (for some), but I don’t 
 see it much these days. Any project that wants to attract attention now lives 
 on Github. Do we really want to keep voting and submitting quarterly updates 
 about how nothing is really happening? Or getting chastised for not sending 
 said reports?
 
 Also, holy shit, are we still f*cking using Subversion?! This makes the whole 
 Apache Project look like asshats. Ridiculous.
 
 D
 
 
  On Dec 18, 2014, at 3:40 AM, David Welton dav...@dedasys.com 
  mailto:dav...@dedasys.com wrote:
 
  ASF is somewhat bureaucratic and rigid, no doubt. It's grown a lot and
  became tailored to let many large projects coexist. I wasn't a committer or
  member in the early times, but I always thought ASF was a collection of
  projects which had at the center the Apache HTTP Web Server. Apache Tcl 
  fits
  exactly this model, and it would all the more so if we consider also the
  projects we dropped because unmaintained (mod_tcl, etc). But the web server
  (despite being still central for the Internet at large) is not the core of
  ASF anymore. There are ~150 projects in ASF, some of them really, really 
  big
  and with large and thriving communities. I was impressed by the number of
  top level projects Apache Hadoop gave birth. We don't fit this picture
  anymore, unquestionable. Recently on the board list someone pointed out 
  that
  Apache never accepted umbrella projects in order to have a more timely and
  accountable management. Well...Apache Tcl is an umbrella project, we
  declared it at the beginning of our home page, in very first statement.
  Definitely we are misplaced if you see it this way.
 
  I think at one point, being associated with the Apache web server had
  some cachet.  These days, most Apache projects are Java things that
  don't have any cross over with the web server, Tcl or Rivet.
 
  The rigidity and process and all that are a good thing for companies
  who want

Re: Hi. A suggestion.

[Damon Courtney]

I’m guessing the reason we don’t get an error is because of the [no_body] 
command in there, so the error isn’t getting output. I would suggest adding a 
[headers sent] command that simply returns whether the headers have gone out 
already, and then we use that in ::rivet::redirect to return an error.

The [headers] command has the correct behavior that errors out when the headers 
have already been sent, but we’ve now prevented the error from displaying to 
the user.

Also, looking at the code, I think we have a discrepancy in the [headers] 
command. The docs imply that most of the arguments to the command are optional, 
but the code says otherwise. For example, the docs say:

headers set ?headername? ?value?

The ?’s imply that both headername and value are optional arguments. I read 
that to mean that [headers set] by itself will probably return a dict of 
headers (it doesn’t), and [headers set Some-Header] will return the current 
value of the Some-Header header (it doesn’t).

Changing the docs is the quickest course of action. HOWEVER, it is a very 
Tcl’ish thing to do to have the kind of introspection that would be provided by 
making the headers command arguments actually be optional with the behavior 
I’ve described above.

Anyone know what stupid-ass process I have to go through to get committer 
access with Apache? I haven’t been a committer in a long, long time, but I’ve 
been working pretty steadily in Rivet for a few years now, and there are nits I 
would love to fix. I hate that Massimo is the only guy who’s ever in the code. 
I should get my hands dirty. :)

D


 On Dec 17, 2014, at 10:08 AM, Massimo Manghi mxman...@apache.org wrote:
 
 There is an implication in using 'headers numeric 302' with the buffer
 control handling.
 
 I don't see any need for reducing the channel buffer size (especially
 since the rivet channel handling was modified in order to have a single
 channel per thread) but I tested the case where the buffer size was
 shrunk to a length short enough to cause several buffer outputs on a
 single page. I put a conditional redirect near the end of the page and
 triggered the redirection. The page don't divert (because headers had
 been flushed already), it stops outputting data, but it doesn't fail either.
 
 What the behavior we expect in this case (it would imply we should call?
 I would expect the page to fail or return a some special code in order
 to give us a chance to abort redirection and maybe take some action.
 
 What do you think?
 
 -- Massimo
 
 
 On 12/15/2014 11:00 PM, Damon Courtney wrote:
 I had thought about that. I would vote for something extensible like a dict 
 with a required field.
 
 ## For a straight abort_page
 set d [dict create]
 dict set d error_code “abort”
 
 ## For a redirect
 set d [dict create]
 dict set d error_code “redirect”
 dict set d location [headers set Location]
 
 Or whatever. error_code being very Tcl’ish and the only required value. The 
 others are dependent on the error_code value. It’s simple, and we can add 
 other codes with other information later.
 
 D
 
 
 -
 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: Hi. A suggestion.

[Damon Courtney]

Which actually brings up something I’ve been thinking about for a while.

Do we want to keep Rivet under the Apache umbrella? Do we gain anything from 
being an Apache project, really? Or is it just a lot of bureaucracy we have to 
suffer through?

My feeling is the latter. :(

D


 On Dec 17, 2014, at 11:05 AM, David Welton dav...@dedasys.com wrote:
 
 Anyone know what stupid-ass process I have to go through to get committer 
 access with Apache? I haven’t been a committer in a long, long time, but 
 I’ve been working pretty steadily in Rivet for a few years now, and there 
 are nits I would love to fix. I hate that Massimo is the only guy who’s ever 
 in the code. I should get my hands dirty. :)
 
 Glad to hear it!  I'm sure Massimo would love some company.
 
 http://people.apache.org/committer-index.html#damonc shows you as
 still being an ASF member, committter, etc
 
 Hopefully it's just a matter of restoring your login credentials.
 
 -- 
 David N. Welton
 
 http://www.dedasys.com/


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Hi. A suggestion.

[Damon Courtney]

Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a 
flush of the output. We should fix that.

I also agree that redirect should cause an abort (or something like it). I 
already do that in my own code, as it makes no sense to redirect and then keep 
processing. It could potentially cause some seriously confusing bugs. We could 
be more elegant about it in the C code, but here’s a version of the proc I use 
we could include:

proc ::rivet::redirect {url {permanent 0}} {
no_body ; ## don’t output anything on a redirect
headers set Location $url
headers numeric [expr {$permanent ? 301 : 302}]
abort_page ; ## stop any further processing
}

Damon


 On Dec 15, 2014, at 11:43 AM, Massimo Manghi massimo.man...@unipr.it wrote:
 
 I probably didn't express this point in an impeccable way. Let me rephrase it
 
 Even though Tcl_Flush (and implicitly the output method of Rivet channel) 
 could be called when everything is done just before returning to Apache (true 
 for most web pages), as a matter of fact parsing a subtemplate causes the 
 same call to Tcl to occur and therefore becomes impossible in this case to 
 change the headers. This is incoherent and fuzzy and should be fixed
 
 I hope the rest of my message is understandable.
 
 -- Massimo
 
 
 On 12/15/2014 04:13 PM, Massimo Manghi wrote:
 I take it and I don't want you to leave the discussion ;)
 
 I've been repeating with Rani the same point every time he brought it
 up: redirection should be done ASAP and before sending any data to the
 stdout. I maintain that for any sensible page (most web pages size is
 well  100) data are sent when mod_rivet calls Tcl_Flush, therefore
 redirection can occur before that point, but it's not true every case.
 Rivet_ExecuteAndCheck calls Tcl_Flush which in turn causes Rivet
 channel's output procedure to be called by Tcl. And this happens also
 when the ::rivet::parse command is called (which calls
 Rivet_ParseExecFile and then Rivet_ExecuteAndCheck)
 

Re: Hi. A suggestion.

[Damon Courtney]

I would just abort with “redirect”. If they want the location, they can call 
[headers set Location] to get it.


 On Dec 15, 2014, at 3:09 PM, Massimo Manghi mxman...@apache.org wrote:
 
 Oh great thanks, I'm going to put in trunk and branches/2.2 right away.
 
 starting with 2.1 IIRC ::rivet::abort_page supports an optional code as
 argument, so that any AbortScript can figure out what caused the page to
 abort. Any Tcl object could work as argument (even a dictionary). Do you
 have suggestion?
 
 -- Massimo
 
 On 12/15/2014 06:51 PM, Damon Courtney wrote:
 Don’t worry, I got it. :) And, I agree. I didn’t realize parse was doing a 
 flush of the output. We should fix that.
 
 I also agree that redirect should cause an abort (or something like
 it). I already do that in my own code, as it makes no sense to
 redirect and then keep processing. It could potentially cause some
 seriously confusing bugs. We could be more elegant about it in the C
 code, but here’s a version of the proc I use we could include:
 
 proc ::rivet::redirect {url {permanent 0}} {
no_body ; ## don’t output anything on a redirect
headers set Location $url
headers numeric [expr {$permanent ? 301 : 302}]
abort_page ; ## stop any further processing
 }
 
 Damon
 
 
 -
 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: Hi. A suggestion.

[Damon Courtney]

Well, it’s a new command, so I would suggest changing it. I find that in most 
cases of a modern web app, you’re doing a temporary redirect, not a permanent. 
301 was really messing me up because the browser would cache it, and then I’d 
have to blow away my cache to make things work again.

So, I would humbly suggest we leave that command just like it is. The [headers 
redirect] can keep the same semantics for backward compatibility.


 On Dec 15, 2014, at 3:13 PM, Massimo Manghi mxman...@apache.org wrote:
 
 The 301 (http://en.wikipedia.org/wiki/HTTP_301) is the permanent
 redirection so, in order to keep the 'permanent' semantics consistent,
 the default must be 1
 
 -- Massimo
 
 On 12/15/2014 06:51 PM, Damon Courtney wrote:
 
 proc ::rivet::redirect {url {permanent 0}} {
no_body ; ## don’t output anything on a redirect
headers set Location $url
headers numeric [expr {$permanent ? 301 : 302}]
abort_page ; ## stop any further processing
 }
 
 Damon
 
 
 
 -
 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: Hi. A suggestion.

[Damon Courtney]

Can’t we just call [abort_page “redirect”] from the proc instead of without an 
argument? Then at least someone can check the abort code in their script to see 
that it’s a redirect and ignore it. Seems like a pretty reasonable idea. :)

D


 On Dec 15, 2014, at 3:43 PM, Massimo Manghi mxman...@apache.org wrote:
 
 AbortScript could serve several different reasons for interrupting
 processing depending on the result returned by [::rivet::abort_code]. I
 will leave it without argument because it's harmless, but it could be a
 good reason for thinking of a 'rivet scheme' for encoding these
 exceptions in the abort_page argument. They can get the URL from
 Location but they need to know why execution got there in the first place
 
 -- M
 
 On 12/15/2014 10:20 PM, Damon Courtney wrote:
 I would just abort with “redirect”. If they want the location, they can call 
 [headers set Location] to get it.
 
 
 
 -
 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: Hi. A suggestion.

[Damon Courtney]

I had thought about that. I would vote for something extensible like a dict 
with a required field.

## For a straight abort_page
set d [dict create]
dict set d error_code “abort”

## For a redirect
set d [dict create]
dict set d error_code “redirect”
dict set d location [headers set Location]

Or whatever. error_code being very Tcl’ish and the only required value. The 
others are dependent on the error_code value. It’s simple, and we can add other 
codes with other information later.

D


 On Dec 15, 2014, at 3:54 PM, Massimo Manghi mxman...@apache.org wrote:
 
 In fact, I was just afraid that rushing a decision would spoil a more
 elegant way of encoding this (and other) conditions
 
 -- Massimo
 
 On 12/15/2014 10:51 PM, Damon Courtney wrote:
 Can’t we just call [abort_page “redirect”] from the proc instead of
 without an argument? Then at least someone can check the abort code
 in their script to see that it’s a redirect and ignore it. Seems like
 a pretty reasonable idea. :)
 
 D
 
 
 


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Hi. A suggestion.

[Damon Courtney]

The channel mechanism is actually quite flexible out of the box. Anything Tcl 
lets you do, you can do with the stdout channel in Rivet. For example:

fconfigure stdout -buffersize 100 -buffering full

And you have almost a megabyte of output before the channel will flush (unless 
you [flush stdout] yourself).

I know that having to output the headers before any data can be annoying 
sometimes, but it’s really the proper way to do it. If you’re going to redirect 
to another page, you should have done so LONG before you output any data. In my 
case, I’m using a pretty standard MVC model where the controller determines 
that a redirect is required before the view is ever rendered.

If we wanted to try and support his proposal, we could alter the [headers 
redirect] command, and if headers have already been sent, then we output the 
meta tag, but this has its problems as well. Though most browsers would 
probably let it slide, the meta tag should really be inside the head of the 
page. So, once again, you have a limitation.

Just my thoughts, take ‘em or leave ‘em. :)

D


 On Dec 13, 2014, at 4:50 AM, Massimo Manghi mxman...@apache.org wrote:
 
 Rani Ahmad gave me permission to forward to rivet-dev his proposal for an 
 alternate way to force redirection to a different URL using the meta  
 tag. Rani claims this approach could attain the same effect while preventing 
 the scripts from failing with the headers already sent error. It still 
 makes sense that a script which could issue a redirect has in principle to 
 determine whether to divert to a different URL *before* any output is sent to 
 the channel. admittedly this is rigid because forces a certain design (though 
 a sane one), it's largely undocumented and in the end there should be a 
 better more flexible way to do this
 
 We obtain redirection with the 301 HTTP code and when the headers command is 
 called the code checks for the headers_sent flag
 
 TCL_CMD_HEADER( Rivet_Headers )
 {
  ...
 if (globals-req-headers_printed != 0)
 {
 Tcl_AddObjErrorInfo(interp ,Cannot manipulate headers - already 
 sent, -1);
 return TCL_ERROR;
 }
  
 globals-req-headers_printed is set when the Rivet channel output procedure 
 is called by Tcl I/O subsystem and I wonder if there are different ways to do 
 it, for example making the channel implementation more flexible about 
 buffering. Of course this doesn't rule out the possibility of exploiting 
 other ways (like in Rani's proposal), but it seems to me the HTTP protocol 
 has to be supported in the best possible way
 
   -- Massimo
 
 -- Forwarded message --
 From: Rani Ahmed rani...@gmail.com mailto:rani...@gmail.com
 Date: Thu, Dec 11, 2014 at 8:37 PM
 Subject: Hi. A suggestion.
 To: Massimo Manghi mxman...@apache.org mailto:mxman...@apache.org
 
 Hi Massimo. 
 
 Well  I suggest that you add a better redirect function/procedure other than 
 the [headers redirect $url ] . This one always makes many people go into the 
 annoying error message of headers already sent .
 
 The procedure will be the following, I found it on Stackoverflow. I 
 understand that I can put it for my own, but this little thing  - I think - 
 can be the key that makes Rivet attractive.
 
 proc http_redirect { url } {
 
 ?
  meta http-equiv=refresh content=0;url='?=$url;?'
 ?
 
 }

Re: file name returned by info script

[Damon Courtney]

 I would suggest that for now we leave the [info script] behavior 
 alone.  It doesn’t hurt anyone that I can see, and it would break
 
 do you mean you want to keep that ugly hack in Rivet_SendContent?

If you want to remove it, I’m fine with that.  Just know that it creates an 
incompatibility.  Now, what are the chances someone is using [info script] in 
Rivet to determine the .rvt file path?  Probably slim to none seeing as [env 
SCRIPT_FILENAME] would be the more common method.  All that said, it’s probably 
easier to just remove the hack and then stop trying to hack [info script] at 
all.  If you want info about your Rivet request, use ::rivet::inspect.  And 
then push people toward that in the docs.


 we have ::rivet::inspect now (whose manual page needs further
 elaboration). It's easy to place those variables in a new dictionary
 returned by it.
 
 I chose the name 'inspect' to avoid conflict with 'info'. I new core
 commands were in the namespace ::tcl but I didn't know they were an
 ensemble and, as a matter of fact, I didn't know of the -map option of
 namespace configure either

I forgot about inspect.  We should continue to enhance that command and remove 
any hacks like [info script].  A whole doc page on introspection would be nice 
as it would lay out exactly what you can query from Rivet.


 OK, but I don't see it as the mine field it could look like at first.
 The only problem I can think of is implementing a simple and safe way
 for keeping the state of of a request processing and depending on it
 calling either our implementation of 'info script' or Tcl's. The crux of
 the problem is that we need to run our info script only during the
 execution of any script/template referenced by the URL and call the
 default implementation from any other script (ChildInitScript,
 BeforeScript,  AfterScript, ErrorScript etc).
 
 The method of remapping a Tcl command would make possible to simply
 extend both 'info' and 'source' provided also this one is an ensemble
 method. A URL referenced file name should be stored in the
 rivet_interp_globals structure and a method of ::rivet::inspect could be
 used to read it. I think everything could be done within
 Rivet_ExecuteAndCheck but the transition between those 3 procedures
 (where the state has to change in order to drive our wrappers of 'info'
 and 'source') isn't marked by anything, as scripts are simply
 concatenated and then executed.
 
 I think the problem is leaning more on mod_rivet rather than Tcl.


I love that Tcl lets you override commands, including core commands.  Other 
language purists can argue it’s a bad thing, whatever, I’m not interested in a 
debate.  The problem is when you do it in a framework like Rivet where other 
people are expected to build on top of your work.  Everything you rename and 
install your own proc over the top of creates another level of indirection and 
the added performance cost of a proc call.  Which is bad, mmm’kay.  ESPECIALLY 
if you do it to a command like [info] that gets called thousands of times per 
request.

Currently, we don’t “override” anything.  We just use Tcl’s already-provided 
mechanism (info script ?filename?) to set the script name within the Rivet 
request.  Any call to [info script] still maps directly to the C function and 
costs nothing except setting the script once when setting up the request.

I guess what I’m trying to figure out is what the hell all this is for.  Remove 
the hack to [info script], that’s great.  Note it in the CHANGES that we no 
longer do that and point them at ::rivet::inspect.  But let’s not “fix it” by 
adding another hack somewhere else.  If we want to extend ::rivet::inspect 
(which should also be an ensemble, by the way), then extend it to have an 
[inspect script] command or whatever.  But let’s not fix one “hack” by hacking 
something else.  Trying to override the source command and/or 
::tcl::info::script just sounds like an all-around bad idea.

What do we gain for the performance loss?  What’s the point?  And… who’s asking 
for it?  Did someone get confused using [info script] and report a bug or ask 
for support that I missed?  If you just want to remove the (arguable) hack, 
then remove the hack.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: file name returned by info script

[Damon Courtney]

Then back away slowly and come up with a new plan.

I would suggest that for now we leave the [info script] behavior alone.  It 
doesn’t hurt anyone that I can see, and it would break compatibility right now. 
 As near as I can tell from the docs, it’s never even mentioned that we do 
that, and we certainly don’t define its behavior for including or sourcing 
files.

My other suggestion would be to add our own info command or something like it 
to dig into the internals of Rivet when necessary.  We currently have the 
::server() array that we populate with some configuration variables.  Those 
could be moved to a new introspection command as well.

Tcl is known for its introspection.  There’s no reason we shouldn’t also 
provide some hooks to give insight on what Rivet is doing.  We’ve faked around 
it for years now, let’s just make it official.

And stop messing with Tcl internals. :)

D


On Jan 22, 2014, at 4:08 PM, Massimo Manghi mxman...@apache.org wrote:

 In think there is more to fix about the way 'info script' is handled in Rivet.
 
 1) when called from a template parsed by another template I maintain the 
 usual Tcl way to respond is expected and the sub-template name be returned. 
 Currently the toplevel template name is returned. This requires also 
 Rivet_Parse and Rivet_ParseExec to handle the current file name and store it 
 coherently somewhere in the local scope and in rivet_interp_globals.
 
 2) to be consistent with the standard behaviour a file name should not be 
 always returned as full path. The mechanism at point 1 should be OK as the 
 file name passed as argument by the caller will in case be returned.
 
 3) mod_rivet.c chdirs to a (toplevel) template directory at every request. 
 For the same reason explained at point 2 the simple file name should be 
 returned, but I can't exactly quantify the impact on existing software and 
 therefore I'm not very sure about is to be done.
 
 4) As the code in mod_rivet changes globally the way [info script] works, 
 also the 'source' command should be remapped to a rivet's new source command 
 that should work like described above
 
 it's getting trickier than expected...
 
 -- Massimo
 
 
 On 01/20/2014 06:29 PM, Damon Courtney wrote:
 Ugh.  Don’t do that at all.  Overriding Tcl’s [info] command (or any
 core commands) by renaming and replacing is a path to doom.
 
 The good news is that we no longer have to.  As of 8.5.something,
 [info] is a namespace ensemble command.  I do think it’s worthwhile
 to make [info script] do the right thing, so you have two ways of
 doing it.
 
 Option 1
 
 proc ::tcl::info::script {{filename “”}} { return [::rivet::env
 SCRIPT_FILENAME] }
 
 This replaces Tcl’s call for the [info script] command with a proc of
 our own making that just returns our script no matter what while
 maintaining the same call structure for compatibility.  But it
 overwrites a Tcl core function, even if it is buried behind an
 ensemble.
 
 Option 2
 
 proc ::rivet::InfoScript {{filename “”}} { return [::rivet::env
 SCRIPT_FILENAME] }
 
 set map [namespace ensemble configure ::info -map] dict set map
 script ::rivet::InfoScript namespace ensemble configure ::info -map
 $map
 
 Option 2 obviously has a few more steps, but is probably more
 correct.  Anyone looking at the ensemble can immediately tell we’ve
 overridden the script command.  They can also still reach the
 original [info script] command by calling ::tcl::info::script if they
 want.  It actually does more than just tell you the startup script.
 :)
 
 Damon
 
 
 On Jan 20, 2014, at 3:39 AM, Massimo Manghi massimo.man...@unipr.it
 wrote:
 
 Hi
 
 I'm wondering if actually is worth keeping these lines of code in
 Rivet_SendContent
 
 Tcl_Obj *infoscript = Tcl_NewStringObj(info script , -1);
 Tcl_IncrRefCount(infoscript); Tcl_AppendToObj(infoscript,
 r-filename, -1); Tcl_EvalObjEx(interp, infoscript,
 TCL_EVAL_DIRECT); Tcl_DecrRefCount(infoscript);
 
 the purpose of running this Tcl fragment is to coax 'info script'
 to return the full path to the current script. Notice that this
 code is unconditionally run on every request handled by
 mod_rivet.c. Not a big deal in terms of performance, but we could
 save some time at every request if we approach the problem in a
 different way (and in any case it's not a good design to have code
 computing something that could never be used when this same
 information can be obtained by other means and only on demand)
 
 My proposal is to rename Tcl's info command in Rivet:init (to a
 different namespace?) and provide our own 'info' command which will
 fall back to the default in every case except when the command call
 reads exactly 'info script'. In this case the string returned by
 
 [::rivet::env SCRIPT_FILENAME]
 
 would be returned or the same information could be fetched from
 request_rec by a new specific command (the presence of a specific
 environment variable is configuration dependent, I still have to
 understand whether

Re: [Bug 55583] Rivet traceback on headers redirect command

[Damon Courtney]

The original intent was that once you've said you're going to redirect to 
another page, you should simply stop processing.  So the command would return a 
RETURN code telling Tcl to return from the current function.

I don't think it ever really worked the way it was intended (at least not in my 
experience), and it seems as though the Tcl guys probably fixed something that 
shouldn't actually have been allowed.  Or maybe someone messed up. :)

Either way, I always end up wrapping [headers redirect] in a proc that then 
does an abort_page call after it to get the result that should really occur.


On Oct 8, 2013, at 7:22 PM, Massimo Manghi mxman...@apache.org wrote:

 Resending to the list this comment posted on bugzilla as the list processor 
 won't let me approve it because the message gets tagged as SPAM (??) perhaps 
 because of the attached patch
 
 I don't know if this has side effects (I still have to run the test suite) 
 but apparently this trivial patch fixes the problem (Rivet 2.1.3, Apache 
 2.2.25, Tcl 8.6.1). The problem is with the Tcl code returned by command 
 'headers redirect ...' which is TCL_RETURN. I don't understand what happened 
 under the hood of Tcl, but probably there is some interaction with the NRE 
 that didn't occur in Tcl 8.6.0 (8.5 still has the recursive engine)
 
 It seems to me that if TCL_RETURN could work out an equivalent TCL_OK in most 
 cases, but Tcl 8.6.1 must have changed something. I wonder if this was a 
 mistake or intentional of the person who originally coded this command.
 
 here is the patch (easy)
 
 Index: src/rivetcmds/rivetCore.c
 ===
 --- src/rivetcmds/rivetCore.c (revision 1530074)
 +++ src/rivetcmds/rivetCore.c (working copy)
 @@ -340,7 +340,7 @@
 apr_table_set(globals-r-headers_out, Location,
  Tcl_GetStringFromObj (objv[2], (int *)NULL));
 TclWeb_SetStatus(301, globals-req);
 -return TCL_RETURN;
 +return TCL_OK;
 }
 else if (!strcmp(set, opt)) /* ### set ### */
 {
 
 
 -- Massimo
 
 
 On 09/25/2013 12:17 AM, bugzi...@apache.org wrote:
 https://issues.apache.org/bugzilla/show_bug.cgi?id=55583
 
 --- Comment #6 from Massimo Manghi mxman...@apache.org ---
 Confirmed: I was able to reproduce the traceback with Tcl 8.6.1 *and* Apache
 2.2.25 (Debian/linux unstable). Changing one of these to 8.6.0 or 2.2.22
 doesn't produce the bug.
 
 I removed the numeric header command from the error handler and the bug 
 doesn't
 show up again. Time to investigate what 'headers numeric' is actually doing,
 but I can't get on it immediately
 
 
 -
 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: Socket gets hanging in Rivet

[Damon Courtney]

You can't do puts -nonewline on one side and then gets on the other.  It 
will hang forever waiting for the newline to come through.  That's what gets 
does.  It reads up to the newline character.

And since you didn't put the socket in non-blocking mode, the gets will block, 
waiting forever for a newline that will never come.  Poor little gets.  If you 
add -blocking 0, gets will return immediately but with no data because it tried 
to get a line and still never found a newline.

If you don't want to use newlines, or you want to send binary data, you need to 
use read to get at the data.  It will read everything in the buffer, and since 
you have -buffering none, that will be everything you sent.  The better idea 
would be to do this:

fconfigure $s -buffering full

puts -nonewline $s $data
flush $s

Unless you're trying to stream something bit-by-bit, that will buffer all your 
data (up to the size of the socket buffer), and then flush will push it all out 
at once.

But Massimo is right, your gets is waiting on a newline.

D


On Aug 17, 2013, at 9:31 AM, Brice Hamon normandvik...@gmail.com wrote:

 Hi all,
 
 I am facing a unexpected problem with such simple code in Rivet:
 I open a socket to an echo server, send something and wait for the answer.
 
 I open the socket like that:
 
 set port 20445
 set host toto2
 set s 0
 
 proc connectToBs {} {
 ::request::global s
 ::request::global port
 ::request::global host
 
 set s [socket $host $port]
 puts Connected to $host:$port
 fconfigure $s -buffering none
 fconfigure $s -translation binary
 }
 
 Then:
 
 connectToBs
 puts -nonewline $s OKOK
 set resp {}
 gets $s resp === and I am getting stuck in the gets forever.
 
 The same code under a regular tclsh works. I don't get it.
 
 I am using the native TCL8.5.10 from SUSE 12.1 with Rivet 2.1.2.
 
 Any idea?
 
 Thanks,
 Brice.


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: [Bug 55153] fileevents do not fire

[Damon Courtney]

Using the event MPM with a non-threaded Tcl works fine.  That's what I use just 
because it's the default in most cases, so I had never hit the issue being 
discussed.  When I recently built a new server, I tried a threaded Tcl with 
prefork (as our docs say) and hit it.  When I compiled back to event / 
non-threaded, everything works.

Not saying that's an answer, just throwing in my experience.  I also use 
SeparateVirtualInterps as I generally run a bunch of smaller sites on a single 
instance.  I know FA and other bigger users are not going to have that turned 
on.

D


On Jul 18, 2013, at 11:43 AM, Jeff Lawson j...@bovine.net wrote:

 
 
 
 On Thu, Jul 18, 2013 at 9:15 AM, Massimo Manghi massimo.man...@unipr.it 
 wrote:
 On 07/18/2013 08:39 AM, Harald Oehlmann wrote:
 
 
  I have reasoned the requirement by the fact, that the following feature
  saved 40 minuites of boot time for FlightAware (what I think I have read
  here):
 
  - Start master interpreter
  - source packages
  - fork a client interpreter
  - open data base connections etc.
 
  If not so, we should revert this, and just do all of that after the fork.
 
 
 I'd like to hear from the FA guys on this. FWIK they had a tremendous
 improvement in the startup of their application.
 
 This feature has some limitation though, even when you are not demanding
 the notifier to be working. Slave interpreters generation don't
 propagate the packages initialization to slave interpreters, therefore
 if SeparateVirtualInterps is on you cannot share among virtual hosts a
 common ground of preloaded packages. (Would this be worth a TIP
 requiring to extend the slave interpreter command to support initialization)
 
 
 It is definitely important for us at FlightAware to be able to do Tcl 
 interpreter initialization before forking.  Our webserver environment uses 
 multiple physical servers each with 300 Apache children processes.  During 
 the Tcl global init and before forking, we pre-load several gigabytes of 
 infrequently changed data from our database for performance.
 
 The inability to do this pre-loading would cause each child to have to load 
 this data from the database (which causes a massive database overhead for 300 
 connections to simultaneously request that much data), which indeed adds many 
 minutes of startup time to our daily release cycle.  Since our release cycle 
 requires us to fully restart one physical server at a time so that we can 
 continue to serve production traffic on the remaining physical servers, any 
 increase in restart time cascades linearly with the number of physical 
 servers we have.
 
 The added database overhead of these 300 Apache children requesting gigabytes 
 of data would also compromise our ability to handle normal database traffic 
 from our other servers while we are restarting one.  
 
 Additionally, the RAM usage on the webservers is significantly impacted since 
 this static data is now actually allocated and duplicated in each child, 
 rather than being loaded in the parent and cloned via copy-on-write pages to 
 each child.  Several gigabyte per child multiplied by 300 processes is a 
 significant memory footprint change for our webservers.
 
 
 Jeff

Installation

[Damon Courtney]

When building Apache, Tcl and Rivet from source, I always have to build Rivet 
with:

./configure --with-apr-config=/usr/local/apr/bin/apr-1-config

Else the Rivet build fails because it can't find apr.h.  I built and installed 
the APR package in its default place, so this is where it wants to live.  Can 
we make Rivet's configure script check for this?

Also, just a note, but the tclrivet package needs an update to the parser to 
grok the new ?= ? construct.  Not a big deal, but I just noticed it.

So, with 2.1.2, we don't install packages at all by default?  The user has to 
explicitly call 'make install-packages' to get them?  What was the reason 
behind this?  Call me crazy, but the point of most installations today is to 
install all of the packages but load on demand, which is what we were already 
doing.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Apache Versions

[Damon Courtney]

Anyone know off the top of their head what versions Rivet compiles with and, 
more importantly, which it doesn't?
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Tcl file mimetype function

[Damon Courtney]

Don't know of a Tcl package, but you might try the xdg-mime utility on most 
Linux / UNIX distros.


On May 15, 2013, at 12:29 PM, Massimo Manghi massimo.man...@unipr.it wrote:

 I'm distributing some Powerpoint files along with other binary (images) 
 files. I wish to determine the correct mimetype and set the Content-Type 
 headers accordingly. Tcllib's ::fileutils::mimetype doesn't know anything 
 about MS Office documents and returns an emtpy string (not even a generic 
 'application/octet-stream'). Is there some wider mimetype library available 
 for Tcl to prevent me from using the file extension? :-
 
 -- Massimo
 
 
 -
 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: Verify Link using http package

[Damon Courtney]

I use the HTTP package within Rivet to make outside requests all the time.  Not 
sure what could be causing the problem.  Try without the timeout and just see 
how long it takes to come back.  The problem with the timeout feature of the 
http package is that it times out even if the request comes back and is 
delivering data.

Also, -validate sends a HEAD request, which can actually be disabled on the web 
server.  Not sure what kind of response you would get back in that case, but 
you might try just doing a regular request with no timeout from within Rivet to 
see what you get back.

Damon


On May 10, 2013, at 8:30 AM, Harald Oehlmann harald.oehlm...@elmicron.de 
wrote:

 I am trying to verify some links of a form entered by a user by:
 
 package require http
 set requestHandle [::http::geturl $urlIn -validate 1 -timeout 5000]
 
 Outside of a rivet script, this works well.
 Inside a rivet script, I always run into the timeout.
 
 Is the tclsh interpreter inside rivet not allowed to use sockets to call
 out of the machine ?
 
 This is CentOS 6.2 64 bit with recent Rivet and tcl8.6.0.
 
 I have activated SE Linux but there are no warnings within the log, so
 there should be no issue with that.
 
 Thank you for any idea,
 Harald
 
 -
 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: Unexpected behavior when redefining ::unknown and calling the original

[Damon Courtney]

 Why don't add a configuration option to make Rivet using safe interpreters?

David and I discussed it back in the day when Rivet first started, but creating 
an interpreter (especially a safe one) on every request was WAY more expensive 
than creating a namespace for each request, and most people don't need the 
protection of multiple interpreters.  We thought about adding it in at one 
point for things like hosting companies (the same reason NeoSoft did it back in 
the day), but it ultimately wasn't worth it, and no one was asking.

AOLServer creates a new interpreter for every request, but it also has a 
sophisticated pooling mechanism for creating a pool of Tcl interps and then 
keeping them around until there's a request to fill.  They also wrote some nice 
code for essentially cloning an interp to another, so they can setup a master 
interp and then quickly clone as many copies as they needed to serve requests.

As I said, all this could be done in Rivet, but what is the pay off?  No one 
really needs such a feature.
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Rivet 2.1 and 2.0 status

[Damon Courtney]

Have we moved on to 8.5+ only support?  If so, I'd like to start cleaning up 
some of the older code that still uses Tcl 8.4-isms.

I don't remember where the discussion on this topic eventually led, but I think 
we can all agree to drop 8.4 support if we haven't already.


On Sep 13, 2012, at 9:57 AM, Harald Oehlmann wrote:

 Thank you Massimo for the analysis
 
 Am 13.09.2012 16:40, schrieb Massimo Manghi:
 - #52909: form select multiple default broken
 - #52653: load_responses has side effect to set dest(__var) on
 multiple occurences of var
 
 I thought I have fixed #52909.
 
 #52653 may just be accepted and documented.
 
 I may work on it next week.
 
 Enjoy,
 Harald
 
 
 
 
 -
 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

The ?= ? construct

[Damon Courtney]

Is this documented somewhere?  I poked around the docs a bit (which are 
hideous, by the way) and couldn't find it mentioned.  In fact, other than our 
examples, I found only a single mention anywhere that ? ? was how you 
actually GET Rivet code into a webpage.

In using the source (Luke), it looks as though the ?= ? construct is meant to 
be used as:

?= $some_variable ?

and that's about it.  If the parser sees = as the first character of the 
string, it append 'puts -nonewline' and then the rest of the string.  So, it 
looks like the = is only good for a single variable or value there since no 
effort is made to output or close a quote.  In other words:

?= $foo $bar ?

is going to blow up without doing:

?= $foo $bar ?

We either need to decide to upgrade this construct to quote the value, or we 
really need to document this behavior.  Actually, we need to document the 
behavior either way, but I think the single value thing could be better.  
Although it will make the code a little more complicated.  The current code is 
quite small and simple, so there's a vote for that.
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: form package bugfixes

[Damon Courtney]

The ID need only be unique to the request and it does not need to be repeatable 
for each request of the same page.  It is simply a way for the browser to link 
the label to the check / radio button such that clicking the label will then 
trigger the button.  They need to be unique because all IDs in an HTML page 
need to be unique.  I believe the UUID package was used originally to ensure 
uniqueness no matter what the user might choose as their IDs.

I think this is of little concern though.  At least in the current patch, the 
IDs are explicitly called autogen_X, which is very unlikely to clash with a 
naming scheme from a developer.  I could be wrong, but them's the breaks.  The 
reason they don't need to be the same with every request is because the 
developer has basically TOLD us they don't care about the ID.

In other words, if the developer cared what the ID of the checkbox was (for CSS 
or Javascript), they would have passed us -id when creating the element, and we 
would use it.  The only place this case comes up is when they are creating a 
check or radio button and they've basically said they don't care about the ID.

But we do.  The browser can't link the label to the button without the button 
having id=X and the label having for=X.  That's all this does.  Pick up 
slack where the developer hasn't cared enough to uniquely name the element.  If 
you care, name your element, but if you don't, we still need to do the right 
thing for usability and accessibility.

I would probably just go with a class variable counter for the form package and 
increment it each time.  Easy solution, the counter variable is obvious to 
anyone reading the form package, and the number will always be unique to the 
request even if they create multiple forms on a single page.  Don't 
overcomplicate it.

Them's my two cents.

D


On May 30, 2012, at 10:20 AM, Harald Oehlmann wrote:

 Am 29.05.2012 17:26, schrieb Damon Courtney:
 ## If you don't mind creating a variable in the request namespace
 autogen_[incr ::request::__formElemCount]
 
 OR
 
 autogen_[info cmdcount]
 
 OR
 
 autogen_[clock microseconds]
 
 would all work just fine without the requirement of another package.
 
 Hi Damon,
 
 Refering to the issue to generate the value idcur of:
 label ref=idcurlabeltext/labeloption id=idcur name=namecur
 value=valuecur/
 
 I have another thought on your propositions how to replace the uuid package.
 There are some solutions to generate the value idcur:
 S1) uuid package
 S2) counter which starts with 1 at each http request
 S3) [info cmdcount]
 S4) [clock microseconds]
 S5) interpreter wide counter
 S6) form name + form internal counter
 
 Here are some thoughts:
 T1) The id must be unique per http request result
 T2) when requesting the same url, there should be the same answer.
 T3) Two http requests should not be in any information relation.
 T4) Don't expose any internals
 
 I am not shure about T3, but this feels as a potential security hole.
 
 Here is the judgement of the solutions and the thoughts:
 
   |T1|T2|T3|T3|
 ---+--+--+--+--+
 S1 |yes   |no|yes   |yes   |
 S2 |yes   |yes   |yes   |yes   |
 S3 |yes   |no|no|no|
 S4 |no|no|no|no|
 S5 |yes   |no|no|no|
 S6 |yes   |yes   |yes   |no|
 
 So, S2 fullfills all thoughts.
 
 S3 to S5 would give internal information of the interpreter to the
 outside and put multiple requests in a relation (which request follows
 which). As stated before, I am not shure if this is an issue but it
 feels like a security hole.
 
 I prefer S6, as:
 + it is easiest to implement (object variable)
 + it is most logic to the outside
 - it exposes the internal form name (so T3 fails).
  Someone might have a better idea here.
  The form name may not be in the character set of an id.
 
 Enjoy,
 Harald


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: form package bugfixes

[Damon Courtney]

And that's my point.  If it matters, YOU should pass -id X instead of letting 
us generate one.  In other words:

set f [form #auto] ;

$f checkbox foo -label Foo ; ## Note, I don't care about an ID here.
$f checkbox bar -label Bar ; ## Don't care about this one either.
$f checkbox moo -label Moo -id bar-checkbox ; ## I'm going to style this or use 
Javascript, so I need its ID.

If you are letting US auto generate IDs and then using those in your CSS and 
JS, you're a bad, bad developer.  One, tiny change to your HTML, and your shit 
is busted.  If you rejiggered your form to move Bar above Foo, you just screwed 
up their ID you were relying on.

The documentation should say that if you don't give us a -id, we'll 
auto-generate one that is unique.  That's it.  We can give people rope to hang 
themselves, but we don't have to put it around their neck and give them a push.

D


On May 30, 2012, at 10:42 AM, Harald Oehlmann wrote:

 On May 30, 2012, at 10:20 AM, Harald Oehlmann wrote:
 Refering to the issue to generate the value idcur of:
 label ref=idcurlabeltext/labeloption id=idcur name=namecur
 value=valuecur/
 
 Am 30.05.2012 17:34, schrieb Damon Courtney:
 The ID need only be unique to the request and it does not need to be
 repeatable for each request of the same page.  It is simply a way for
 the browser to link the label to the check / radio button such that
 clicking the label will then trigger the button.  They need to be unique
 because all IDs in an HTML page need to be unique.  I believe the UUID
 package was used originally to ensure uniqueness no matter what the user
 might choose as their IDs.
 
 
 As far as I know, the ID may be used at two places:
 
 - JavaScript
 - Cascading Style Sheets (newer version)
 
 Thus it may matter to a developper and it would be helpful, if it is
 predictable and documented.
 
 Regards,
 Harald


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: form package bugfixes

[Damon Courtney]

 Comments:
 load_response:
 - insured that output array exists

Just to note, you are breaking compatibility here.  Previously one could rely 
on ![info exists response] to test whether any response had, in fact, been 
loaded.  I'm not a backward compatibility nut, but change for the sake of 
change is bad.  Is there a compelling reason for this?

 form.tcl:
 - return - return 
  May have side effects otherwise, as last result is returned

There is no difference between [return] and [return ].  A return with no 
arguments returns an empty string.

  There were many issues when default values were treated as lists.
  Now, they are treated as lists if __$name exists (as outputted by
  load_response).
  The following widgets require lists:
radiobuttons checkboxes select -multiple
  and all others require values.
  The first element is used if a value is required and a list is given.
  - Capsulated Default value processing internally be the protected
methods default_*
  - enhanced public method default_value by option -list to get/set a
list of default values.
This is specially important to set the current value of the list
widgets (because there is no such option prevued):
   my_form default_value -list -- option check default {o 2 o 3}
   my_form checkboxes option check default\
   -values {o 1 o 2 o 3 o 4}\
   -labels {l 1 l 2 l 3 l 4}
 - Use uuid package only if it is loaded.
  I personally didn't like that. In addition, there was no
  package require uuid.
  IMHO the code should export the uuid values, if they are generated
  on the fly. It is half taken.

Don't use the uuid package.  There's no need for it.  Just use a simple, unique 
number within the request.  There's no need for the overhead of generating a 
UUID (small though it may be), and there's definitely no need to add a 
requirement for tcllib to Rivet.  If you want to ship Rivet with tcllib 
included, I could be persuaded for that, but don't make me get tcllib just to 
get a unique name for an HTML form element.

## If you don't mind creating a variable in the request namespace
autogen_[incr ::request::__formElemCount]

OR

autogen_[info cmdcount]

OR

autogen_[clock microseconds]

would all work just fine without the requirement of another package.


 Footnote:
 for me, form my form raises an Itcl error.
 I have forwarded this to Arnulf Wiedemann.

Being that there are many bug fixes but also MANY incompatibilities in this 
version of the form package, we might consider moving these changes to a 
form2.tcl file and giving it a [package provide form 2.0] label.  This would 
leave the old one in place, and anyone running into compatibility issues could 
simply change [package require form] to [package require form 1.0] to get the 
old one and keep running without all the pain in the ass.

I'm not disagreeing with the changes here.  They look good, and they do fix 
bugs.  But give people a temporary migration path.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Tcl_Mutex call

[Damon Courtney]

Well, Massimo says it doesn't work as it is right now, and I've seen some mail 
on this list to that effect as well, so there must be something wonky going on 
there.  I have no idea what though. 0-]

Damon


On Jul 29, 2011, at 1:40 PM, Karl Lehenbauer wrote:

 I know Tcl's thread model is one interpreter per thread.  That seems like
 a pretty good fit.  Is it even relevant?
 
 On 7/29/11 1:16 PM, Damon Courtney da...@tclhome.com wrote:
 
 I don't recall being the one to addd that code, but I would imagine we
 need to go with Apache's model here.  We run inside Apache's world, for
 the most part, so we should let that be the record of authority in cases
 like these.
 
 Damon
 
 
 On Jul 29, 2011, at 12:39 PM, Massimo Manghi wrote:
 
 Hi guys
 
 I'm reviewing mod_rivet.c to understand what
 making it mpm-worker compliant is about. Currently mod_rivet
 fails  miserably when running with the threaded mpm,
 still this is an issue we should try to
 deal with.
 
 It seems someone (Damon?) laid down the code
 setting up Rivet to support threads by putting the
 content generation within a pair of
 Tcl_MutexLock-Tcl_MutexUnlock calls.
 I don't see any other purpose for this and there is
 no comment explaining the need for this. I
 
 This is not enought to let it work and anyway
 Rivet should use apr_* call to better suit the Apache
 threading model.
 
 Anyone can recall why these calls made it into the code?
 
 -- Massimo
 
 
 -
 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

Re: Apache 1 removal countdown

[Damon Courtney]

Just out of curiosity, what is the compelling reason for removing 1.x support?  
Does it no longer work?  Is the work to support it too much work going forward?

Note that I'm not suggesting we should keep it, I'm just wondering if there is 
a specific reason for removing it.


On Apr 19, 2011, at 8:27 AM, Massimo Manghi wrote:

 
 even though svn can restore from deletion a whole directory tree,
 when the time comes to actually type 'svn remove ...; svn commit'
 a qualm about what you're doing takes over. So, before I commit the
 removal of the apache-1 directory I want to concede a last chance
 to say hold on and wait. I will commit the removal tonight if no one
 will have a different opinion.
 
 After apache-1 is deleted also configure.ac gets changed and an attempt
 to pass --with-apache-version=1 to 'configure' results now in an error 
 message.
 
 
 -- Massimo
 
 -
 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: branches/rivet-namespace ready

[Damon Courtney]

On Feb 15, 2011, at 8:03 AM, Massimo Manghi wrote:

 I've just merged the latest commits from trunk into branches/rivet-namespace.
 
 This branch holds the code that introduces the ::Rivet namespace where all 
 the module commands are located. Commands in librivet.so are now placed in 
 the package RivetLib (formerly called simply 'Rivet'). The change was 
 motivated by the need to leave the work ::Rivet to everything is pertaining 
 the core module.
 
 A trivial way to assure compatibility with existing scripts can be achieved 
 by adding these lines to the configuration
 
 RivetServerConf ChildInitScript package require RivetLib
 RivetServerConf ChildInitScript if {[package present Rivet] = 1.2} {
 RivetServerConf ChildInitScriptnamespace import ::Rivet::*
 RivetServerConf ChildInitScript }
 
 Notice:
 
 -- Rivetlib creates commands into the ::Rivet namespace and puts them on the 
 export list
 -- Commands are created into the ::Rivet namespace. Changing to other forms 
 (::rivet or ::RIVET) can be done in a split second, as it's just a 
 preprocessor definition. Just express your opinion
 
 I will allow a week for anyone to try this branch before commiting into trunk

I would call it ::rivet instead of ::Rivet.  I would also call the library 
simply rivet.  IE:

package require rivet
namespace import ::rivet::*

I don't think there's a compelling reason for the names to be anything more 
than that.  Also, I think it might be wise at this point to do the namespace 
import automatically for the current release but mark it as deprecated and 
encourage people to start using ::rivet::X instead of just the command name.

Damon
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: reintegrating branches/master-interp

[Damon Courtney]

If Karl says it's ready and he's already using it in production, that's good 
enough for me.  Push it.

Also, I've been thinking maybe we need to enable SeparateVirtualInterps by 
default.  I realize it's my own stupidity, but when developing in a dev vs. 
production environment (usually on different virtual hosts), this really hosed 
me up the other night until I figure it out.  Is there really a good reason 
someone would WANT all the interps to serve every domain?

I'm sure there are reasons why (multiple domains all hosting the same site and 
content), but should that really be the default case?

D


On Jan 31, 2011, at 10:03 AM, Massimo Manghi wrote:

 If no objection is raised, I'm going to merge into trunk the branch with the
 master interpreter creation and initialization through the directive
 'ServerInitScript'
 
 -- Massimo
 
 
 
 -
 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: reintegrating branches/master-interp

[Damon Courtney]

 Also, I've been thinking maybe we need to enable SeparateVirtualInterps
 by default.  I realize it's my own stupidity, but when developing in a
 dev vs. production environment (usually on different virtual hosts), this
 really hosed me up the other night until I figure it out.  Is there
 really a good reason someone would WANT all the interps to serve every
 domain?
 
 443 / 80 needn't be handled by different interpreters and a big site might
 have several names, like we also serve flightaware.co.uk, but the typical
 user of Rivet with more than one vhost would probably want separate
 interpreters and if they were big enough to need the other style they'd
 figure it out by then.  Short answer, then, is it's OK with me.


It sounds like Massimo is in agreement as well.  We should make 
SeparateVirtualInterps the default and then add some information in the docs 
about what this might mean and when you might want to turn it off, like in the 
case of really big sites.

Although, I'm curious.  I don't know exactly what the code says about this, but 
does it handle virtual hosts based on the actual name of the requested host or 
based on some Apache internals?  For example, if you have:

VirtualHost *:80
ServerName foo.com
ServerAlias www.foo.com bar.com www.bar.com
/VirtualHost

Does that all show up to Rivet as a single virtual host, or is Rivet 
determining that each of those domain names is a separate virtual host?  I 
would think they should all show up as a single virtual host and get served the 
same interp, but I don't know.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Rivet namespace and Rivet package

[Damon Courtney]

With this latest project of mine I actually started work on a framework built 
solely around Rivet.  I'm not shooting for something that works across web 
servers or something that is portable, I'm writing something that takes 
advantage of all the things Rivet has to offer.  I call it Skyscraper.

It kinda sucks right now because I've only really just started it, but it's 
coming along.  It's based on many of the ideas used in Rails but in a Tcl way.  
When I looked at Ruby and Rails once before, there was a lot to like about it.  
Right now it's sort of hardwired for MySQL and jQuery as the external 
components, but that's purely because it's what I'm using.  The ties to jQuery 
at this point are not much more than just including the tags to include it, and 
MOST of the SQL code is generic with only a few MySQL-specific things.

It uses TDBC as the database backend, so it can easily support any database Tcl 
does, and the rest is all straight Tcl or Rivet.  It doesn't use TclOO though 
it probably could if someone had a strong feeling about it.  I found when using 
Rails that the object stuff felt kinda' forced.  Like you didn't really need 
it, but because you're in Ruby, that's just the way you do it.  Do you really 
need a new object for each request?  Isn't that what Rivet's ::request 
namespace is doing for you?

I'm open to hearing what people have to say on this topic.  I needed a good MVC 
framework for writing Rivet apps, so I made one.  I'm up for taking suggestions 
as I write it if anyone has any.  I hope to include it as part of Rivet one 
day.  Unlike TclOO that was supposedly made to build other OO frameworks on top 
of, I'd like to see Rivet ship with one framework to rule them all and right 
out of the box.

D


On Jan 27, 2011, at 8:12 AM, Massimo Manghi wrote:

 Arnulf's work is the only serious attempt I know to endow Tcl programming 
 with a consistent framework for web development. Still, the SF site has no 
 download to offer. Do you know if Arnulf moved it on to some other resource?
 
 -- Massimo
 
 
 On 01/27/2011 02:31 PM, Harald Oehlmann wrote:
 
 Maybe ATWF, the port of the zend framework to Rivet by Arnulf Wiedemann
 may be interesting?
 See:
 http://wiki.tcl.tk/25821
 or the presentation at TC2010.
 
 Harald
 
 -
 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 namespace and Rivet package

[Damon Courtney]

MySQL was just my choice, and most all the code in Skyscraper itself is just 
plain old SQL.  There may be a few things in there that are specific, but for 
the most part it'll work anywhere.  But Flightaware isn't going to use 
something like this.  You guys have in development of your stuff, and this is a 
whole new framework.  You're not going to go through and rewrite all your pages 
in this. 0-]

I haven't looked at generating JSON at all as I don't have a need for it, but 
it's certainly something that should be added out of the box.  Being that I 
develop my stuff in one way while others develop in completely different ways, 
this is the kind of thing that needs to be brought up.  What is the list of 
things that should be in a modern framework built on Rivet.

Someone with some Ruby and Rails experience should pipe in here.  Oooh, maybe 
we can get ol' Welton over there to wake up for a quick response! 0-]

D


On Jan 27, 2011, at 11:09 AM, Karl Lehenbauer wrote:

 I like the name.  We are down with jQuery.  But it would need to support
 PostgreSQL to get any traction at FlightAware.
 
 You might have a look at yajl-tcl for generating valid JSON really
 quickly.  The library includes returning PostgreSQL query results as JSON.
 It can parse, too, but the results are left-to-right so it's gotta be
 taken further to be useful.
 
 On 1/27/11 10:49 AM, Damon Courtney da...@tclhome.com wrote:
 
 With this latest project of mine I actually started work on a framework
 built solely around Rivet.  I'm not shooting for something that works
 across web servers or something that is portable, I'm writing something
 that takes advantage of all the things Rivet has to offer.  I call it
 Skyscraper.
 
 It kinda sucks right now because I've only really just started it, but
 it's coming along.  It's based on many of the ideas used in Rails but in
 a Tcl way.  When I looked at Ruby and Rails once before, there was a lot
 to like about it.  Right now it's sort of hardwired for MySQL and jQuery
 as the external components, but that's purely because it's what I'm
 using.  The ties to jQuery at this point are not much more than just
 including the tags to include it, and MOST of the SQL code is generic
 with only a few MySQL-specific things.
 
 It uses TDBC as the database backend, so it can easily support any
 database Tcl does, and the rest is all straight Tcl or Rivet.  It doesn't
 use TclOO though it probably could if someone had a strong feeling about
 it.  I found when using Rails that the object stuff felt kinda' forced.
 Like you didn't really need it, but because you're in Ruby, that's just
 the way you do it.  Do you really need a new object for each request?
 Isn't that what Rivet's ::request namespace is doing for you?
 
 I'm open to hearing what people have to say on this topic.  I needed a
 good MVC framework for writing Rivet apps, so I made one.  I'm up for
 taking suggestions as I write it if anyone has any.  I hope to include it
 as part of Rivet one day.  Unlike TclOO that was supposedly made to build
 other OO frameworks on top of, I'd like to see Rivet ship with one
 framework to rule them all and right out of the box.
 
 D
 
 
 On Jan 27, 2011, at 8:12 AM, Massimo Manghi wrote:
 
 Arnulf's work is the only serious attempt I know to endow Tcl
 programming with a consistent framework for web development. Still, the
 SF site has no download to offer. Do you know if Arnulf moved it on to
 some other resource?
 
 -- Massimo
 
 
 On 01/27/2011 02:31 PM, Harald Oehlmann wrote:
 
 Maybe ATWF, the port of the zend framework to Rivet by Arnulf Wiedemann
 may be interesting?
 See:
 http://wiki.tcl.tk/25821
 or the presentation at TC2010.
 
 Harald
 
 -
 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

Re: Rivet namespace and Rivet package

[Damon Courtney]

This is where I'm not exactly sure how tightly things are integrated between 
Javascript and most frameworks.  I know that Rails supports jQuery and 
Prototype, I believe, but I don't know exactly where they have them integrated 
and for what purpose.

The only integration I have so far is in a proc called ss_button that creates a 
button widget, and you can do things like:

ss_button delete -text Delete This -confirm Are you sure you want to delete 
this?

The -confirm option links into jQuery and pops up a confirmation dialog before 
proceeding with the button if it exists.  Otherwise it just returns and does 
nothing.  So far that's about the only actual integration I've managed to come 
up with.  I'm using jQuery extensively on the site, but it's just pure jQuery 
and has little or nothing to do with the Tcl code on the backend.

D


On Jan 27, 2011, at 12:22 PM, Clif Flynt wrote:

 I've got some sort of javascript interfacing in my future.  In a 
 post-FaceBook era, folks don't like the http 2.0 look  feel any more
 than they like Mosaic.
 
 I've looked at WubTk briefly - the idea is clever (rework Tk widgets to
 generate javascript (JQuery, I think) widgets), but it's tied more
 tightly to Wub than a quick survey was going to disentangle.
 
 I think a One-True-Supported javascript thing in Rivet (or as a Rivet
 add-on) would be great.
 
 I can offer to test and complain.  I'm not sure just how much I'll be
 able to actually contribute.
 
 Clif
 
 -- 
 ... Clif Flynt ... http://www.cwflynt.com ... c...@cflynt.com ...
 .. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
  18'th Annual Tcl/Tk Conference:  2011, Manassas, VA USA 
 .  http://www.tcl.tk/community/tcl2010/  
 
 
 
 
 
 
 
 -
 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: master interpreter

[Damon Courtney]

Freakin' awesome!  Good work, Massimo, and thank you.  Looks like the giant may 
awaken for a bit after all. 0-]

D


On Jan 25, 2011, at 12:40 PM, Karl Lehenbauer wrote:

 You are correct, Massimo.  We have eight cores, 200 children, and before
 the ServerInitScript patch the machine had a very high load average for
 multiple minutes after a graceful.  With the patch, startup time for 200
 children to a calm, quiet system is five seconds.  So yeah, it is a 98%
 reduction or, said another way, more than 50X faster.
 
 Also since the packages all get loaded into the parent, the forked
 children share all the VM pages containing procs, arrays, long strings,
 etc, with copy-on-write keeping any changes from being shared.  This has
 reduced the memory footprint by tens of megs per child, another big win
 for ServerInitScript.
 
 Massimo's patch is in production at FlightAware and has successfully
 served more than a million pages across several webservers, with no
 errors.  I consider the patch fully tested at this point, and it can be
 merged into the mainline any time -- it's good to go.
 
 Karl
 
 On 1/25/11 11:54 AM, Massimo Manghi massimo.man...@unipr.it wrote:
 
 Wow, if I understand your estimation on the reduction of time needed to
 start up the server was correct.
 
 How many processors do you have on this machine? The time needed to
 merely launch the 150 children had to be (12*150)/(num of processors)
 seconds, since each of them took at least 12 secs of CPU time (not
 counting other time spent in waiting state). On a machine hosting 4
 processors it means around 4-5 minutes which is in agreement with what
 you reported. Perhaps my reckoning is over simplified, it would mean the
 time was cut by a 98%
 
 -- Massimo
 
 On 01/25/2011 08:45 AM, Karl Lehenbauer wrote:
 Massimo et al,
 
 I got the master-interp branch of Rivet built and running on a
 near-production next-generation webserver running FreeBSD
 8.2-PRERELEASE.  Moving the loading of the hundreds of packages we are
 doing in the ChildInitScript into the ServerInitScript cut the apachectl
 graceful time to launch 150 children to about five seconds of realtime
 from start to the system being stable and idle and ready to handle
 requests.  And it works.  Each child process shows 0 CPU seconds, as
 opposed to about 12 CPU seconds having each child do all the
 initialization separately (and mostly system CPU, too).
 
 We had some hacks in there to randomly delay Apache child startup, too,
 because it made the whole thing faster by reducing contention.  That's
 off in test and we won't need it anymore.
 
 If all goes well we'll try it tomorrow in production and if it works on
 one of the webservers, we'll push it to all of them.
 
 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: Rivet namespace and Rivet package

[Damon Courtney]

I'm just looking at some of the code for the first time in a while so forgive 
me for not commenting sooner.

Are you talking about just moving the rivet commands into a ::Rivet namespace?  
It sounds like from this and your previous Rivet command scope email that 
you're trying to unify everything.  I think that's a great idea.  It makes 
Rivet more of a package that can easily be loaded or not based on the user.

Does anyone else have an opinion here?  Are there any other Rivet requests on 
the horizon we should be looking at?  It sounds like Karl is waking up a bit, 
at least as regards to ideas and thoughts, but maybe some code too.  I'm 
working on a pretty big project in Rivet right now, so my activity level is 
sure to increase soon enough.  Clif Flynt has thrown his hand in a few times 
now.

Combine that with Massimo's tireless work, and we may actually be able to wake 
the sleeping giant.  At least until we all go back to our regular lives. 0-]

D


On Jan 13, 2011, at 6:02 PM, Massimo Manghi wrote:

 Code in src/rivetWWW.c, src/rivetCrypt.c and src/rivetList.c has been so far 
 independent from definitions in the mod_rivet.h. This was a sensible approach 
 that made it reusable outside the context of the apache module.
 
 I favor the move of the commands coded in those files into the newly created 
 Rivet namespace, thus breaking the mentioned independence. 
 
 The package Rivet they provide could be also be moved into the module code to 
 better qualify the whole Rivet namespace (after all Rivet should be a keyword 
 reserved to the module).
 
 Existing scripts won't be affected, because the module initialization could 
 'package require Rivet' and user scripts will have a mean to test which 
 scripting level they're running in by calling 'package require Rivet x.y'
 
 comments are welcome.
 
 -- Massimo
 
 
 -
 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 wish list

[Damon Courtney]

  It takes minutes to settle down before our stuff can put the 
 server back into the webserver.  What would be incredibly cool would 
 be to be able to load up the 468 packages in the parent httpd process 
 one time and then have each child process use the same Tcl interpreter 
 already loaded with the packages.  This would be a way more than 
 200-fold improvement in Apache startup time for us (because it 
 would eliminate all the contention.)  [I don't even know if this 
 is possible.] 
 
 so slave interpreters don't inherit packages loaded in their parent
 interp? Getting the answer should be easy...


I don't even think this is possible.  You're talking about creating an interp 
in the parent httpd process and then somehow handing that off to each child as 
a copy as it's created?  I think that's a great idea, but I don't see how to 
implement it.  AOLServer has this idea of cloning interpreters, but they're 
always working within the same process not multiple children.  And I don't even 
know if THEY clone the entire interpreter, packages and all. I would think they 
do though if it's a true interp clone.

I would love to be proven wrong though. 0-]  I don't have near the kind of load 
you guys are using, but the idea of cloning a full interpreter has been an idea 
I've wanted for a long time.  Cloning within the same process is possible.  
Cloning in a child? *shrug*

D

Re: Web Services for Tcl v1.2.0

[Damon Courtney]

Well, it's not exciting or glamorous to run your own forge that's for sure.  
At this juncture I was just proposing a box somewhere that people can host 
Fossil repos on.  Fossil already has its own built-in bug tracker, wiki, etc... 
 I'm not sure how hard it would be to run multiple repos on a single machine 
with since Fossil kinda wants to run its own web server.

If we could figure that out, each project already has all the bits it needs.  
You can have a project website up and running in Fossil just by creating the 
repo.  At least to start with.  If someone wants something more than the 
default, they can kick in some work on Fossil and do it. *shrug*

That being said, I really like Github.  Their issue tracker is really not going 
to work for something with high volume though.  It's already slow as hell for 
me, and I have only 100 or so issues.  Blech.

D


On Nov 17, 2010, at 12:30 PM, Karl Lehenbauer wrote:

 I agree it would be prestigious and helpful for the Tcl community to host
 its own community development environment, but I'm concerned about the
 ability of the community to actually fulfill on it.  It's a lot of effort,
 and nobody would be working on it full time.  I feel like a professional
 organization operating as a business is more likely to be successful over
 time.
 
 I've been using github for a while and I like it.  And with git, everyone
 who has a distribution checked out has the entire repository, which really
 helps if the hosting goes away or gets corrupted or whatever.
 
 If there is something really turnkey, then maybe that is the way.  If not,
 it's a minefield.  Even sourceforge has been unresponsive and slow to
 adapt.  If we don't have the resources and we try to do it anyway, we'll
 be even worse.
 
 Just my $0.02...
 
 On 11/17/10 12:12 PM, Damon Courtney da...@tclhome.com wrote:
 
 Putting on one of my other hats for a moment - is this a service that
 the Tcl Community Association should be offering to the community?  Or
 is this something better handled via sourceForge or the other code
 repository services.
 
 Just for general info, currently, TCLCA pays for the wiki, runs the
 US conference and acts as our front for the Google Summer of Code.
 
 
 Personally, I'm against using SourceForge for future projects.  There has
 already been much talk about getting Tcl/Tk off of SourceForge in the
 future, and it is exceedingly hard to do that right now.  I would hate to
 see us put more projects there.  I don't have an answer as to what we
 SHOULD use, but that's just my opinion.
 
 Some mention has been made of using Fossil repos on some future basis.
 It's distributed, nice and small, and it's written by one of our own.  I
 use Git for just about everything these days and Github for hosting, but
 I would rather come up with something that we (we being the Tcl
 community) own ourselves.  We don't have anything like Rubyforge or the
 like, but it sure would be nice.
 
 I guess I don't have an answers about what we SHOULD do right now, just
 an opinion on what I'd rather we not do.  Which is not very helpful, I
 grant you, but that's all I got.  More discussion with the community as a
 whole is needed here.  TDOM is a project that while definitely relating
 to Rivet and the Web in general is a symptom of a larger issue.  We don't
 have anyplace to put stuff that can belong to the community.  At this
 point I don't even think we need something as big and grand as Rubyforge.
 Just a machine where Fossil (or Git or whatever) repos could live would
 be a good start.  We can worry about the interface later.
 
 D
 -
 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: Persistent DB connection

[Damon Courtney]

You need to write a helper function to create the DB connection if it doesn't 
already exist and then return it if it does.  The reason you're hitting this is 
because every time you request a page, you get a random child process from 
Apache.  You don't know which one you're going to get, and it's unlikely you'll 
get the same one over and over again.  Once you create the DB handle the first 
time in the global scope, it will remain in that Apache child, but you may get 
a different child next time.

Damon


On Oct 28, 2010, at 10:45 PM, Clif Flynt wrote:

 Hi,
  I think I'm missing something simple.
 
  I may be getting bit by threads.
 
  The system I'm building is a database backed web application. 
 Nothing particularly complex.
 
  I open a connection to the database using tdbc - this creates
 a new command that I put in the global scope as '::db1'.
 
  A few minutes later, I hit a web page, and the command is gone.
 
  It's simple enough to re-create it, but I'm getting bored with
 adding the 'is it still here' check to my code.
 
  Is there a way to open a persistent link?  Or am I getting caught by
 a new thread being assigned to a session and the new thread has never
 heard of any ::db1 command.
 
  Maybe I should drop the tdbc idea and move to dio...  My primary 
 reason for using tdbc is that I'm not convinced that we won't be 
 switching backends before we get out of prototype mode and tdbc seemed
 like the simplest way to be server-neutral.
 
  Thanks for insights,
  Clif
 
 -- 
 ... Clif Flynt ... http://www.cwflynt.com ... c...@cflynt.com ...
 .. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
 .. 17'th Annual Tcl/Tk Conference:  2010,   Oak Brook, IL  USA ..
 .  http://www.tcl.tk/community/tcl2010/  
 
 
 
 
 
 
 
 -
 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: form.tcl -method get|post?

[Damon Courtney]

Just jumping in here.  I'm working pretty heavily in Rivet for the next few 
months, so I will be updating little things and making changes a lot.  The form 
package is due for some updating and a bit of an overhaul, I think.  I know 
that Karl said they have a version that returns the form elements instead of 
outputting them, and that's probably a good change.

As far as I know, passing -method should accept anything.  There's not an 
actual check on what is supported, and what is supported in the form tag is up 
to your browser.  I know I ran into this recently.  I would do something like:

form #auto -method PUT

And in viewing the source, it would say method=PUT, but when it was submitted 
back to the server, PUT had been turned to POST (POST is the default, by the 
way).  After some reading, I think this was the browser doing it.  I couldn't 
find a better explanation.  So, I was trying to figure out how the Rails guys 
do it since they use PUT and DELETE as methods in their RESTful interfaces.  
Turns out they fake it.  They just include a hidden field that passes the 
method, and the Rails code on the backend knows to look for this variable and 
set the method to that.  So, I went with that. 0-]

I think all of our packages should be converted to TclOO if we can.  Though the 
latest Itcl IS built on top of TclOO, so we're really just talking syntax here. 
 I don't particularly care as long as we're talking TclOO in the future.  I'm 
all for moving things forward to 8.6 with a newer version.  Not necessarily 
dropping support for 8.5, just using 8.6 where we can.  That would be one 
advantage to using Itcl syntax.  It remains backward compatible with 8.5 and 
the old Itcl.

Anyone else wanna' weigh in here? 0-]

D


On Oct 27, 2010, at 7:16 PM, Clif Flynt wrote:

 On Thu, Oct 28, 2010 at 12:38:29AM +0100, Massimo Manghi wrote:
 
 wouldn't '$this methodName' work out a solution?
 
  I won't swear to it, but I think I tried that first, and 'my cmd',
 and neither of them was happy with me.
 
  I've got a kludged version of form.tcl that works (to the extent
 that I've tested it) with the new 8.6.
 
  Is anyone interested in this code?
 
 
 yes, I am. 
 
  I've attached it to this email.  If attachments get scrubbed, let
 me know, and I'll mail it direct.
 
 It's something we should talk about. Tcl 8.6 is getting momentum among the
 Tcl'ers and its new introductions will probably set new standards in the
 language history.
 
  I'm pretty bullish on TclOO.  I think it's a nice mix of providing
 structure while still giving the developer the freedom to rework 
 things as his understanding of the problem matures.  (How's that for
 buzz-word compliance?)
 
  I worked in C++ for 5 or 6 years and did a little with itcl.  I ended
 up unthrilled with OO.  TclOO has revived my excitement.
 
  This construct in the form.tcl code was the only one that caused
 me some dismay at a quick-N-dirty translation to TclOO:
 
public variable defaults  {
upvar 1 $defaults array
array set DefaultValues [array get array]
}
 
  I think this can be implemented in TclOO with a variable trace and a
 new object method, but I didn't have time right then to play with it.
 
  Clif
 
 -- 
 ... Clif Flynt ... http://www.cwflynt.com ... c...@cflynt.com ...
 .. Tcl/Tk: A Developer's Guide (2nd edition) - Morgan Kauffman ..
 .. 17'th Annual Tcl/Tk Conference:  2010,   Oak Brook, IL  USA ..
 .  http://www.tcl.tk/community/tcl2010/  
 
 
 
 
 
 form8.6.tcl
 -
 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: Moving forward

[Damon Courtney]

 Giving as granted  we are using Tcl8.5 from now on we can obviously expand, 
 reform and/or complement commands and packages.   I'm sure Damon is thinking 
 of our database access module for example. Also smaller databases (headers, 
 cookies, forms, environment) may benefit of dicts to improve their interface. 
 This is not only about the core but also programming style and object 
 interfaces so I thought we could have a page on the wiki where we can keep a 
 list of new ideas and proposals. Furthermore 8.6 is bringing new remarkable 
 stuff to Tcl and this might require some planning and ability to look far 
 ahead.

Absolutely.  Dropping 8.4 wasn't so much about it being old or unsupportable, 
it's just that we have some really nice things in 8.5 (and the upcoming 8.6) 
that we could be taking advantage that we can't as long as we continue 8.4 
support.  Some of the packages in tcllib as well as some of the binary 
extensions have already dropped support going forward, so anyone running 8.4 is 
already going to start losing out on some things.

 I created a page on the wiki at http://wiki.apache.org/tcl/RivetPlanning. I 
 chose to put in on the Apache's wiki, but maybe it would be more visible on 
 wiki.tcl.tk

I don't have an opinion one way or the other.  You're more likely to get input 
from the Tcl community than from the Apache community.  You're also more likely 
to get interest in the work from the Tcl community and maybe some people 
wanting to pitch in.  I don't think you'll find that in the Apache community.  
Not a dig against Apache, just that Tcl is a close-knit community, and they 
tend to help each other out with Tcl projects.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Moving forward

[Damon Courtney]

 I think one of the biggest advances in the potential for the use of Rivet by 
 others has been the creation of a Linux RPM and a FreeBSD port of Rivet 2.0.
 
 While I enthusiastically welcome further Rivet development, successful 
 efforts to grow the user base will yield more energy and more people who are 
 willing to contribute.
 
 That being said, I don't particularly know where to go from there.

I'm not sure I know where to go either. 0-]  I'm just working with it and 
starting to find places where it could be improved, that's all.  I think you're 
right about getting new users and new energy, but not a damn one of us knows 
how to do that.  If we did, one of us might have been able to save Tcl 
somewhat.  David has complained of this point many times.

We're just not marketing people.  How do you market a language to someone?  Tcl 
is much easier for novices to grasp, but its setup means that you have to have 
an Apache server implementation with the ability to compile modules in.  That's 
not something a novice is going to have.  They're going to be setup on a simple 
hosting service that probably has PHP built in.  It's the default choice for a 
lot of people because it's always there.

I'm open to suggestions, but I've given up caring about what people want to 
work on my projects.  If I want to work on them, I work on them.  The people 
who care about the project and use it will always contribute to it here and 
there.  But until someone has a need for something, the project will push along 
doing what it does without problems.  It doesn't mean the project is dead, it 
just means there's not much to do with a stable release that works really well 
and does the job.

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: global nonsense

[Damon Courtney]

Basically, reqvar means to give me a global variable for this request only.  
It basically does:

namespace upvar ::request foo foo

So you get your variable locally, but it's coming from the ::request namespace. 
 It will get cleaned up along with the namespace when the request is complete.  
If you want a TRULY global variable, meaning one that will actually persist 
between instances, you would use the global command or the variable command 
within your own namespace.

reqvar is just a way to say Give me a variable for this request only.

Damon


On Sep 10, 2010, at 4:52 AM, Massimo Manghi wrote:

 I use myself to store reusable code and variables outside the ::request
 namespace using other namespaces to give every symbols a meaningful scope. It
 did make sense in the usual Tcl programming and it makes sense in Rivet too.
 So I never used the ::request::global command and dropping it would not affect
 anything I did.
 
 I have a question about reqvar: does it mean the ::request namespace won't be
 wiped out at the end of the request processing and at least some of the
 contents (reqvars) preserved? Will you create a new 'private' namespace were
 reqvars are copied back and forth?
 
 -- Massimo
 
 On Thu, 9 Sep 2010 21:22:13 -0500, Damon Courtney wrote
 After chatting with Karl a bit, I think my plan is to add a new 
 command called reqvar that can be used as a way of getting a local 
 variable from the ::request namespace.  We'll leave the 
 ::request::global command in for now, but I think it's a hack and 
 needs to probably get removed.  If people want a global, you global 
 it.  If you want a namespace variable, you variable.  You want a 
 request variable, reqvar.
 
 Any objections?
 
 D
 
 
 
 --
 


-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

C is for Cookie

[Damon Courtney]

I notice that the 'cookie delete' command was removed from the docs, but it 
still exists in the cookie.tcl file.  Any particular reason?  I found it a nice 
and clean command for deleting a cookie instead of:

cookie set foo  -minutes -1

Which just looks stupid. 0-]

Also, I have found something interesting as I'm writing some login / session 
management code.  If you set a cookie and then immediately redirect to another 
page (via header redirect), the cookie doesn't actually get passed to the 
browser.  So your cookie doesn't get set before redirecting to the next page.

That is, of course, unless you specify -path / EXPLICITLY!  Not sure why that 
is, but that's the deal.  If you specify -path /, the cookie will get passed 
along with the redirect header, and the browser will set it correctly before 
moving on.  The default behavior if no path is specified for a cookie is to use 
the path of the object that was requested.  Does anyone actually want this 
behavior??  It seems to me the smarter default is simply /.

I propose modifying the 'cookie set' command to default -path to / if none is 
specified, which would mean that people don't get bitten by this little 
idiosyncrasy in their own code, but they can still specify -path for a 
subdirectory if they really want to.  Also, I propose bringing back the docs 
for 'cookie delete' and making that command use -path / as the default as well. 
 Given those small changes, you can easily set or delete a cookie and 
immediately redirect to another page, and it will work as you expect.  I think 
this is what most people would expect the behavior to be anyway.  I know I did. 
0-]

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

global nonsense

[Damon Courtney]

So, way back when we first wrote Rivet, we had this bright idea to make a 
::request::global command that automatically forced global variables into the 
::request namespace so that users could say

global foo

And get what was EFFECTIVELY a global variable for their request but without 
actually setting something in the global namespace that would hang around 
between requests.  It seemed like a good idea at the time. 0-]  Now that I'm 
doing more Rivet development, this is looking like maybe a bad idea.  Not that 
we need to take out what is already there (it's already been in use for a 
while), but I think we need something better and a little more specific to what 
we're doing.

My problem is this.  I have a source file of code that is getting sourced every 
time a request comes in, and it's re-compiling my procs every time because the 
request namespace got blown away from the last request.  Instead, I want to 
make my procs in the global namespace but with the ability to scope variables 
from the ::request namespace so that the procs exist but never actually operate 
at #0.

I could easily do something like:

variable ::request::foo

within my procs, but that is assuming knowledge of Rivet and knowing that we're 
operating within a namespace called ::request.  I would prefer not to do that.  
So, my proposal is either to rename Tcl's global out of the way and just make 
our global hack be the default global, or we create a new command.  Something 
like reqvar (for a request variable) or something.

I'm perfectly happy to just rename global to something like ::tcl_global and be 
done with it.  In reality, when the hell would you EVER want a truly global 
variable to be set from your request?  There's absolutely NO guarantee you're 
ever going to see that variable again, so it seems silly to even allow it.  If 
you REALLY had a need for it, you could just as easily use ::foo and get a 
globally-scoped variable without the command.

Any thoughts or opinions?

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: global nonsense

[Damon Courtney]

After chatting with Karl a bit, I think my plan is to add a new command called 
reqvar that can be used as a way of getting a local variable from the ::request 
namespace.  We'll leave the ::request::global command in for now, but I think 
it's a hack and needs to probably get removed.  If people want a global, you 
global it.  If you want a namespace variable, you variable.  You want a 
request variable, reqvar.

Any objections?

D


On Sep 9, 2010, at 7:43 PM, Karl Lehenbauer wrote:

 Absolutely you can leave truly global variables laying around, it's valuable, 
 and this is an important capability of Rivet.  We get around the problem 
 you're talking about by using toplevel namespaces for the procs and variables 
 of our packages.
 
 We load up tons of truly global variables in our Rivet child init script, 
 arrays that function as a cache for airport names, city names, aircraft 
 types, all sorts of stuff.  We've moved to message catalogs for a lot of that 
 stuff now, using speedtables and PostgreSQL, but we did it that way for years 
 and still have lots of global stuff that pages expect and rely on.
 
 Anyway...
 
 So if you package require foo then the foo package is wrapped in a 
 namespace eval ::foo {} and it won't recompile any compiled procs for 
 subsequent pages.  We don't put procs in the .rvt pages, that is we try to 
 avoid it if there is any reusability possible at all, it goes into a package.
 
 When we want real global variables we use the ::var notation or we invoke 
 ::global instead of global.
 
 I think it needs to stay the way it works now and the way it works is fine 
 and you just need to scale up your approach by loading all your reusable 
 stuff outside of ::request, even pulled in in your child init script but 
 that's not required.
 
 As long as you use packages and the stuff is in namespaces, it's all money.  
 And tcllib and all that stuff work that way, most stuff works that way, so 
 you don't get screwed by third party packages very much either.
 
 There's also that rivet cache dealie where you can say oh cache the last 200 
 compiled pages, so you might look at that too.  Also I bet you can define 
 your procs globally with something like proc ::foo if you want to just 
 shotgun it.
 
 On Sep 9, 2010, at 7:06 PM, Damon Courtney wrote:
 
 So, way back when we first wrote Rivet, we had this bright idea to make a 
 ::request::global command that automatically forced global variables into 
 the ::request namespace so that users could say
 
 global foo
 
 And get what was EFFECTIVELY a global variable for their request but without 
 actually setting something in the global namespace that would hang around 
 between requests.  It seemed like a good idea at the time. 0-]  Now that I'm 
 doing more Rivet development, this is looking like maybe a bad idea.  Not 
 that we need to take out what is already there (it's already been in use for 
 a while), but I think we need something better and a little more specific to 
 what we're doing.
 
 My problem is this.  I have a source file of code that is getting sourced 
 every time a request comes in, and it's re-compiling my procs every time 
 because the request namespace got blown away from the last request.  
 Instead, I want to make my procs in the global namespace but with the 
 ability to scope variables from the ::request namespace so that the procs 
 exist but never actually operate at #0.
 
 I could easily do something like:
 
 variable ::request::foo
 
 within my procs, but that is assuming knowledge of Rivet and knowing that 
 we're operating within a namespace called ::request.  I would prefer not to 
 do that.  So, my proposal is either to rename Tcl's global out of the way 
 and just make our global hack be the default global, or we create a new 
 command.  Something like reqvar (for a request variable) or something.
 
 I'm perfectly happy to just rename global to something like ::tcl_global and 
 be done with it.  In reality, when the hell would you EVER want a truly 
 global variable to be set from your request?  There's absolutely NO 
 guarantee you're ever going to see that variable again, so it seems silly to 
 even allow it.  If you REALLY had a need for it, you could just as easily 
 use ::foo and get a globally-scoped variable without the command.
 
 Any thoughts or opinions?
 
 D
 -
 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

Moving forward

[Damon Courtney]

I think it's time to drop support for Tcl 8.4 in the next release.  We've got 
2.0.1 out there that works with 8.4, but 8.4 is getting long in the tooth and 
will soon be EOL'd.  I'm already running everything on 8.6, and Karl has been 
on 8.5 for a while now.  As I make changes to the core, I'd like to use newer 
8.5 code like dicts and ensembles.

I can see already from the 2.0.1 release notes that we've added a calendar 
package that requires 8.5 or 8.4 with dicts.  It's time to drop 8.4.  People 
who still need it for whatever reason can stay with the last supported version 
of Rivet (which will be 2.0.1 if we all agree).  This is not to say that we 
will be purposely ripping out a bunch of code and replacing it with 8.5, just 
that the developers don't have to worry about using the nicer pieces of 8.5 
going forward.

What say you?

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Installation Complete

[Damon Courtney]

So, I installed Rivet on my Apache 2 box today because I wanted to dink around 
with some pages.  I am happy to report that after only a minor hiccup, I got 
everything up and running with no problems.  Kudos to Massimo and everyone for 
getting the 2.0 release out and solid enough to build with just your average 
'./configure  make install'.

For the record, the hiccup I ran into was in trying to use:

../tclconfig/install-sh -c -d /path/to/some/directory

Which resulted in an error where install-sh is passing the -d to 'cp' which is 
an invalid option.  In fact, I could not get install-sh to create a directory 
even after removing the offending -d.  It just didn't work.  I ended up having 
to modify my Makefile by hand to replace that call with the more traditional 
'mkdir -p'.  Not sure what that's about.  I'm on FreeBSD 7, for the record, and 
this is compiled against Tcl 8.6.

Everything seems to be working well for now.  I haven't really exercised it yet 
though.  We'll see how that holds up. 0-]

D
-
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

[Damon Courtney]

Excellent!  Thanks for taking on the official release bits and getting things 
cleaned up, Massimo.  I think I'll grab the new release once it's posted and do 
some work on my server.  See what shakes loose.  I'm not even sure what I have 
installed on my server these days. 0-]

Damon


On Apr 29, 2010, at 11:19 AM, Massimo Manghi wrote:

 The tarball of rivet 2.0.0 has been uploaded to the apache web 
 infrastructure. The release is available now at:
 
 http://www.apache.org/dist/tcl/rivet/
 
  An announce should appear on the website tomorrow after the tar archive has 
 propagated through some of the many mirrors hosting ASF software .
 
 I'm also preparing a document to be published on the website listing the (so 
 far) few known problems with this release. After I uploaded the tarball I 
 noticed a small mistake in the INSTALL file, that shouldn't prevent a user 
 from building the module though. It's been corrected in the 2_0 branch and 
 will be commited soon.
 
 -- Massimo
 
 
 -
 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

[Damon Courtney]

On Apr 15, 2010, at 3:19 PM, Jeff Lawson wrote:

 On Thu, Apr 15, 2010 at 3:15 PM, David Welton dav...@dedasys.com wrote:
 It's been so long that I've forgotten how to go about things
 officially.  I know we have to vote on it...
 
 I'd still be a little bit concerned about the 2.X support.  Are you
 guys using that at flightaware?
 
 
 Yep, we're running against httpd 2.2.9


What are the remaining concerns over 2.x?  Just that we've never actually done 
a release with the support?  What are the build concerns with 2.x? Doesn't it 
have to be a threaded Tcl build or something?  Does the build system have the 
proper checks in place to make that happen?

D
-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: Reconsider command name for error logger

[Damon Courtney]

On Sep 3, 2009, at 8:54 AM, Karl Lehenbauer wrote:

Since the table command is apache_table, how about if the proposed  
error logging command is apache_log_error?


I don't have any problem with adding more of the Apache API to Rivet,  
and I like keeping the function names the same if we can.  Because all  
of the Apache stuff is generally namespaced with the apache_ prefix,  
we shouldn't really have to worry about name collisions, and it'll be  
really easy for anyone familiar with Apache to pick up the API.


Go for it.

D

-
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org

Re: upload data and upload channel problem solved / fixed for Apache 2

[Damon Courtney]

I like the new 'upload tempname' as well.  That's better in a lot  
of ways than 'upload save' which is just going to copy (rename?) the  
temp file into another location when all you really want is to open up  
the file wherever it is.


Damon


On Nov 14, 2008, at 11:19 AM, Massimo Manghi wrote:


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]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Accessing Apache core configuration

[Damon Courtney]

I'd go 50 if I had to throw out a number.  50 isn't going to hurt  
anything, and it might help someone who just leaves the defaults in  
place.


D


On Jul 10, 2008, at 9:37 AM, David Welton wrote:


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


What's everyone else think?  I think 20 or 25 would be ok as defaults.
So would 50.  Anyone else want to throw numbers out?

--
David N. Welton

http://www.welton.it/davidw/

http://www.dedasys.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The state of Rivet?

[Damon Courtney]

   Believe me when I say that there is nothing I would love more than 
something to get excited about in the Tcl community.  I continue to use 
Tcl for most all of my projects because I love it so much.  I've gotten 
so used to the things that Tcl does so well that it's hard for me to use 
another language that lacks those features.  Of course, it's been a 
while since I did any web development, which is an area where Tcl has, 
unfortunately, fallen behind the rest of the world.


   I really think XOTcl is the best OO framework though.  It would be 
really easy to write a SNIT wrapper on top of it but still provide the 
inheritance OO model the rest of the world is used to.  A really good 
web framework (with good AJAX integration) would do wonders for the Tcl 
community, I think.


   Remember, hardly anyone (outside of Japan) used Ruby before Rails 
came along.  Even though Ruby had been around for a long time.  Rails 
gave it a new lease on life.  The web is where all the programming is 
these days.  We have a unique position to make something great in that 
arena, but it takes hands and minds.  Most of the ones on this project 
have given up and moved on.


D


Hicks, Robert wrote:
The problem with most of the current ones is they suck when running under CGI. Catalyst (Perl), Mason (Perl), RoR (Ruby) all have poor performance under CGI and that is where you are going to get most ISP hosting companies to help you. If they don't have to much about with Apache but just install Tcl+tcllib+whatever they are more likely to do so. 

So maybe coming from the bottom end (CGI and FCGI) would help. I have heard and read that FCGI is getting more of the Apache teams attention these days. You could marry Tcl+Snit+ORM into a framework and that would be pretty nice. RoR is OO and that is where you are getting people. At least with Snit you can give them a delegation model (which should work pretty well in a web environment). 


It has to be easy to install, easy to come up to speed on, and at least excite 
the current Tcl community into helping in various ways.

Robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The state of Rivet?

[Damon Courtney]

The elephant in that room is garbage collection, as I mentioned on
tcl-core.  I want my objects deleted automatically.


I would like that too, but unfortunately this is far from trivial in 
Tcl. It may not even be possible in a reasonable sense. Laddered 
string would help a lot to do something about it and there was that 
variable trick mentioned on the Wiki. Apart from that, you would need 
to break Tcl to make it happen (which, I guess, is what Hecl is about).


   Yes, but in a web-based environment, how much garbage collection do 
you really need?!  The interpreter is going to disappear as soon as the 
webpage is sent!


Damon

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The state of Rivet?

[Damon Courtney]

   And, by the way, in defense of Tcl, the new Rails release JUST got 
Unicode support!  Wahoo!  Those guys are smokin'.


D


David Welton wrote:

Having looked at Ruby on Rails, I don't see anything so spectacular
that it couldn't be done in Tcl.  Tcl was made for this kind of stuff.
It just takes work and the hands to do it, and those seem to be in
pretty short supply.  In part due to lack of time, and in part due to
lack of interest.


RoR is a lot of good practices all rolled into one.  Tcl could
definitely do most of what it does, although it does fall down pretty
badly in terms of OO due to the lack of garbage collection.  The thing
about RoR is that it has a ton of people working on it and with it, so
there is really no competition unless you can improve on it by an
order of magnitude (as RoR did in some ways with PHP and Java).  Just
equalling what they've done isn't enough any more, because no one
cares about Tcl.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: coding style rationale

[Damon Courtney]

   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


Massimo Manghi wrote:

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




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: WinXP + Apache + Rivet + ActiveTcl

[Damon Courtney]

Is this happening when you start the server up, or when you serve up a
webpage?  If it happens on a page, can you get some pages to work, or
do they all fail?

Thanks,

Damon


 Thanks you. Any suggestion about what it might be, or what software to
 swap in order to fix it?

 Hicks, Robert wrote:
 My bad...the version number would be 8.4.12; so your issue probably
 isn't related to that.

 Robert


-Original Message-
From: [EMAIL PROTECTED]

 [mailto:rivet-

[EMAIL PROTECTED] On Behalf Of

 [EMAIL PROTECTED]

Sent: Friday, March 10, 2006 2:43 PM
To: rivet-dev@tcl.apache.org
Subject: WinXP + Apache + Rivet + ActiveTcl

Since no response was gotten, I'll try to send it again:

 I've tried for days now to get Rivet running using Apache 1.3.33.

 I've

 gotten everything else to work, so the problem is most likely
somewhere in the Rivet-ActiveTCL connection.

 Now, I have the following setup:
 -Rivet0.7
 -ActiveTcl 8.4.7

 The HTTPD.conf parameters concerning Rivet are:
 -LoadModule rivet_module modules/mod_rivet.so
 -AddType application/x-httpd-rivet .rvt
 -#AddType application/x-rivet-tcl .tcl (I don't want .tcl-files to

 be

 parsed by the web server)

 The error found in Apache's errorlog is the very descriptive
subsequent statement: Ouch!  malloc(1512058488) failed in

 malloc_block()

 Anyone got an idea on how to solve this?

 Best regards,
 Johan Christie
 www.g0mp.org
 www.tcl.no

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 'DIO' buglet

[Damon Courtney]

 You're right.  There's thing thing about DIO where it does an

  upvar $arrayName $arrayName $arrayName array

 ...and I'm not totally sure why... it's some sort of Damon magic.

Uh... probably something really stupid on my part. 0-]  Not sure why
the double $arrayName would be there when the array variable will work
just fine.  Need to get in there and look at the code.

 I've been working on DIO.  It's fairly high overhead, creating an
 object for every result, and it pulls several result variables across
 to the result object whether they're requested or not... stuff like
 that.  I've been toying with the idea of trying to reuse result
 objects due to the overhead of Itcl object creation.  Also
 occasionally studying Xotcl since that's the forthcoming official
 object system.

I'd like to see a switch to XOTcl.  Not sure what kind of work it
would be.  There doesn't seem to be a lot of push for Itcl anymore
these days.  Even David hates it. 0-]

I'm really beginning to rethink the whole every result is an object
idea.  I like it in some respects, but it really does create some
overhead that most people just don't care about.  Hell, these days, I
usually just want to iterate over all of the results and destroy the
object anyway.  The object itself is basically useless to me other
than to encapsulate some result data. *shrug*

 One thing that makes it difficult is I'm a PostgreSQL guy and not a
 MySQL/SQLite guy.  A recent case in point, I want the DIO update
 method to return the number of rows affected, but it's a different
 result method, pgresult -cmdTuples rather than pgresult -numTuples,
 and I don't know how the others handle that.

I'm definitely more a Postgres guy than anything else, but I also do a
lot of Mysql and Oracle work.  Not much on Sqlite at all (though I
really dig it), but I think if we're gonna' rethink this thing, we
need to take Sqlite into account.  It's method of handling results is
more like where we probably need to go.  You can't fetch individual
rows at a time, you just process the whole result set in a loop.

This is what I go more towards anyway, and I know Karl does too.  I
rarely find the occassion to do anything BUT process the whole result
set.  It would certainly be a lot faster.  Sqlite and Oracle both
process their results this way.  We have to do a lot of fiddling in
DIO to make it work otherwise (usually cacheing entire result sets
into an array).

Do we really need all this?  I know David has pushed before to adopt
nstcl instead of our own little DIO, but I really like the ideas
behind DIO.  I just want to see them evolve now that we've (by we I
mean Karl and I) had time to use them regularly and see what the
package really needs.

D


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: help- having problems with apache and rivet50 under windows

[Damon Courtney]

   Robert beat me to it. 0-]  Yes, the new ActiveTcl is compiled with 
threads enabled by default on Windows.  If you download the latest 
version you may find that everything just works for you.  Please let us 
know your results.  We're always very curious to know how it all goes. 0-]


Damon


Hicks, Robert wrote:


-Original Message-
   


snip
 


I found another project using TCL that give me the idea of compiling TCL
sources with threads enabled. According to the author, ActiveTCL isn't
thread enabled so I thought that it could be the reason of my Apache
crashes. What is your opinion on this point ? Here is the page, I've just
talked about: http://hammerora.sourceforge.net/installation.htm (§
Installation from source)
   



The latest version of AT is thread enabled. Just so you know...

Robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 



--

Note: It is our company policy not to accept email of any data controlled by 
the International Traffic in Arms Regulations (ITAR).  Please contact our 
Security Officer, Alexander Houtzeel, for instructions and authorization to 
transmit such data.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Rivet and Windows

[Damon Courtney]

Hey,

   How would everyone feel about packaging up a full install of Rivet 
for Windows?  Apache, Tcl, Rivet, the works, all included in an 
installer.  I really wouldn't want this for any other platform, but it 
just makes sense for Windows.  We'd probably get some good feedback from 
people who wanted to try Rivet if they could just dump it on their 
Windows box and hit Go.


D


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Rivet version number

[Damon Courtney]

You know.  I'm inclined to agree.  2.0 really does say something to
some people about stability, and I DEFINITELY think that Rivet has
that stability.  I don't really care about version numbers.  I've used
tons of 0.X releases in production code knowing the authors and
knowing that it's rock-solid despite their apprehension to raise the
version number.

If it puts more people at ease, do it.  It's definitely solid.  I vote
2.0.

D


 I am an occasional user but moving to 2.0 is not a big deal. An example
 would be Netbeans just jumping to 5.0 because they felt that enough had
 been added to justify it.

 If you think enough has been put into it...I say make it 2.0 and be done
 with it.

 Robert

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: USER array

[Damon Courtney]

 I noticed something that's kind of a pain in the neck in rivetCore:
 
 if (authorization
!strcasecmp(ap_getword_nc(POOL, authorization, ' '), Basic))
 {
   char *tmp;
   char *user;
   char *pass;
 
   tmp = ap_pbase64decode(POOL, authorization);
   user = ap_getword_nulls_nc(POOL, tmp, ':');
   pass = tmp;
   Tcl_ObjSetVar2(interp, Tcl_NewStringObj(::request::USER, -1),
  Tcl_NewStringObj(user, -1),
  STRING_TO_UTF_TO_OBJ(user, POOL),
  0);
   Tcl_ObjSetVar2(interp, Tcl_NewStringObj(::request::USER, -1),
  Tcl_NewStringObj(pass, -1),
  STRING_TO_UTF_TO_OBJ(pass, POOL),
  0);
 }
 
 Maybe we should make this its own function.  As it stands right now,
 it doesn't fit in well with its surroundings, in that if you do
 load_env  this variable won't get loaded in with the others.
 
 Speaking of which, do you know much about the
 
 NULL, /* check auth */
 
 field of the module structure?  What does one do with that?

I'm gonna' do some stuff with the check auth field.  The user
information should load into the env array though.  We shouldn't have
a separate command for loading that info.  It's just like the log
files.  If the user is present, it's logged.  If it's not, it's not.
The load_env command should load it if it's there and not if it isn't.

D

Re: Rivet C code

[Damon Courtney]

 I've mentioned it about mod_dtcl and I'll mention it here.
 
 Change the config to directories (probably the path would be relative to 
   /usr/local/apache/rivet).
 
 That's the part I like about AOLserver - when I want to move some 
 module I just copy modules/tcl/dirname between machines and add one 
 line in the config.
 
 I don't want nsd's clone (actually, I do, but I'll wait for mod_tcl with 
 that :), but the idea of splitting stuff into directories is nice.

How do you mean split into directories?  I'm afraid my work with
AOLServer is limited.

 It would be even more cool to be able to add multiple lines - so that it 
 could source multiple directories.
 
 RivetServerConf InitScript sourcedir modules/zoro/news
 RivetServerConf InitScript sourcedir modules/zoro/forum
 RivetServerConf InitScript sourcedir modules/zoro/gb
 
 Wouldn't that be cool? :)

I've thought about this.  It would be quite nice.  It's not really
that difficult to do, I think.

 Also, out of curiousity, when appending a 200kB global script, does it 
 affect Apache much? I had some problems with mod_dtcl and larger init 
 scripts. I split them into packages and did package require on top of 
 scripts.
 
 Anyway, when ab-ing static pages with larger global scripts, I was up to 
 2 times slower :(. Which was kind of strange to me since I supposed 
 global script was only loaded at apache startup (tcl8.3, w/o threads)

Well, theorhetically, it should slow down the start-up time of each
child process by just a little, but it shouldn't slow down the overall
performance of requests.  But then, I'm not sure exactly what you're
doing. 0-]

D

Rivet C code

[Damon Courtney]

Ok,

Now that I have some organization to the Tcl code, I'm about to
embark on organizing the C code a little.  I want to add some more
commands at the C level, and I need to decide the best way to do it.

Should we:

A) Compile C commands into mod_rivet.so itself.

B) Compile C commands into a single, separate library that can be loaded?

or

C) Compile C commands into separate libraries based on likeness?


I'm mostly in favor of A.  The number of commands is going to be
relatively small, hopefully.  I really hope to do most of the work in Tcl,
as I've done in the past.  People who don't know Tcl as well as I do will
often insist that some things need to be done in C, and it's mostly untrue.

So, the level of C commands written for Tcl should be relatively
small.  But, I wanted to find out what the consensus was before I start
coding any.  I am going to be dividing the C commands into separate files
based on likeness.  IE: list-manipulating commands in rivetList.c or some
such.  This will add more source files but make it much easier to find
what you're looking for.

Or, should we just leave them all in tcl_commands.c?  I'm ok with that
too.  As long as the function declarations are formatted correctly, it's
easy to find what you're looking for. 0-]

D

Re: Rivet C code

[Damon Courtney]

 Escape/unescape sound like handy things to have that could reasonably
 be considered part of the core.  Something like lremove couldn't be
 written in Tcl?  Let's have a look at the list and see if we are in
 agreement with everything.

Well, I think any command we add in C should just be compiled into
the module itself.  I don't want 10 .so files at 10k a piece lying
around everywhere.  I'm not sure just how many commands we're talking
about, but it's not going to be much.

Lremove COULD be written in Tcl, but it's definitely a command which
benefits from C.  The Tcl code to do the same amount of work in C is much
slower.  I mean, if you REALLY want, we can load stuff like this into
packages or into command libraries (.so).  I just don't see why a few
commands can't go into the module.  It's already bloated with crap we
really don't need.

  Some are packages of code, like a GDBM interface or MySQL, etc...
 
 That stuff should be kept far, far away from the core, in my
 opinion:-)
 
 Tcl has a way to load external modules, and packages like that should
 use it.

I agree.  They should be loaded in packages.  We should make support
like this in the main build, but when it's installed, it should install into
rivet/packages/gdbm, etc...  I really plan on putting a lot of packages in
Rivet.  I think that's where most of the web stuff out there is lacking.
PHP has it in spades, and that's why they beat out just about everyone
else.  They just have more support for more packages.

D

Re: page name (.ttml, .asp, .pl...?)

[Damon Courtney]

 .ttml is probably a good thing to move away from, just so we stake out
 our own namespace.
 
 How about .rsp?
 
 Borrows on a common theme, and isn't too hard to find with google (I
 like looking up pages to see who is using my stuff:-).

I guess .rsp is ok.  I was thinking more like .rvt.  Then, with later
releases, we can either keep this or go to more of a PHP type scheme to
keep parsers and versions separate.  IE: .rvt, .rvt2, .rvt3, etc...

I've been using .rhtml on my personal instances.

D

Re: escaping start/close tags in Tcl sections of tcl/html pages

[Damon Courtney]

 I'm thinking about redoing the parser to take into account situations
 like this:
 
 
 some html
 
 ?
 puts {? blah blah blah?}
 ?
 
 
 Which currently cause problems with the parser.  Thoughts?  Maybe at
 the same time, I can make it accept ?dtcl as well as ?, also...

Hrmmm...  Couldn't we just check to see if we're already in a block
of code?  I like the idea of specifying some kind of specific rivet tag,
but I think doing ?rivet is a bad idea.  I mean, I guess it works.  NWS
had its own tag which looked more like a real HTML tag.  They were just:

nws

puts FOO

/nws

OR

nwsincr_page_counter/nws

Etc...

BTW, I'm back from honeymoon, recovered from the wedding and now
recovering from Christmas, which means I'll be back on some code very
shortly.

Damon

Re: flush

[Damon Courtney]

 Ok, well 'flush stdout' should have that effect, as it stands right
 now.

Yeah, that works.  I tried a page with calling flush stdout at the
end before calling 'headers,' and it worked beautifully (failed that is).
I then tried the same page without the flush, and the headers command worked.

 We can kill them - I put them in because I had hoped to have a
 flushproc:-(

Ok.  I killed 'em.  I'll commit shortly with a few other little things.

D