Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Jeff Hobbs
 Tcl arrays are associative.  Tcl has pretty much 3 data structures:

 - scalars
 - lists
 - arrays (which are associative)

 The trick is that a list is really just a scalar with whitespace between
 the elements, unless the element is enclosed by braces, so there's really
 only two.

Woah, that last part isn't true at all, and is a common misconception
that leads people to think Tcl isn't up-to-snuff, which isn't true.

Lists are preserved in Tcl as arrays of Tcl_Obj's.  If I do the following:

proc makeList {size} {
set output 
for {set i 0} {$i  $size} {incr i} {
lappend output $i
}
return $output
}
set myList [makeList 50]

I will not have a *single* byte in memory reserved for a char.  I will
have a Tcl_Obj *objv[50] where each Tcl_Obj is an Integer object.  I
*can* then say:

puts $myList

and that will cause the whole thing to create a string representation
of each object (the list and each integer respectively).  If I do:

set otherList $myList

I don't create any new objects - I increment the reference count of the
original list by one and point to that.  If I then modify the original
list, then otherList will be left with the original (lazy copy-on-write
semantics).

That means that list's lindex accessor is O(1) and appends are O(1)
except where we need to increase the C Tcl_Obj **objv array (and that
only needs to copy the pointers).

  Jeff Hobbs The Tcl Guy
  Senior Developer   http://www.ActiveState.com/
  Tcl Support and Productivity Solutions



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Peter M. Jansson
On Monday, November 11, 2002, at 01:22 PM, Jeff Hobbs wrote:


a list is really just a scalar with whitespace between
the elements


Woah, that last part isn't true at all, and is a common misconception
that leads people to think Tcl isn't up-to-snuff, which isn't true.


[snip]


That means that list's lindex accessor is O(1) and appends are O(1)
except where we need to increase the C Tcl_Obj **objv array (and that
only needs to copy the pointers).


I'm happy to stand corrected regarding the implementation, but for someone
writing Tcl code, is there a meaningful difference between my flawed
conceptual model and the implementation?



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Brett Schwarz
On Mon, 2002-11-11 at 10:22, Jeff Hobbs wrote:
  Tcl arrays are associative.  Tcl has pretty much 3 data structures:
 
  - scalars
  - lists
  - arrays (which are associative)
 
  The trick is that a list is really just a scalar with whitespace between
  the elements, unless the element is enclosed by braces, so there's really
  only two.

 Woah, that last part isn't true at all, and is a common misconception
 that leads people to think Tcl isn't up-to-snuff, which isn't true.

 Lists are preserved in Tcl as arrays of Tcl_Obj's.  If I do the following:

 proc makeList {size} {
 set output 

Is there any difference in initializing output to list at first, or is
there no difference. IOW, should I initialize 'output' to a list object,
or does 'set output ' just create an untyped object?

   set output [list]  --- does this have any affect?

thanks,

--brett


--
Brett Schwarz
brett_schwarz AT yahoo.com



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Jeff Hobbs
  That means that list's lindex accessor is O(1) and appends are O(1)
  except where we need to increase the C Tcl_Obj **objv array (and that
  only needs to copy the pointers).

 I'm happy to stand corrected regarding the implementation, but for someone
 writing Tcl code, is there a meaningful difference between my flawed
 conceptual model and the implementation?

Only that the conceptual model underestimates the power of lists.
There are cases where lists are avoided based on the flawed conceptual
model, but they would actually be good options.  In 7.x, which was
pre-internal-objects Tcl, it was faster to create an array that was
indexed by integer, like so:

set ary(1) a
...
set ary(n) z

and then access it with $ary($num), but this is now faster with lists
based on the internal object rep, although it all looks the same at
the Tcl level.

Tcl is very simple for people to learn, but when you want to start
squeezing the speed out of it, you do have to be more concerned about
what goes on under the covers (which is a lot).  Thus, there is only
importance for the conceptual model when you want to extract the most
out of the language.

Jeff



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Jeff Hobbs
  Lists are preserved in Tcl as arrays of Tcl_Obj's.  If I do the
following:
 
  proc makeList {size} {
  set output 

 Is there any difference in initializing output to list at first, or is
 there no difference. IOW, should I initialize 'output' to a list object,
 or does 'set output ' just create an untyped object?

set output [list]  --- does this have any affect?

At this point no, although future improvements in post-processing of
bytecodes (bc-optimization) could cause that to be significant.

Right now:

1:  set output 
2:  set output {}
3:  set output [list]

all create *untyped* empty objects.  Doing a lappend or append on them
causes very little overhead in typing the object.  It's more a matter of
style, and sometimes I do write 'set output [list]'.  Some people use
'set output ' to indicate a simple var vs. 'set output {}' for list
vars (since lists uses {}s in their stringified form).

  Jeff Hobbs The Tcl Guy
  Senior Developer   http://www.ActiveState.com/
  Tcl Support and Productivity Solutions



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Rob Mayoff
+-- On Nov 11, Peter M. Jansson said:
 I'm happy to stand corrected regarding the implementation, but for someone
 writing Tcl code, is there a meaningful difference between my flawed
 conceptual model and the implementation?

{ is a string but not a list.



Re: [AOLSERVER] AOLserver Project Update

2002-11-11 Thread Dossy
On 2002.11.11, Jeff Hobbs [EMAIL PROTECTED] wrote:
  Tcl arrays are associative.  Tcl has pretty much 3 data structures:
 
  - scalars
  - lists
  - arrays (which are associative)
 
  The trick is that a list is really just a scalar with whitespace between
  the elements, unless the element is enclosed by braces, so there's really
  only two.

 Woah, that last part isn't true at all, and is a common misconception
 that leads people to think Tcl isn't up-to-snuff, which isn't true.

I think the point is that the Tcl language spec. (which is
extraordinarily simple, which is awesome) says that a list is just a
specially formatted scalar as the requirement.

How a particular Tcl interpreter optimizes this is irrelevant.  If I
wanted to start implementing a Tcl interpreter on my own Foozenwhatsit
chip tomorrow, implementing the Tcl spec. should be sufficient (but
perhaps not optimal) to run Tcl code.

But, thanks for the elaborate explanation of how Tcl8's internals have
been optimized.  ;-)

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)



Re: [AOLSERVER] AOLserver Project Update

2002-11-09 Thread Steve Manning
On Fri, 2002-11-08 at 03:46, Patrick Spence wrote:
snip

  for magazines, update my website, and run naked through the streets if
  necessary.

 I want pictures.. :)

Pictures! I'm waiting for the world tour.

Of course you realise that a precedent has already been set for this
just down the road from me by Lady Godiva (1040-1080 AD) who rode naked
through the streets of Coventry to promote her crusade on taxes.

As noon approached, so did Lady Godiva. ...

She sat straight and properly in the saddle with a look of composure on
her face; relaxed, confident, unashamed. Her hair was done in two large
braids which were curled snugly at the back of her head, one on each
side; she wore no jewelry or other adornment. People looked at her and
saw that she was not merely naked, or nude; rather she was in a higher
state of presentation -- being a correct and elevated quality of her
composure, and resulting also from the people's appraisal, appreciation,
and consideration beyond simple voyeurism.  -
http://www.abacom.com/~jkrause/godiva.html

Can we expect a similar performance?


Steve



--
Steve Manning - Linux Mandrake 9.0 - Gnome 2.0
East Goscote  - Leicester - UK +44 (0)116 260 5457
Reply to [EMAIL PROTECTED] - AIM: verbomania
--
 Only 1 in 10 people understand binary
  - the other one hasn't got a clue.
--



Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Nathan Folkman
In a message dated 11/7/2002 7:32:43 PM Eastern Standard Time, [EMAIL PROTECTED] writes:

I second the idea of organizing commands by function. I think the
current documentation at aolserver.com does a good job of this:
http://www.aolserver.com/docs/devel/tcl/api/

I hope we will still be able to have an overview document dividing
commands up by function after the commands are converted to man pages.

Jeff

Sure - once we get the docs up to date, we can then look at the myriad of different ways by which one could categorize and display them.

- n


Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Peter M. Jansson
On Thursday, November 7, 2002, at 09:27 PM, Gabriel Ricard wrote:


   - Note: my only gripe with ADP is that the following does not
appear
to work:

   if { [check $something] == 1 } {
   %
   bbreak out of Tcl mode and process some HTML
conditionally/b
   %
   }



What I usually do here is to register a tag that saves a fragment of the
page in a slot in an array, so I do stuff that looks like this:

   blah blah blah
   adp_remember name=conditional1
   bspecial blah/b
   /adp_remember
   %
   if [check $something] {
   adp_recall conditional1
   }
   %

This has the benefit of being friendly to most of the WYSIWYG HTML editors
(life is too short to edit HTML with vi, emacs or Notepad), and the code
to implement the registered tag is simple, and even requires no locking.
At the moment, because of limitations in the ADP parser, I can't nest
remembered tags, so sometimes I've got some fairly convoluted logic, but
I've been able to do a lot with this.



Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Dossy
On 2002.11.08, Peter M. Jansson [EMAIL PROTECTED] wrote:
 On Thursday, November 7, 2002, at 09:27 PM, Gabriel Ricard wrote:
 
if { [check $something] == 1 } {
%
bbreak out of Tcl mode and process some HTML
 conditionally/b
%
}
 

adp_remember name=conditional1
bspecial blah/b
/adp_remember
%
if [check $something] {
adp_recall conditional1
}
%

This is how I implement this:

%
if {[check $something] == 1} {
ns_adp_puts {
bbreak out of Tcl mode and process some HTML
conditionally/b
}
}
%

Personal preference, I guess.

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)



Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Peter M. Jansson
On Friday, November 8, 2002, at 09:35 AM, Dossy wrote:


This is how I implement this:

%
if {[check $something] == 1} {
ns_adp_puts {
bbreak out of Tcl mode and process some HTML
conditionally/b
}
}
%


The only reason I do the other thing is that the method you're using is
really hostile to Dreamweaver, Mozilla Composer, or GoLive.  I can edit my
HTML in my WYSIWYG editor, and some of the editors include facilities for
doing thing sitewide that are just as good as ns_adp_include, but don't
require a runtime execution (Why Grandma, what a static page you have.
The better to cache you with, my dear).

My personal preference is not to force HTML to be edited in a text editor,
 where possible.



Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Rogers Gene A Civ 96 CG/SCTOB
Title: RE: [AOLSERVER] AOLserver Project Update





I don't really want stir up dust on this one, not too much, because it hasn't been a real hinderance for me, but the solution presented still would allow something like:

set username [ns_conn authuser]
if { [check $something] == 1 } {
 %
iHello, %= $username% ibr 
  bbreak out of Tcl mode and process some HTML conditionally/b
 %
}
Or what's better an iteration of somekind say placing fields into a table.
TABLE
%
for {k j z} $listOstuff {
%
 TR
 TD%= $k %/TDTD%= $j %/TDTD%= $z %/TD
 /TR
%
}
%


/TABLE
To me it would just making this kind of template stuff easier if you could break up the TCL as such. 
My two-pennies.


Gene

This is how I implement this:


 %
 if {[check $something] == 1} {
 ns_adp_puts {
 bbreak out of Tcl mode and process some HTML
 conditionally/b
 }
 }
 %


Personal preference, I guess.


-- Dossy


--
Dossy Shiobara mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
 He realized the fastest way to change is to laugh at your own
 folly -- then you can let go and quickly move on. (p. 70)





Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Dossy
On 2002.11.08, Rogers Gene A Civ 96 CG/SCTOB [EMAIL PROTECTED] wrote:
 I don't really want stir up dust on this one, not too much, because it
 hasn't been a real hinderance for me, but the solution presented still would
 allow something like:

 set username [ns_conn authuser]
  if { [check $something] == 1 } {
   %
 iHello, %= $username% ibr
 bbreak out of Tcl mode and process some HTML
 conditionally/b
%
 }

I'd implement this like this:

%
set username [ns_conn authuser]
if {[check $something] == 1} {
ns_adp_puts [subst {
iHello, $usernameibr
bbreak out of Tcl mode and process some HTML
conditionally/b
}]
}
%

I'd implement this:

 TABLE
 %
 for {k j z} $listOstuff {
 %
 TR
TD%= $k %/TDTD%= $j %/TDTD%= $z %/TD
 /TR
 %
 }
 %
 /TABLE

Like this:

TABLE
%
for {k j z} $listOstuff {
ns_adp_puts [subst {
TR
   TD$k/TDTD$j/TDTD$z/TD
/TR
}]
}
%
/TABLE

-- Dossy

--
Dossy Shiobara   mail: [EMAIL PROTECTED]
Panoptic Computer Network web: http://www.panoptic.com/
  He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on. (p. 70)



Re: [AOLSERVER] AOLserver Project Update

2002-11-08 Thread Gabriel Ricard
Ok, the way I get data from the DB now is much like this:

function db_select($table, $fields, $where) {
...
}

This function creates a select statement based on the criteria I pass
in and returns a single row which I can access like this in PHP:

?
   $row = db_select('users', 'first_name,last_name,phone', 'user_id=21');
?
User: ?=$row['last_name']? , ?=$row['first_name']?br
Phone Number: ?=$row['phone']?

I use another function to retrieve multiple rows:

function db_select_list($table, $rows, $key, $value, $where, $limit,
$order) {
...
}

Like db_select(), it creates the SQL query for me. But when it receives
data back from the database it loops through it and creates a
multi-dimensional array for me. If I wanted an array of 10 users' names
and phone numbers, ordered and indexed by their id # I'd do this:

$users = db_select_list('users', user_id,phone,CONCAT('first_name','
','last_name) AS name, 'user_id', '', '10', 'user_id');

now I can do this:

table
tr
thnbsp;/th
thName/th
thPhone Number/th
/tr
?
foreach( $users as $user_id = $user_data )
{
   ?
tr
tda href=/edit_user.php?user_id=?=$user_id?Edit/a/td
td?=$user_data['name']?/td
td?=$user_data['phone']?/td
/tr
   ?
}
?
/table

One thing I've thought of is just using lists to handle this with a
custom API. So, I'd have a list where index 0 contains a list of the
key/field names for the rows, and 1-N would contain the rows. Then I
could just use the API like this:

set users [db_select_list ...]
foreach { row } { [my_array rows $users] } {
   set name [lindex [lindex $users $row] [my_array getkeyindex name]]
   ...
}

It's a bit kludgey, but I suppose that would work.

- Gabriel

On Thursday, November 7, 2002, at 10:30  PM, Michael A. Cleverly wrote:


On Thu, 7 Nov 2002, Gabriel Ricard wrote:


Wonderful!

Now my only gripe is the multi-dimensional array issue, hehe. At least
there are lots of solutions for that problem available.


I'm not at all familiar with PHP.  Could you describe (possibly
included
actual PHP code snipets or other pseudo-code) what it is you accomplish
with multi-dimensional arrays? Then we should be able to help flush out
which of the many solutions would be most apropriate.

Michael



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Lamar Owen
On Thursday 07 November 2002 13:21, Jim Davidson wrote:
 As you may have noticed, we've been making some changes with our management
 of the AOLserver project here at AOL.  Basically, we're applying some
 lessons learned from other successful OpenSource projects such as Apache to
 provide better support for you in the community.  To help you understand
 these changes, I'd like to provide you some background on AOLserver
 including my role in the project.
[snip]

As an AOLserver/AOLpress (RIP) user since May 1997, I applaud the new
direction this project is taking.  The moves of the last few weeks are
refreshing to me, and reinforce my decision to continue forward with
AOLserver rather than an Apache/PHP cookie-cutter site for WGCR Radio.  We
are in the midst of a redesign/revamp using OpenACS 4, and the direction the
base server takes or doesn't take is critical in my continued justification
of using a fairly arcane and obscure webserver.  My insistence on using this
particular server has come under fire before because the server isn't as
popular as some.

While I don't feel like I should be on core, I do want to continue helping as
I can with development in the future. As the shape of 4.0 develops, I can
focus on how that will impact the PostgreSQL driver, to the point that I may
be able to maintain that.  Maybe I will have the time I would like to have to
do this.

In all honesty, I was beginning to wonder about the wisdom of continuing to
use AOLserver in this application, but the renewed vigor in this area is
nice.  So, today will be the first chat I will attend, as ramifordistat,
because of this rejuvenation.

Jim, many thanks for the explanation, and I look forward to continuing using
this fine server.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Dave Siktberg



Thanks 
for the interesting background info, for clearly stating the current situation 
so we know how we fit in, and especially thanks for your clear commitment to 
excellence in this endeavor. I am grateful that AOLserver is available to 
supportour business venture, and look forward to helping the AOLserver 
community as bestI can. We all will benefit from wider use of 
AOLserver and from the agenda items you laid out for the rest of this 
year.

Dave 
Siktberg
Webility Corporation


Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Steve Manning
Congratulations on this move to include the community and setup the core
team. I feel it gives a very positive vibe for the future of AOLServer.

I just wondering if this new push includes any plans to promote
AOLServer amongst the IT public at large. Its difficult to promote
AOLServer as a solution to a requirement when the response is 'AOL
what?'. Just about everyone has heard of Apache - how can we achieve the
same notoriety?

Steve



--
Steve Manning - Linux Mandrake 9.0 - Gnome 2.0
East Goscote  - Leicester - UK +44 (0)116 260 5457
Reply to [EMAIL PROTECTED] - AIM: verbomania
--
 Only 1 in 10 people understand binary
  - the other one hasn't got a clue.
--



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Scott Goodwin
Good question.  In about six months I expect AOLserver and all of the
modules to be fully tested, documented and clean. At that point, it will
be hard to argue with using AOLserver for any kind of IT project from a
technical or maintenance standpoint. It is the other arguments we will
have to overcome, such as, Tcl? I thought that was obsolete and Isn't
everything going Java and J2EE?

On the popularization front I want to have a self-installing
distribution of AOLserver that will lower the bar to getting a copy of
AOLserver running with a few simple, live applications. We make it easy
for newcomers to run the server and see what it can do without having to
wade through discussion groups and docs trying to figure out how to get
something running themselves. I also plan to write a series of articles
for magazines, update my website, and run naked through the streets if
necessary.

/s.



-Original Message-
From: AOLserver Discussion [mailto:AOLSERVER;LISTSERV.AOL.COM] On Behalf
Of Steve Manning
Sent: Thursday, November 07, 2002 4:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [AOLSERVER] AOLserver Project Update


Congratulations on this move to include the community and setup the core
team. I feel it gives a very positive vibe for the future of AOLServer.

I just wondering if this new push includes any plans to promote
AOLServer amongst the IT public at large. Its difficult to promote
AOLServer as a solution to a requirement when the response is 'AOL
what?'. Just about everyone has heard of Apache - how can we achieve the
same notoriety?

Steve



--
Steve Manning - Linux Mandrake 9.0 - Gnome 2.0
East Goscote  - Leicester - UK +44 (0)116 260 5457
Reply to [EMAIL PROTECTED] - AIM: verbomania
--
 Only 1 in 10 people understand binary
  - the other one hasn't got a clue.
--



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Dave Siktberg
Scott wrote:
 ... lower the bar to getting a copy of AOLserver running ...

To revisit the documentation theme in this context of attracting new users,
I remember the sensory overload of picking up AOLserver / ACS from scratch
18 months ago.  I've been developing software on and off for 38 years
(yikes!), so it's no sweat in theory to pick up a few new languages /
platforms.  But becoming proficient is another story - in the beginning, you
have to look up almost everything - very little is yet committed to memory,
and you are in the blind spot of don't know what you don't know an awful
lot of the time.  In this mode, you want to access documentation differently
than when you are an expert or expert-in-the-making.

For example, you often want to see things organized by function, not
alphabetically -- you don't yet know the name of what you're looking for!
You want to see a function's arguments and their meaning right next to its
overall description for fastest access - not looking in two different
places.  You find it useful to browse among _all_ related commands in a
given functional area to get a full mental picture of what's available, and
start thinking about when to employ each.  A grouping scheme that's fairly
rich helps you build your knowledge this way.

I don't think this requires separate documentation for neophytes, but
perhaps a separate and differently organized set of links into the
documentation.  I created my own high-level crib sheet for the tcl API a
year ago, with links to the online documentation, and used it faithfully for
several months.  But I never fixed the places where my initial understanding
was wrong, or where items were missing, or where I never used functions and
didn't learn about them.  And then when the on-line documentation file
structure changed, I dropped it.  But it could well form a useful starting
point now.  Take a look at it here (no off-page links work):

www.webility.md/aol-tcl-a.htm   (not our AOLserver site)

I'll volunteer to take it further if y'all think it's worth it.

Dave Siktberg



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Jeff Huber
For example, you often want to see things organized by
function, not alphabetically -- you don't yet know the name of
what you're looking for!
snip

I second the idea of organizing commands by function. I think the
current documentation at aolserver.com does a good job of this:
http://www.aolserver.com/docs/devel/tcl/api/

I hope we will still be able to have an overview document dividing
commands up by function after the commands are converted to man pages.

Jeff



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Gabriel Ricard
Speaking from the point of view of a recent convert from the Apache/PHP
world, one thing that will really lower the bar for people like me is a
document (or article) along the lines of AOLServer and Tcl for
Apache/PHP users. From the end user stand point it may be good to have
packaged versions of AOLServer with snazzy front-ends for configuration
and maintenance/status of the server. I'm not a terrific write, but I
think I could maybe crank out something to assist PHP users in getting
acquainted with AOLServer and Tcl. Tcl along with AOLServer's API is
just as powerful and extensible as PHP is. In fact it offers a lot of
things that PHP simply doesn't (pooled DB connections, robust control
over the use of the HTTP protocol: responses codes, headers, mime
types, etc.).

I think the only thing I'm still hung up on is arrays. In PHP it was
ultra-easy to handle database rows using associative arrays,, and
handling large numbers of rows in multi-dimensional arrays. I don't
really know how to emulate that in Tcl, without setting up a separate
API to handle it. Anyone have some tips on that?

- Gabriel

On Thursday, November 7, 2002, at 06:13  PM, Scott Goodwin wrote:


Good question.  In about six months I expect AOLserver and all of the
modules to be fully tested, documented and clean. At that point, it
will
be hard to argue with using AOLserver for any kind of IT project from a
technical or maintenance standpoint. It is the other arguments we will
have to overcome, such as, Tcl? I thought that was obsolete and
Isn't
everything going Java and J2EE?

On the popularization front I want to have a self-installing
distribution of AOLserver that will lower the bar to getting a copy of
AOLserver running with a few simple, live applications. We make it easy
for newcomers to run the server and see what it can do without having
to
wade through discussion groups and docs trying to figure out how to get
something running themselves. I also plan to write a series of articles
for magazines, update my website, and run naked through the streets if
necessary.

/s.



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Andrew Piskorski
On Thu, Nov 07, 2002 at 08:06:37PM -0500, Gabriel Ricard wrote:
 Speaking from the point of view of a recent convert from the Apache/PHP
 world, one thing that will really lower the bar for people like me is a
 document (or article) along the lines of AOLServer and Tcl for
 Apache/PHP users. From the end user stand point it may be good to have

As a real live recent convert, what led you convert?  And what is
better/worse about AOLserver/Tcl vs. Apache/PHP?  I'm personally
curious, but maybe your answers would also be an effective
evangelization document!

 packaged versions of AOLServer with snazzy front-ends for configuration
 and maintenance/status of the server. I'm not a terrific write, but I

snazzy configuration front-ends, yuck!  Well, that was my first
reaction anyway.  If someone really wants to do this, making AOLserver
Tcl or ADP pages for controlling AOLserver should be the right way to
go.  One button out-of-the box install of useful applications sounds
potentially good though.

 I think the only thing I'm still hung up on is arrays. In PHP it was
 ultra-easy to handle database rows using associative arrays,, and
 handling large numbers of rows in multi-dimensional arrays. I don't
 really know how to emulate that in Tcl, without setting up a separate
 API to handle it. Anyone have some tips on that?

I know nothing about PHP's arrays, but it sounds like you're running
into the fact that unlike lists, which may contain other lists, Tcl
arrays can't contain other Tcl arrays, they can only contain named
references to other Tcl arrays.  I know there's been talk in the past
about changing that limitation, but I don't know whether it's
currently on the Tcl core team's agenda, or what they think about it.

In Tcl, if I wanted to get all the rows at once and store them in some
structure, I'd probably use either db_list_of_lists:

  http://openacs.org/api-doc/proc-view?proc=db_list_of_lists

or one of the related OpenACS db or templating procs.  Or, I might
store each row as a list in a Tcl array - as long as you include a
column with a unique id in the list, that works fine.

To store multiple rows each of multiple columns directly in a Tcl
array (without any embedded list structures), you just need to embed
more info into the Tcl array keys.  I've never done that myself, but
it would work, something like what the A simple database page on the
Wiki shows:

  http://mini.net/tcl/1598.html

--
Andrew Piskorski [EMAIL PROTECTED]
http://www.piskorski.com



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Dave Bauer
 I think the only thing I'm still hung up on is arrays. In PHP it was
 ultra-easy to handle database rows using associative arrays,, and
 handling large numbers of rows in multi-dimensional arrays. I don't
 really know how to emulate that in Tcl, without setting up a separate
 API to handle it. Anyone have some tips on that?

Take a look at ns_set

http://www.aolserver.com/docs/devel/tcl/api/general.html#ns_set

Dave



[AOLSERVER] ns_set, Tcl arrays Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Andrew Piskorski
On Thu, Nov 07, 2002 at 08:58:40PM -0500, Dave Bauer wrote:
  I think the only thing I'm still hung up on is arrays. In PHP it was
  ultra-easy to handle database rows using associative arrays,, and
  handling large numbers of rows in multi-dimensional arrays. I don't
  really know how to emulate that in Tcl, without setting up a separate
  API to handle it. Anyone have some tips on that?

 Take a look at ns_set

 http://www.aolserver.com/docs/devel/tcl/api/general.html#ns_set

If you have a lot of data - hundreds rather than just one row - using
an ns_set is a bad choice, as they are implemented as linearly
searched C arrays.  This gets very slow for large datasets.

If you create a huge ns_set (say, in some custom C code), it can be
MUCH faster to immediately convert it to a Tcl array or AOLserver nsv
before further processing in your Tcl code, rather than using the
ns_set directly - if you do lots of key lookups, it definitely will
be.  I know, I tested it.  (And in fact, I left it that way, as I
never did sit down and figure out how to create and populate a Tcl
array in C and then hand it to Tcl.)

AFAIK it's not mentioned anywhere in the docs, but the uses of ns_sets
in AOLserver seem to keep this in mind.  E.g., the database API puts
ONE row of data into the ns_set, not thousands; AOLserver uses ns_sets
for holding HTTP headers because you need to allow duplicate keys, but
you're never going to have that many rows.

I'd say, use an ns_set when these features are either something you
want, or not a problem:

- Key order is preserved.
- Multiple identical keys are allowed.
- Very poor key lookup scalability - slow for large datasets.

Otherwise, use something else, probably a Tcl array, maybe an nsv or
Tcl list.

Oh yeah, and I recomend not using server-wide shared ns_sets either.
Doing so is unusual anyway, but I did for a while (on AOLserver
3.3+ad13), and it caused unexplainable memory leaks, even though I
was always properly freeing the ns_set

--
Andrew Piskorski [EMAIL PROTECTED]
http://www.piskorski.com



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Gabriel Ricard
On Thursday, November 7, 2002, at 08:52  PM, Andrew Piskorski wrote:


On Thu, Nov 07, 2002 at 08:06:37PM -0500, Gabriel Ricard wrote:

Speaking from the point of view of a recent convert from the
Apache/PHP
world, one thing that will really lower the bar for people like me is
a
document (or article) along the lines of AOLServer and Tcl for
Apache/PHP users. From the end user stand point it may be good to
have


As a real live recent convert, what led you convert?  And what is
better/worse about AOLserver/Tcl vs. Apache/PHP?  I'm personally
curious, but maybe your answers would also be an effective
evangelization document!


Curiosity mainly. I work on a fairly large web application at the
office, and I've been researching ways to expand it and ensure its
maintainability in the future. I've been looking into as many different
options as possible for implementing a new version of the application.
PHP is ok, but I wanted to know what my options were. I've looked at
and played with python, ruby, even lisp (after reading about how yahoo!
stores was created/bought). PHP is nice, but it doesn't really seem to
scale that well past a single server, and I'm looking for reliability
as well as performance, so multiple webservers sitting behind a load
balancer seems like the best option. For a few months I spent time
playing with SRM, an application server for PHP. It's a great idea, but
it's not near production quality yet, and work on it is slow.

At some point I ran across Philip Greenspun's book. I think that was
mostly related to hearing about what happened to ArsDigita (damn VCs).
So, I read his book a few times, and absorbed as much else as I could.
At some point I figured I'd give AOLServer a try. I wanted to try PHP
with it as well.

I have to admit, when I first started playing with AOLServer I was
quite dumbfounded. But, after spending a week or so reading as much as
I could about it and Tcl and going to BN and reading through some
books there it seemed rather ok. I've got a growing list of the things
I think make AOLServer/Tcl great:

- AOLServer is multi-threaded. Uses less resources than Apache, and is
considerably more reliable. (Yes, Apache 2 is multi-threaded, and PHP
is thread-safe, but there are still issues with using the two together
and they are not guaranteed to be reliable for production use)

- AOLServer's configuration is considerably easier to understand (at
least for me). Now that I've taught myself Tcl, reading through the
config file is a breeze. Everything makes sense. I can easily locate
where certain configuration parts are. In Apache, PHP's configuration
is usually three different commands in three completely separate
locations (LoadModule, AddModule, and then AddTypes to handle PHP).

- DB connection pooling. Apache is great for running multiple websites,
but for running a single web application, AOLServer, frankly, is the
shit. Yes, in Apache and PHP there are persistent connections, but how
useful is that when they're only available per pre-forked process? It
doesn't save as much time as having a single pool of database
connections open and ready anytime.

- I absolutely *LOVE* the control over URL mapping in AOLserver. So far
as I know, there's no way in Apache to say take any requests for
/cmd/* and process them with this PHP function

- I like the idea of moving the authentication out of the scripts
themselves and into a tcl init script that sets up a bunch of filters.
Less work for the actual scripts to perform, and easier to maintain.

- ADP templating facilities are great. I love being able to create my
own tags and controlling how that tag is processed. That's just not
available in PHP unless you use Smarty (I don't know if it allows for
custom tags) or write it yourself.

   - Note: my only gripe with ADP is that the following does not appear
to work:

   if { [check $something] == 1 } {
   %
   bbreak out of Tcl mode and process some HTML conditionally/b
   %
   }

   In PHP that is perfectly possible.

- Another big bonus for AOLServer/Tcl is the preloading of code
libraries in your server/tcl directory. The closest PHP gets to this is
caching systems like APC and Zend Accelerator. Having all of your
utility code available instantly so it doesn't have to be parsed and
processed for each request.

- the built-in cron-like task scheduling system is great too. makes it
a lot easier to maintain your app when all of its functionality is in
one place. if only there was an MTA system that tied in with AOLServer
too... (is there??)

- stability / reliability. in benchmarking AOLServer and Apache on my
mac at the office, I found that Apache had some reliability issues. out
of 50,000 requests Apache would have about 1,000 failures. AOLServer,
on the other hand, had about 2-6. Also, when I hit Apache really hard
(50 concurrent users or more), it would soak up all availble CPU so my
system's 

Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Peter M. Jansson
On Thursday, November 7, 2002, at 09:27 PM, Gabriel Ricard wrote:


I guess I'm just spoiled by the associative arrays in PHP.


Tcl arrays are associative.  Tcl has pretty much 3 data structures:

   - scalars
   - lists
   - arrays (which are associative)

The trick is that a list is really just a scalar with whitespace between
the elements, unless the element is enclosed by braces, so there's really
only two.

Here's an example of Tcl array usage, outside of the DB context:

   set likes(Bob.color) red
   set likes(Earl.color) blue

Now you can do things like:

   puts $likes(Bob.color)

You can also do this:

   set person Bob
   puts $likes($person.color)

And that's how a lot of the DB stuff I do gets done.  I have this routine
I use that sucks in a DB query into an associative array and gives you
back a list of the primary keys in the array (assuming the primary key is
not a composite key), and then you can do this:

   foreach rowkey $rows {
   ns_puts Person: $rowkey; Favorite color:
$fetchResult(key.$rowkey.column.color)
   }

The only problem with it is that it's pretty painfully slow for large
datasets, but the logic is simple enough that you can probably figure out
how it works just from this description.



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Jeff Huber
- Note: my only gripe with ADP is that the following
does not appear to work:

if { [check $something] == 1 } {
%
bbreak out of Tcl mode and process some HTML
conditionally/b
%
}


Gabriel,

I built an ADP Parser that works like that. I haven't used it since
AOLserver 3.0 though I'd think it'd still work. You can get it here:
http://aolserver.am.net/srccontrib/adp/index.html

Thanks for the PHP comparison.

Jeff



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Gabriel Ricard
Wonderful!

Now my only gripe is the multi-dimensional array issue, hehe. At least
there are lots of solutions for that problem available.

- Gabriel

On Thursday, November 7, 2002, at 09:47  PM, Jeff Huber wrote:


   - Note: my only gripe with ADP is that the following
does not appear to work:

   if { [check $something] == 1 } {
   %
   bbreak out of Tcl mode and process some HTML
conditionally/b
   %
   }



Gabriel,

I built an ADP Parser that works like that. I haven't used it since
AOLserver 3.0 though I'd think it'd still work. You can get it here:
http://aolserver.am.net/srccontrib/adp/index.html

Thanks for the PHP comparison.

Jeff



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Michael A. Cleverly
On Thu, 7 Nov 2002, Gabriel Ricard wrote:

 Wonderful!

 Now my only gripe is the multi-dimensional array issue, hehe. At least
 there are lots of solutions for that problem available.

I'm not at all familiar with PHP.  Could you describe (possibly included
actual PHP code snipets or other pseudo-code) what it is you accomplish
with multi-dimensional arrays? Then we should be able to help flush out
which of the many solutions would be most apropriate.

Michael



Re: [AOLSERVER] AOLserver Project Update

2002-11-07 Thread Patrick Spence
- Original Message -
From: Scott Goodwin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, November 07, 2002 4:13 PM
Subject: Re: [AOLSERVER] AOLserver Project Update


 Good question.  In about six months I expect AOLserver and all of the
 modules to be fully tested, documented and clean. At that point, it will
 be hard to argue with using AOLserver for any kind of IT project from a
 technical or maintenance standpoint. It is the other arguments we will
 have to overcome, such as, Tcl? I thought that was obsolete and Isn't
 everything going Java and J2EE?

I see one big obstacle... and one I hope can be overcome..there are lots of
third party add ons for apache that would work seemlessly if we had
compatibility with the more popular MODs for apache.  If we had perfect
emulation of (for example) mod_rewrite it would make quite a few packages
that are popular (like gallery from gallery.menalto.com) work much better..
I think one of the best ways to get converts from the top webservers is to
offer them invisible migration.. otherwise we have to limit ourselves to
people willing to convert lots of code or people setting up fresh servers..
and neither of those are large in volume...

Make it apache compatible at the basic level (with add on modules) and it
will be a lot easier to convert them...

 for magazines, update my website, and run naked through the streets if
 necessary.

I want pictures.. :)


--
  Patrick Spence arivenATarivenDOTcom
  www.RandomRamblings.com
  www.Ariven.com