Re: [AOLSERVER] New Config API's which document default values.
In a message dated 3/6/05 11:08:33 AM, [EMAIL PROTECTED] writes: In my own experience reading AOLserver code, what I'd really wished for was more comments explaining WHY something was being done, as opposed to merely what or how. (I suspect I've rambled on about this in the past...) Andrew is right -- there isn't enough "why" commenting in the code. I often write (or rewrite) sections of the code assuming folks understand the flow of all the callbacks and threading junk or that there's some nonexistent architecture overview guide. We really do need that overview guide which will be a lot of work. In the meantime, we could go back and add some comments around areas of the code which are very particularly odd -- how about we compile a list of these sections? I'm thinking Tcl init and connection handling and garbage collection can be complicated and could use some explaination in the code. -Jim 2">
Re: [AOLSERVER] New Config API's which document default values.
On Sun, Mar 06, 2005 at 07:40:11PM -0500, Dossy Shiobara wrote: On the other hand, I do think a set of very high-level design documents that outline the overall strategies implemented in AOLserver would be useful. I'm thinking at the level that would be suitable as bullet points on a PowerPoint deck, like: AOLserver 4.1 employs a single driver thread to accept TCP connections then dispatches requests to connection threads for request processing. That's as detailed as I'd go -- this way, as the actual implementation changes, it doesn't immediately obsolete large chunks of the design doc. No. When I say document the internals I mean REALLY EXPLAINING them, educating the reader as to just what all the major moving parts really actually do, and why. Ideally, engineer to engineer mental download, all the thoughts and trade-offs that drove Jim's design explicated in text. This is a totally different thing from merely sketching out the very highest-level concepts. A sketch of all the high-level concepts would indeed be valuable, I just want to be clear that such a sketch is in no way a replacement for a full guide to the design of the AOLserver internals. I think Jim D.'s old Tcl conference presentation on AOLserver in Digital City is an excellent example of the high-ish level sketch you're talking about. In the course of discussing a very large real-world web/db application, it covered an interesting variety of hands-on AOLserver details. But it definitely wasn't anything close to what a new AOLserver hacker would consider adequate for groking the AOLserver internals, nor would anyone expect it to be. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Sun, Mar 06, 2005 at 07:40:11PM -0500, Dossy Shiobara wrote: 9.99 times out of 10 (feel free to round up) if the code isn't communicating its intent, the answer is NOT to comment the code, but to refactor it so it communicates its intent clearly. If there's a I believe that to be a grossly innaccurate characterization. I am mildly obsessive about re-factoring and cleaning up my own code, and yet, there often still remain some critical bits which even *I*, the guy we wrote the whole thing in the first place, feel compelled to keep carefully commented just so that I myself will still understand what and why I did there a few months (occasionally years...) later. (Some typical areas for such are: communication between concurrent threads; complicated trigger-fired stuff in RDBMS systems; race conditions, atomicity, and transactional semantics; and dynamic code or query generation.) And if even I the original author need say, 5% of the code commented to stay productive, others are going to need more. Probably much more. I assert that for real-world (aka, complicated) problems, the solution-in-code tends to converge towards the maximum complexity with which the developer's mind can cope. Review and feedback from others plus refactoring helps combat that tendency, but, there's nothing inherently WRONG with that tendency! Documented human-readable design intentions - as found in good code comments - HUGELY help RAISE the maximum level of code complexity with which the developer's mind can cope, and doing so is often a LOT easier and less bug prone then thinking up some smarter way to refactor something. Such comments can also help immeasurably if/when you finally do refactor those hairy parts of the code... A codebase is a solution to a problem. I suggest therefore that attempting to artificially limit the complexity of your solution to that level which developers can understand solely from the code, WITHOUT recourse to good comments, is not a good idea, neither in practice nor in theory. Good comments let you create more sophisticated, more powerful solutions, yet still have the result be equally understandable and maintainable. Personally, I also find that the process of commenting on the current baroqueness often helps me think up better ways to solve the same problem. I think better when I'm forced to beat my thoughts into clarity on (electronic) paper. In a lousy, poorly maintained pile of spaghetti code, perhaps 99.9% of the need why/how comments for clarity areas really are amenable to simple immediate refactoring of the code, done so well and thoroughly that the new code then needs no further explanatory comments. But in a well-maintained codebase, that should NEVER be true. Rather, all or most of the parts which are confusing or tricky will be so because they really are solving a harder problem, and while refactoring and improving that may well be possible, it sure as heck won't be easy or trivial. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Mon, Mar 07, 2005 at 10:10:15AM -0500, Jim Davidson wrote: I'm thinking Tcl init and connection handling and garbage collection can be complicated and could use some explaination in the code. Yes, that would be great! Those are areas I've never yet really NEEDED to understand, but which I'd very much LIKE to understand, even if only for educational purposes. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Tue, Mar 01, 2005 at 04:41:00PM -0800, Tom Jackson wrote: Okay, I have taken the time to browse several source files. I think the cleanest I have found is binder.c, but it still has several styles, or inconsistencies. I'm talking only about whitespace here, not any of the naming conventions, or broader considerations. The PostgreSQL project uses a program to periodically go through the source and make it conform to their standards. I think it's called pgindent, can't remember. Migth be worth a look. -Roberto -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Mon, Mar 07, 2005 at 12:38:58PM -0500, Andrew Piskorski wrote: On Mon, Mar 07, 2005 at 10:10:15AM -0500, Jim Davidson wrote: I'm thinking Tcl init and connection handling and garbage collection can be complicated and could use some explaination in the code. Yes, that would be great! Those are areas I've never yet really NEEDED to understand, but which I'd very much LIKE to understand, even if only for educational purposes. Me too! -Roberto -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
In a message dated 3/7/05 11:33:52 AM, [EMAIL PROTECTED] writes: On Mon, Mar 07, 2005 at 12:38:58PM -0500, Andrew Piskorski wrote: On Mon, Mar 07, 2005 at 10:10:15AM -0500, Jim Davidson wrote: I'm thinking Tcl init and connection handling and garbage collection can be complicated and could use some explaination in the code. Yes, that would be great! Those are areas I've never yet really NEEDED to understand, but which I'd very much LIKE to understand, even if only for educational purposes. Me too! OK -- I'll focus in those areas and try to checkin some stuff in a week or so. Thanks, -Jim 2">
Re: [AOLSERVER] New Config API's which document default values.
On Sat, Mar 05, 2005 at 04:12:41PM -0800, Tom Jackson wrote: I would think it is easier to simply apply a few fixes to a single file the next time you touch it, and commit the whitespace changes first, than it would be to only correct the code you touch. Ok, I agree, you've convinced me. Beyond whitespace, Jim has put in a few words about the structure of a file. Yes, did anyone stick that onto the Wiki? (Hm, actually, I don't even see where on the Wiki it should go. We need to add a new section along with the links to the API documentation?) The result of a written standard with a conforming codebase will be cleaner code contributed by future developers, and much simpler process of helping new developers fix their contributions. You would be able to point to the I think this is grossly optimistic. Over time I've read a fair amount of both core AOLserver code and various modules, and hacked on some of it, and frankly, I don't remember noticing any major formatting problems. If they are present, they were never a major obstacle to my understanding of the code. So, although it is certainly a useful and laudible endeavor to clean up the formatting of the code to use only spaces (no tabs) and otherwise better conform to an AOLserver engineering manual style guide, let's be honest about the real benefits: It will make hacking on AOLserver more pleasant and a bit more productive. But that's about it. It's not going to magically attract new developers or something. In my own experience reading AOLserver code, what I'd really wished for was more comments explaining WHY something was being done, as opposed to merely what or how. (I suspect I've rambled on about this in the past...) My impression of the AOLserver code, is that as I came to understand each bit, I almost always realized that the code was actually clear, correct, and good, it just sometimes took me longer than optimal to figure that out. In particular, the use of callback-like constructs makes it harder to manually trace through the flow of control, ESPECIALLY when you don't yet have a model in your head - or in the code comments - of why and how the callbacks are arranged the way they are. (Unfortunately it's been long enough that I don't have a more concrete example handy.) That isn't really a knock against AOLserver, as I don't think I've seen ANY codebase that included enough design and internals comments to satisfy a new developer. But, it does point out one additional way we could make AOLserver codebase be made much better than average. Since the code is already quite good, it is much more amenable (than the average pile of haphazard code) to a clear description of the design intention behind it! So, as AOLserver developers maintain and renovate any code, I highly encourage you not only to fix distracting formatting issues, but to also add any additional explanatory comments which you believe useful, especially of the why type. My basic rule of thumb in my own programming work is, when reading code, anytime I WISH there was a comment explaining something, I stick in a TODO comment, maybe like this: TODO: Why are we fooing the bar here? Doesn't this cause a race condition with baz?? [EMAIL PROTECTED], 2005/03/06 12:22 EST Then once I actually come to understand that part of the code (hopefully soon), I replace that with something answering my original question, or pointing out why that concern does not actually apply in this case because of clever trick X, or whatever. It is no doubt possible to go overboard with that sort of commenting, but my experience is that most projects and most developers do far too little of it, not too much. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.03.06, Andrew Piskorski [EMAIL PROTECTED] wrote: So, as AOLserver developers maintain and renovate any code, I highly encourage you not only to fix distracting formatting issues, but to also add any additional explanatory comments which you believe useful, especially of the why type. I'd rather folks not litter the code and instead send an email to the AOLSERVER mailing list referring to the file name(s) and CVS revision numbers and line numbers that they're questioning. 9.99 times out of 10 (feel free to round up) if the code isn't communicating its intent, the answer is NOT to comment the code, but to refactor it so it communicates its intent clearly. If there's a block of code that needs to be refactored out and its purpose named with a function, then apply the Extract Method refactoring, especially if it removes duplication. Of course, in a multi-threaded app. we have to deal with locks and lock contention, and minimizing the time spent in a hot section is important -- so, extracting methods may not be attractive (unless we start using compiler hints to inline methods, etc. but lets not go there yet). In those cases, perhaps a comment is appropriate, but I'd still rather at least attempt to refactor the code itself to make it communicate better before giving in and commenting it. Comment graffiti (I WUZ HERE, WHUT DUZ THIS C0D3 [EMAIL PROTECTED]) is just that. Please, don't do it. :-) Use the mailing list to ask questions *OR* the online chat. ... On the other hand, I do think a set of very high-level design documents that outline the overall strategies implemented in AOLserver would be useful. I'm thinking at the level that would be suitable as bullet points on a PowerPoint deck, like: AOLserver 4.1 employs a single driver thread to accept TCP connections then dispatches requests to connection threads for request processing. That's as detailed as I'd go -- this way, as the actual implementation changes, it doesn't immediately obsolete large chunks of the design doc. -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Tue, Mar 01, 2005 at 08:10:23PM -0500, Dossy Shiobara wrote: On 2005.03.01, Tom Jackson [EMAIL PROTECTED] wrote: Indeed, there's places in the codebase where hard tabs still exist. They should be replaced with 4 spaces where appropriate, but only when you're actually touching that portion of the code to fix a bug or change functionality. Why? I would suggest the exact opposite, that it would be more useful to go through and commit all untabify changes at once for each module. GNU indent is cool, but not being maintained and it's really geared to the GNU C style which sucks (unless you're am Emacs person, in which case, you're already used to seeing that ugliness if you use its c-mode). Nonsense. Emacs users simply edit their ~/.emacs to make Emacs use a different, non-sucky C mode style. The fact that the default c-mode style is so hideious is merely annoying. Worse, is that by default Gnu Emacs sticks hard tabs in everywhere, and that's everywhere, not just for C code. Each user must also fix that. -- Andrew Piskorski [EMAIL PROTECTED] http://www.piskorski.com/ -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Saturday 05 March 2005 13:56, Andrew Piskorski wrote: On Tue, Mar 01, 2005 at 08:10:23PM -0500, Dossy Shiobara wrote: On 2005.03.01, Tom Jackson [EMAIL PROTECTED] wrote: Indeed, there's places in the codebase where hard tabs still exist. They should be replaced with 4 spaces where appropriate, but only when you're actually touching that portion of the code to fix a bug or change functionality. Why? I would suggest the exact opposite, that it would be more useful to go through and commit all untabify changes at once for each module. I would think it is easier to simply apply a few fixes to a single file the next time you touch it, and commit the whitespace changes first, than it would be to only correct the code you touch. For one, consistent whitespace formatting makes it easier to read the code, which I would think would help you read it and understand it faster. Second, I don't want my name to show up on a source file that is wack, and if it does, I'd rather the mistakes be mine. Third, and most important, we will avoid spending hours discussing what the rules are, and maybe persuade more folks to actually contribute. As it stands, I spent more hours discussing whitespace than I spent writing a module (a module used to test and use the changes to the config.c code). Yet, there is still no word on simple little issues. Although the indent program is probably unsafe, since it cannot guarantee that the second and third, etc. passes of code through the program would remain unchanged, the fact is, the command line switches point out that most formatting can be easily specified. And since we are human, not machine, we will likely be able to do this a little more simply than indent. Beyond whitespace, Jim has put in a few words about the structure of a file. This is very helpful, but the main impediment to getting new contributors to actually commit their code is to bring all the code up to a written standard. Written standards can only communicate so much, but code which everyone agrees meets the standard is crucial to explaining the standard. Right now, I would say, not a single file can be named which meets this test. Fortunately, as Jim has pointed out, the code is in good shape beyond the whitespace confusion. The result of a written standard with a conforming codebase will be cleaner code contributed by future developers, and much simpler process of helping new developers fix their contributions. You would be able to point to the specific problem, and to similar code elsewhere. Of course, with good examples, this would be needed even less, so those reviewing commits or patches would have an easier job. It would also focus discussion on features and implimentations, and away from mundane issues. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Friday 25 February 2005 05:56, Nathan Folkman wrote: i recommend that you follow the aolserver style guide, which is heavily based on the tcl style guide. however, when in doubt, it is best to follow the style you see in the core code, as almost all of it is consistently formatted. it shouldn't be too difficult to infer the style by looking at a few different source files. Okay, I have taken the time to browse several source files. I think the cleanest I have found is binder.c, but it still has several styles, or inconsistencies. I'm talking only about whitespace here, not any of the naming conventions, or broader considerations. So I'm really stuck wondering what to do. The source files differ in substantial ways from the written guides. The source files differ from each other, and each file itself represents several styles. I had the timely fortune of needing to replace my crashed hard drive this weekend and I noticed a program being installed called 'indent'. Indent is a program which reformats the whitespace of C source code. Given a series of switches, which can be maintained in a file, it can help developers transform the files they are working on into a consistent style. It seems to have enough switches to handle more than has ever been covered in either of the written guides. I'm sure there are downsides, but it sounds like a good way to document one small aspect of the development standards for AOLserver. Has anyone had good or bad experiences with this tool? tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.03.01, Tom Jackson [EMAIL PROTECTED] wrote: Okay, I have taken the time to browse several source files. I think the cleanest I have found is binder.c, but it still has several styles, or inconsistencies. I'm talking only about whitespace here, not any of the naming conventions, or broader considerations. Indeed, there's places in the codebase where hard tabs still exist. They should be replaced with 4 spaces where appropriate, but only when you're actually touching that portion of the code to fix a bug or change functionality. So I'm really stuck wondering what to do. The source files differ in substantial ways from the written guides. The source files differ from each other, and each file itself represents several styles. Stick with what's in the published AOLserver Engineering Manual's style guide. If/when you touch code that doesn't comply, then only then make the necessary changes to make it do so. I had the timely fortune of needing to replace my crashed hard drive this weekend and I noticed a program being installed called 'indent'. Indent is a program which reformats the whitespace of C source code. Given a series of switches, which can be maintained in a file, it can help developers transform the files they are working on into a consistent style. It seems to have enough switches to handle more than has ever been covered in either of the written guides. GNU indent is cool, but not being maintained and it's really geared to the GNU C style which sucks (unless you're am Emacs person, in which case, you're already used to seeing that ugliness if you use its c-mode). If you want to try, go ahead and try to come up with the necessary command line switches for GNU indent that will format AOLserver source to conform to the currently published style guide. If it's possible, then this might be worth documenting on the wiki, what command line options are appropriate, and perhaps include it in the style guide itself. I'm sure there are downsides, but it sounds like a good way to document one small aspect of the development standards for AOLserver. Has anyone had good or bad experiences with this tool? I wouldn't say bad but I definitely had to extend GNU indent when I was using it and I tried to find a maintainer to submit patches to and the last known maintainer never responded to me -- not even to tell me that he wasn't accepting patches. -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
In a message dated 3/1/05 7:52:22 PM, [EMAIL PROTECTED] writes:
I had the timely fortune of needing to replace my crashed hard drive this
weekend and I noticed a program being installed called 'indent'. Indent is a
program which reformats the whitespace of C source code. Given a series of
switches, which can be maintained in a file, it can help developers transform
the files they are working on into a consistent style. It seems to have
enough switches to handle more than has ever been covered in either of the
written guides.
I'm sure there are downsides, but it sounds like a good way to document one
small aspect of the development standards for AOLserver.
Has anyone had good or bad experiences with this tool?
Hi,
I tried a few times to get all the switches just right for indent but failed. Actually, I got much closer with the old BSD indent but the GNU indent was more trouble. Would be cool if it worked.
Otherwise, I'm a big believer in a consistent style guide and I greatly appreciate when folks follow the standard -- it makes it much easier for all of us to understand new code. The standard is a bit dated but still a good guide. It varies from the Tcl guide a bit by choice -- I can't remember all the reasons but I think they were mostly about assuming an ANSI C compiler, e.g., eliminating needless casts from void * types.
Current variances from the standard are some times the result of folks who didn't follow the standard but more often sloppy or lazy behavior on my part, e.g., skipping a function header comment and/or form-feed formating. My bad -- sorry about that.
In general, here are the style misses I really notice:
- Mixed up indent level stuff -- I'm ok with some mix of 8-space tabs and true spaces but I have trouble with folks using tabs only and assuming I'd just set the editor to 4 space mode. Microsoft's Visual C interface was particularly good about getting this right so I think code I wrote there is probably closer to the goal.
- Variable name scope -- Ns_Foo for public, NsFoo for private, all other functions file-scope. The only exceptions are ns_ function which are (mostly) wrappers of stdlib, e.g., ns_malloc and malloc -- folks shouldn't need to write anymore of those.
- Name convention for Tcl commands -- best to use NsTclFooCmd or NsTclFooObjCmd which makes it easy to search for them in the code.
- Code padding (e.g., if (a != b), not if ( a != b )) and non-compliant variable names, especially those with an underscore (e.g., my_thing_ptr instead of myThingPtr) -- I find missing these a real visual distraction.
- Comments which are not complete sentences and/or formatted properly.
- Ordering functions in a file wrong (I often get this wrong): It's best with init routines, public C API's, Tcl commands, aolserver-private API's, and finally static routines, in that order, e.g.:
NsInitThings
Ns_ThingCreate
Ns_ThingDo
Ns_ThingDont
NsTclThingObjCmd
NsStartThings
NsStopThings
CreateThing
DestoryThing
- Finally, and I think some will disagree, over-zeolous Tcl object command usage, in particular not using the simple and clean Tcl_AppendResult to format error messages. I know some folks would like everything to be Tcl_Obj stuff and the new Tcl_WrongNumArgs and command switch stuff is nice but in an error condition I think stuff like this is a bit distracting:
Tcl_SetObjResult(interp, Tcl_NewStringObj("package not known", -1));
I've found myself re-writing these sorts of things back to the old clean style:
Tcl_AppendResult (interp, "cannot join thread ", buf, NULL);
As it's an error path, performance isn't an issue and there's not much work being done anyway. I see the Tcl core mostly uses the old Tcl_AppendResult as well.
Otherwise, I think we've got a pretty clean code base here.
Thanks,
-Jim
2">
Re: [AOLSERVER] New Config API's which document default values.
? let me try again... i recommend that you follow the aolserver style guide, which is heavily based on the tcl style guide. however, when in doubt, it is best to follow the style you see in the core code, as almost all of it is consistently formatted. it shouldn't be too difficult to infer the style by looking at a few different source files. i think it would then be a good idea to review the aolserver style guide to remove any ambiguities that exist, and finally to clean up any source code that does not conform to those style guidelines. make sense? - n On Feb 25, 2005, at 4:05 AM, Tom Jackson wrote: On Thursday 24 February 2005 13:46, Nathan Folkman wrote: Yeah, that's pretty much the point I was hoping to illustrate... ;-) We need to update the AOLserver Style Guide so that it accurately documents the actual style guidelines that are used throughout the code. Until that happens, it's a good idea to try and follow Jim's style where possible, as that is the style to which most of the code is written. You're joking, right? tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Feb 23, 2005, at 9:59 PM, Brett Schwarz wrote:
just a couple of suggestions, from a very quick first
look (it is hard too sifting through the TAB changes,
as Dossy said):
1) Tcl already has Tcl_GetBoolean...this could be used
instead of the boolean...I believe...no big deal
though
Good idea. It's actually already being used in a few places. I think
it's a good idea to be as consistent as possible, using core Tcl APIs
where it makes sense.
adpcmds.c: if (Tcl_GetBooleanFromObj(interp, objv[2], new) !=
TCL_OK) {
conn.c: if (Tcl_GetBooleanFromObj(interp, objv[2], flag) !=
TCL_OK) {
tclconf.c: if ( Tcl_GetBoolean(interp,
argv[defaultIndex], iValue)
tclsock.c: result = Tcl_GetBooleanFromObj(interp, objPtr, ok);
2) This might be a good time to start moving away from
Tcl_AppendResult...just a thought. This is for AS in
general. Note: there is also a Tcl_WrongNumArgs
function that probably could be used in a few places
too.
Same as above - Tcl_WrongNumArgs is much cleaner.
3) similar to 2), it might be a good time to start
moving to Obj based commands.
I think this is a good idea as well, and a fair amount of work has
already been done. I also personally think Tcl Obj commands are much
nicer to work with.
--- Tom Jackson [EMAIL PROTECTED] wrote:
I have added a few new C API's for setting (just
adding, not replacing) config
params during startup.
The new API's are named after the current Get API's,
for instance:
Ns_ConfigGetValue
Ns_ConfigSetValue
Due to the amount of common code which would have
been repeated in the new
API's, I factored out this code into private
procedures.
I also compared the resulting code with the Tcl C
API standards contained in
http://www.tcl.tk/doc/engManual.pdf.
There were many deviations from this standard in the
original file, so I made
any changes that I noticed, the result is that the
file is mostly new.
If there are any style changes which need to be
made, please point them out on
this list, so I can make the changes.
I included a sample use of the new APIs in nslog.c.
The diff, and changed files are located at:
http://rmadilo.com/m2/config-changes/
If this is something that should be included in
future versions of AOLserver,
I need to know which cvs version to do a diff on,
and how. If there are
further suggestions, please note them on this list.
For one, it might be nice to have a ParamDelete
procedure to hide things like
password params after they have been read. Note
that all config sections are
returned from every virtual server with the current
tcl api commands.
The new APIs are only useful for adding params for
values which are not in the
config file. The section Ns_Set is appended to only
if the section exists,
but in every case, the new APIs return the value
that is needed to set the
default.
I haven't investigated the case where a null
(missing) default is used later
to determine configuration (such as rollFmt), for
now these will remain
undocumented, but I think I can add a check for a
null value to get it to
work.
Untested is Int64.
I'm writing a C module to run tests over the APIs.
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an
email to [EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message.
You can leave the Subject: field of your email
blank.
=
--brett
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.02.23, Brett Schwarz [EMAIL PROTECTED] wrote: 1) Tcl already has Tcl_GetBoolean...this could be used instead of the boolean...I believe...no big deal though Sure. Same with using Tcl_GetInt. I don't think Tcl has a Tcl_GetInt64 equivalent, unfortunately, so we'll have to continue to use ours. 2) This might be a good time to start moving away from Tcl_AppendResult...just a thought. This is for AS in general. Note: there is also a Tcl_WrongNumArgs function that probably could be used in a few places too. 3) similar to 2), it might be a good time to start moving to Obj based commands. These two are general code freshening comments -- it's nothing specific about Tom's change. -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Wednesday 23 February 2005 18:59, Brett Schwarz wrote: just a couple of suggestions, from a very quick first look (it is hard too sifting through the TAB changes, as Dossy said): 1) Tcl already has Tcl_GetBoolean...this could be used instead of the boolean...I believe...no big deal though 2) This might be a good time to start moving away from Tcl_AppendResult...just a thought. This is for AS in general. Note: there is also a Tcl_WrongNumArgs function that probably could be used in a few places too. 3) similar to 2), it might be a good time to start moving to Obj based commands. Actually this is what I will do. I was working on another module and decided to switch to the new coding style. I think it is a good time to do this for this file, as the changes I am adding require a lot of code reorganization. This is probably hard to see through the cvs diff due to the noise of the whitespace changes. The new complete file is at http://rmadilo.com/m2/config-changes/nsd/config.c tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
Seems like good feedback for an AOLserver Coding Style guide. On Feb 24, 2005, at 10:42 AM, Dossy Shiobara wrote: Sure. Same with using Tcl_GetInt. I don't think Tcl has a Tcl_GetInt64 equivalent, unfortunately, so we'll have to continue to use ours. 2) This might be a good time to start moving away from Tcl_AppendResult...just a thought. This is for AS in general. Note: there is also a Tcl_WrongNumArgs function that probably could be used in a few places too. 3) similar to 2), it might be a good time to start moving to Obj based commands. These two are general code freshening comments -- it's nothing specific about Tom's change. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Thursday 24 February 2005 08:22, Nathan Folkman wrote: Seems like good feedback for an AOLserver Coding Style guide. I'm reworking a module, actually two, in the new style. I'll be focusing on these to use as examples of coding style, so once completed I would encourage any nits that anyone is willing to throw my way. I have the originals in the old style, so they can be used as a comparison for code migration. The Tcl/Tk Engineering Manual http://www.tcl.tk/doc/engManual.pdf is very helpful, especially the introduction. Consistency appears to be high on the list of goals, regardless of the actual details. This intro, coupled with specific examples, which are pretty thin in the Manual, would go a long way in explaining how AOLserver coding should be done, even if it isn't always represented that way in every file. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.02.24, Nathan Folkman [EMAIL PROTECTED] wrote: Seems like good feedback for an AOLserver Coding Style guide. You mean this: http://www.aolserver.com/docs/devel/tech/standards.html Perhaps it's time to add a few new items under the Idioms, Canonical Forms, and Recommended Practices section regarding use of Tcl_WrongNumArgs and such. -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Thursday 24 February 2005 09:37, Nathan Folkman wrote:
Exactly. Thinking of enumerating some higher level guidance:
1. Where ever possible use or wrap core Tcl APIs vs. creating your own
implementation.
2. Tcl APIs should be implemented as Tcl Obj commands.
...etc...
So I have a few questions about the finer details. Reading the Tcl/Tk Manual,
I have been using these conventions:
1. no tabs, indents are 4 spaces.
2. continuation lines are indented 8 spaces:
3. continuations in if ( ) conditions begin with something that doesn't look
like a function call: , ||, etc.
4. continuations of function prototypes/defs are also indented 8 spaces, not
lined up with the first arg.
5. lines have no trailing whitespace.
There are a lot of differences still in config.c:
1. function prototypes of exported functions are missing.
2. functions are declared with the type on one line and the name on the
following:
char *
Ns_MyChar(...
{
}
Examples:
static int
Poly1305AESObjCmd(ClientData context, Tcl_Interp *interp, int objc,
Tcl_Obj **objv); /* 8 space continuation */
extern void
Ns_Poly1305Authenticate( /* Tcl Manual suggests this style */
char auth[16],
char kr[32],
char nonce[16],
char *message,
unsigned int messageLen); /* each arg on separate line */
static void /* good or bad */
ConfigSet(char *section, char *key, char *value)
{
Ns_Set *set;
if (section != NULL
key != NULL /* indent 8 on continuation, start */
( (set = Ns_ConfigGetSection(section)) != NULL) ) {
Ns_SetPut(set, key, value); /* back to 4 indents */
Ns_Log(Debug, ConfigSet: Added %s = %s to %s, key, value, section);
} else {
Ns_Log(Debug, ConfigSet: Unable to add key %s to section %s,
key, section);
}
return;
}
Comment code examples:
The AOLserver style guide says to use where the code actually uses -
Below, Ns_ConfigGetSections:
1. follows one blank line after --- line which extends to column 79
2. is indented one space
3. followed by space -- ' --'
3. is followed by a blank line
Description:
1. indented 5 spaces beyond the previous indent, so 6 spaces from the *
2. continuations are lined up???
3. followed by a blank line.
Overall:
No trailing whitespace
Should text end in a period, or no punctuation?
/*
*--
*
* Ns_ConfigGetSections --
*
* Return a malloc'ed, NULL-terminated array of sets, each
* corresponding to a config section
*
* Results:
* An array of sets
*
* Side effects:
* The result is malloc'ed memory
*
*--
*/
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
There are a lot of differences still in config.c: function prototypes of exported functions are missing. Oops, prototypes for extern are in a header file, in this case nsd.h. I guess the question is, should there have been a config.h, probably the way it should be done with a module. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.02.24, Tom Jackson [EMAIL PROTECTED] wrote: There are a lot of differences still in config.c: function prototypes of exported functions are missing. Oops, prototypes for extern are in a header file, in this case nsd.h. I guess the question is, should there have been a config.h, probably the way it should be done with a module. include/ns.h is for public C API prototypes. nsd/nsd.h is for private ones that aren't declared static to the .c file they're defined in. More often than not, most functions should NOT NOT NOT NOT NOT be exported. They should be file static scoped. Which means, no prototype of their signature should go into include/ns.h NOR nsd/nsd.h. -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
It should probably be updated. The rule of thumb that I always followed
was to code in the same style as Jim, who himself followed the Tcl
Style Guide. That said, it would be good to actually enumerate this
better so that there is no confusion, then work to clean up code that
doesn't follow the style guide. Examples:
Good:
^L
/*
*--
*
* NsTclNHttpObjCmd --
*
* Implements the new ns_http to handle HTTP requests.
*
* Results:
* Standard Tcl result.
*
* Side effects:
* May queue an HTTP request.
*
*--
*/
int
NsTclNHttpObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
Bad:
^L
/*
*--
* Find the specified queue and lock it if found.
*
* Specify locked true if the queuelock is already locked.
*
* PWM: With the new locking scheme refCount is not longer necessary.
* However, if there is ever a case in the future where an unlocked
* queue can be referenced then we will again need the refCount.
*
* Results:
*
* Side effects:
*
*--
*/
static int LookupQueue(Tcl_Interp *interp,
CONST char *queueId,
Queue**queuePtr,
int locked)
{
Tcl_HashEntry *hPtr;
On Feb 24, 2005, at 3:18 PM, Tom Jackson wrote:
On Thursday 24 February 2005 09:37, Nathan Folkman wrote:
Exactly. Thinking of enumerating some higher level guidance:
1. Where ever possible use or wrap core Tcl APIs vs. creating your own
implementation.
2. Tcl APIs should be implemented as Tcl Obj commands.
...etc...
So I have a few questions about the finer details. Reading the Tcl/Tk
Manual,
I have been using these conventions:
1. no tabs, indents are 4 spaces.
2. continuation lines are indented 8 spaces:
3. continuations in if ( ) conditions begin with something that
doesn't look
like a function call: , ||, etc.
4. continuations of function prototypes/defs are also indented 8
spaces, not
lined up with the first arg.
5. lines have no trailing whitespace.
There are a lot of differences still in config.c:
1. function prototypes of exported functions are missing.
2. functions are declared with the type on one line and the name on the
following:
char *
Ns_MyChar(...
{
}
Examples:
static int
Poly1305AESObjCmd(ClientData context, Tcl_Interp *interp, int objc,
Tcl_Obj **objv); /* 8 space continuation */
extern void
Ns_Poly1305Authenticate( /* Tcl Manual suggests this style */
char auth[16],
char kr[32],
char nonce[16],
char *message,
unsigned int messageLen); /* each arg on separate line */
static void /* good or
bad */
ConfigSet(char *section, char *key, char *value)
{
Ns_Set *set;
if (section != NULL
key != NULL /* indent 8 on continuation,
start */
( (set = Ns_ConfigGetSection(section)) != NULL) ) {
Ns_SetPut(set, key, value); /* back to 4 indents */
Ns_Log(Debug, ConfigSet: Added %s = %s to %s, key, value,
section);
} else {
Ns_Log(Debug, ConfigSet: Unable to add key %s to section %s,
key, section);
}
return;
}
Comment code examples:
The AOLserver style guide says to use where the code actually
uses -
Below, Ns_ConfigGetSections:
1. follows one blank line after --- line which extends to column 79
2. is indented one space
3. followed by space -- ' --'
3. is followed by a blank line
Description:
1. indented 5 spaces beyond the previous indent, so 6 spaces from the
*
2. continuations are lined up???
3. followed by a blank line.
Overall:
No trailing whitespace
Should text end in a period, or no punctuation?
/*
*--
*
* Ns_ConfigGetSections --
*
* Return a malloc'ed, NULL-terminated array of sets, each
* corresponding to a config section
*
* Results:
* An array of sets
*
* Side effects:
* The result is malloc'ed memory
*
*--
*/
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Thursday 24 February 2005 12:55, Nathan Folkman wrote:
The rule of thumb that I always followed
was to code in the same style as Jim, who himself followed the Tcl
Style Guide.
int
NsTclNHttpObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
So this doesn't follow either the Tcl Eng Manual, or the AOLserver guide.
Continuation line isn't indented either 8 chars (Tcl) or to the first arg
(AOLserver), although maybe the line above was folded by the email process.
Variable declarations are not lined up as suggested in either reference (could
be due to a tab in the original):
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
intmyExtraVar;
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
Yeah, that's pretty much the point I was hoping to illustrate... ;-) We
need to update the AOLserver Style Guide so that it accurately
documents the actual style guidelines that are used throughout the
code. Until that happens, it's a good idea to try and follow Jim's
style where possible, as that is the style to which most of the code is
written.
On Feb 24, 2005, at 4:10 PM, Tom Jackson wrote:
On Thursday 24 February 2005 12:55, Nathan Folkman wrote:
The rule of thumb that I always followed
was to code in the same style as Jim, who himself followed the Tcl
Style Guide.
int
NsTclNHttpObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
So this doesn't follow either the Tcl Eng Manual, or the AOLserver
guide.
Continuation line isn't indented either 8 chars (Tcl) or to the first
arg
(AOLserver), although maybe the line above was folded by the email
process.
Variable declarations are not lined up as suggested in either
reference (could
be due to a tab in the original):
NsInterp *itPtr = arg;
Http *httpPtr;
Tcl_HashEntry *hPtr;
intmyExtraVar;
tom jackson
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to
[EMAIL PROTECTED] with the
body of SIGNOFF AOLSERVER in the email message. You can leave the
Subject: field of your email blank.
--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to [EMAIL PROTECTED]
with the
body of SIGNOFF AOLSERVER in the email message. You can leave the Subject:
field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
I have submitted a feature enhancement request for this available at: https://sourceforge.net/tracker/?func=detailatid=353152aid=1124272group_id=3152 If anyone has a problem with me committing these changes to the current CVS, please speak up. I'll wait a week then commit my changes, unless requested not to. The patch will not change any existing functionality. During testing of this the config.c code I noticed a few things which might be addressed in the future, or maybe just documented somehow with respect to the interpretation of values in the config params. 1. any integer is interpreted as boolean. 2. large values derived from tcl expr which result in values in scientific notation (9.12345e5) end up with a value the whole part for integer conversion. 3. values of integer larger than the max size supported are given the max value for that integer type (int or int64). 4. string values which begin with one or more digits can be interpreted as integers. They are stored as the integer up to the first non-digit in the string. I have written a C module 'config-test' which provides a tcl api allowing you to test any config section. In cases where the stored (in C struct) differs from the string, the difference is noted (with the obvious exception of boolean). The tcl api allows you to test one param or one section at a time. The C module is not part of the patch. One deficiency of the new API is the inability to document the use of NULL values as a default. One instance is the nslog format string. tom jackson On Monday 14 February 2005 12:13, Tom Jackson wrote: I have added a few new C API's for setting (just adding, not replacing) config params during startup. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On 2005.02.23, Tom Jackson [EMAIL PROTECTED] wrote: I have submitted a feature enhancement request for this available at: https://sourceforge.net/tracker/?func=detailatid=353152aid=1124272group_id=3152 If anyone has a problem with me committing these changes to the current CVS, please speak up. I'll wait a week then commit my changes, unless requested not to. I don't have a problem with these changes being committed since you say: The patch will not change any existing functionality. However, I have one small nit to pick: many changes in the patch are simply formatting-related (converting hard tabs to spaces) which I agree should be done, but could you separate that into its own patch? It's hard to see what your actual proposed changes are amongst all the noise of changes which are strictly reformatting of existing code. Since you say your change doesn't change any existing functionality, then the next logical step is that code should be updated to use the new Ns_ConfigSetValue API to record all config settings, correct? We want to ensure that Ns_ConfigSetValue when called after the config interp is done evaluating the config.tcl and initializing all the modules, but before the server actually starts up that we set a boolean to indicate from this point forward, no more changes to the config so that Ns_ConfigSetValue will return an error. Because of this, I'm not too happy with Ns_ConfigSetValue returning a (char *) but would rather it return (int) for NS_OK/NS_ERROR. One deficiency of the new API is the inability to document the use of NULL values as a default. One instance is the nslog format string. Huh? Why not: Ns_ConfigSetValue(ns/parameters, key, NULL); Then, you can either test for NULL in Tcl with [ns_set isnull setId key] or in C with value == NULL tests. Or, do you mean something else and I'm misunderstanding you? -- 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) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
On Wednesday 23 February 2005 09:54, Dossy Shiobara wrote: However, I have one small nit to pick: many changes in the patch are simply formatting-related (converting hard tabs to spaces) which I agree should be done, but could you separate that into its own patch? It's hard to see what your actual proposed changes are amongst all the noise of changes which are strictly reformatting of existing code. I guess the best way to do this is to checkout a fresh copy of config.c and first apply any whitespace formatting changes. After this is done, I can commit the other changes, once the below issues are resolved. Since you say your change doesn't change any existing functionality, then the next logical step is that code should be updated to use the new Ns_ConfigSetValue API to record all config settings, correct? Yes, I've already prepared the nslog module, which tests everything except int64. We want to ensure that Ns_ConfigSetValue when called after the config interp is done evaluating the config.tcl and initializing all the modules, but before the server actually starts up that we set a boolean to indicate from this point forward, no more changes to the config so that Ns_ConfigSetValue will return an error. Is there any example code to show where this might be done? Otherwise I'll look around. This would break the config-test module, which isn't an issue here, but might suggest a solution. Because of this, I'm not too happy with Ns_ConfigSetValue returning a (char *) but would rather it return (int) for NS_OK/NS_ERROR. Three reasons I chose this method. First, it keeps each Set function identical to the Get function. Second, you don't need to declare another int and check the return. Third Ns_ConfigSetValue never fails, if it did, the purpose of having no effect on the configuration process beyond documentation would be lost. If a config section is missing, an Ns_Log Debug is issued during ConfigSet. However, after this step, Ns_ConfigSetValue just returns the value passed in. One deficiency of the new API is the inability to document the use of NULL values as a default. One instance is the nslog format string. Huh? Why not: Ns_ConfigSetValue(ns/parameters, key, NULL); Then, you can either test for NULL in Tcl with [ns_set isnull setId key] or in C with value == NULL tests. Or, do you mean something else and I'm misunderstanding you? Actually all I meant was that I didn't test it. It appears that it would work as you suggest. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
Re: [AOLSERVER] New Config API's which document default values.
just a couple of suggestions, from a very quick first look (it is hard too sifting through the TAB changes, as Dossy said): 1) Tcl already has Tcl_GetBoolean...this could be used instead of the boolean...I believe...no big deal though 2) This might be a good time to start moving away from Tcl_AppendResult...just a thought. This is for AS in general. Note: there is also a Tcl_WrongNumArgs function that probably could be used in a few places too. 3) similar to 2), it might be a good time to start moving to Obj based commands. --- Tom Jackson [EMAIL PROTECTED] wrote: I have added a few new C API's for setting (just adding, not replacing) config params during startup. The new API's are named after the current Get API's, for instance: Ns_ConfigGetValue Ns_ConfigSetValue Due to the amount of common code which would have been repeated in the new API's, I factored out this code into private procedures. I also compared the resulting code with the Tcl C API standards contained in http://www.tcl.tk/doc/engManual.pdf. There were many deviations from this standard in the original file, so I made any changes that I noticed, the result is that the file is mostly new. If there are any style changes which need to be made, please point them out on this list, so I can make the changes. I included a sample use of the new APIs in nslog.c. The diff, and changed files are located at: http://rmadilo.com/m2/config-changes/ If this is something that should be included in future versions of AOLserver, I need to know which cvs version to do a diff on, and how. If there are further suggestions, please note them on this list. For one, it might be nice to have a ParamDelete procedure to hide things like password params after they have been read. Note that all config sections are returned from every virtual server with the current tcl api commands. The new APIs are only useful for adding params for values which are not in the config file. The section Ns_Set is appended to only if the section exists, but in every case, the new APIs return the value that is needed to set the default. I haven't investigated the case where a null (missing) default is used later to determine configuration (such as rollFmt), for now these will remain undocumented, but I think I can add a check for a null value to get it to work. Untested is Int64. I'm writing a C module to run tests over the APIs. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank. = --brett -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
[AOLSERVER] New Config API's which document default values.
I have added a few new C API's for setting (just adding, not replacing) config params during startup. The new API's are named after the current Get API's, for instance: Ns_ConfigGetValue Ns_ConfigSetValue Due to the amount of common code which would have been repeated in the new API's, I factored out this code into private procedures. I also compared the resulting code with the Tcl C API standards contained in http://www.tcl.tk/doc/engManual.pdf. There were many deviations from this standard in the original file, so I made any changes that I noticed, the result is that the file is mostly new. If there are any style changes which need to be made, please point them out on this list, so I can make the changes. I included a sample use of the new APIs in nslog.c. The diff, and changed files are located at: http://rmadilo.com/m2/config-changes/ If this is something that should be included in future versions of AOLserver, I need to know which cvs version to do a diff on, and how. If there are further suggestions, please note them on this list. For one, it might be nice to have a ParamDelete procedure to hide things like password params after they have been read. Note that all config sections are returned from every virtual server with the current tcl api commands. The new APIs are only useful for adding params for values which are not in the config file. The section Ns_Set is appended to only if the section exists, but in every case, the new APIs return the value that is needed to set the default. I haven't investigated the case where a null (missing) default is used later to determine configuration (such as rollFmt), for now these will remain undocumented, but I think I can add a check for a null value to get it to work. Untested is Int64. I'm writing a C module to run tests over the APIs. tom jackson -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to [EMAIL PROTECTED] with the body of SIGNOFF AOLSERVER in the email message. You can leave the Subject: field of your email blank.
