naviserver-devel — Developer discussion

Re: [naviserver-devel] mysql?

[Zoran V. <zv...@ar...>]

Am 05.04.2007 um 16:09 schrieb Vlad Seryakov:

> We are using it, the version from AS or Dossy site i do not remember,
> there were some changes i made, i always wanted to put into our CVS.
> Not sure i can do it now, so Zoran you may find any version and  
> import it

OK. So there is one working-module for mysql connection.
If I import the code, would you apply your changes?

Re: [naviserver-devel] mysql?

[Vlad S. <vl...@cr...>]

We are using it, the version from AS or Dossy site i do not remember, 
there were some changes i made, i always wanted to put into our CVS.
Not sure i can do it now, so Zoran you may find any version and import it

Zoran Vasiljevic wrote:
> Hi!
> 
> We never had any need for DB interface in the server
> since some years, but now we might need to get this
> working with mysql database. I see that we do not have
> this module in our cvs.
> 
> Question: anybody has some experience with mysql and
> naviserver?
> 
> Cheers
> Zoran
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

[naviserver-devel] mysql?

[Zoran V. <zv...@ar...>]

Hi!

We never had any need for DB interface in the server
since some years, but now we might need to get this
working with mysql database. I see that we do not have
this module in our cvs.

Question: anybody has some experience with mysql and
naviserver?

Cheers
Zoran

[naviserver-devel] CFP: OpenACS and .LRN Spring Conference, Vienna 2007

[Gustaf N. <ne...@wu...>]

Hi everybody, 

the following conference might find the interest of
some people of the naviserver community.

best regards
-gustaf neumann
=================================================


Call for Papers:

   OpenACS and .LRN Spring Conference, Vienna 2007 -
       International Conference and Workshops on
          Community Based Environments

        http://oacs-dotlrn-conf2007.wu-wien.ac.at/
              April 25 - 28,
   University of Economics and Business Administration
             Vienna, Austria

1 Introduction

The OpenACS and .LRN Spring Conference for 2007 is the 5th of a series
which focuses on the development of community based web sites and on
community based e-learning environments. The confernence is the user
and developer conference of the Open-Source Frameworks OpenACS and
DotLRN. Presentations and Submissions are not limited to these
frameworks.

The conference offers multiple activities for users and developers of
the framework as well as for people interested in the mentioned topics
in general. The program will contain tutorials and BOFs, two days of
presentations and workshops and the traditional bug bashing day.
While part of the presentations will be use-cases and research
developments, the workshops will focus on short-presentation of
approaches, discussions and some outcomes in form of a consolidated
opinion, state-of the art report or a proposal, which will be
presented in a common session.


2 Topics

 * Agile Content Development
 * Web 2.0 for E-Learning Environments and/or DotLRN, OpenACS
 * Testing-Environment and Testing Approaches
 * Methodologies for online teaching
 * Learning design (IMS LD, LAMS)
 * Specialized Learning Components
 * Social Software
 * Educational standards support
 * Usability for online learning
 * Accessible services for learners
 * Experiences and Best Practices
 * Remoting Frameworks for  OpenACS
 * Extending Object Orientation in OpenACS for better reuse and 
configuration
 * Architectural Developments


3 Participation and Important Dates
3.1 Participation

The conference and workshops addresses practitioners, developers and
researchers in the topics mentioned above. Participants intending to
present their work should send a 2 page abstract to
con...@do.... Every presentation at the conference will take
about 20 minutes, followed by 10 minutes discussions. The
presentations are reviewed by the program committee. The presentations
and papers will be published electronically on the conference web
site.

In addition to the presentation style conference program, we plan
Thematic Workshops to foster discussions on the workshop topics. These
workshops do not overlap with other workshops or
presentations. Ideally, every workshop will contain 3 or 4 short
position presentations (max 5 slides) that should fuel the discussion
in the workshop. The outcome of each workshop should be a document
summarizing the results, which might range from a consolidated set of
opinions to a road map paper inspiring the development of the
framework.

In the pre-confernce program, we plan Tutorials and "Birds Of a
Feather" (flocking together) sessions, which are informal group
discussions where participants wish to discuss certain developments or
problems.

We would like to encourage people interested to participate to fill
out the pre-registration form on
http://oacs-dotlrn-conf2007.wu-wien.ac.at/ . Participants intending to
present a short position statement should note their intensions and
topic in the pre-registration form (including BoF topics).


3.2 Important Dates

 * April 2th, 2007:  Submissions of Abstracts  (2 pages, mail to 
con...@do...)
 * April 9th, 2007:  Notification and Final Program
 * April 25th, 2007: Pre-Conference Program: Tutorials and BOFs
 * April 26th and April 27th: Main Confernce
 * April 28th, 2007: Developers Day

3.3 Program Committee

 * Carl Blesius, MGH Lab of Computer Science, U.S.A.
 * Alfred Essa, Deputy CIO at Minnesota State Colleges and Universities, 
U.S.A.
 * Gustaf Neumann, University of Economics and Business Administration, 
Vienna, Austria.
 * Carlos Delgado Kloos, UC3M, Spain.
 * Jesús G. Boticario, UNED, Spain.
 * Emmanuelle Raffenne, UNED, Spain.
 * Olga C. Santos, aDeNu Research Group, UNED, Spain.
 * Rocael Hernández, Galileo University, Guatemala.

3.3 Organization Committee

 * Valerie Bajc (WUW)
 * Bernd Simon (WUW)
 * Stefan Sobernig (WUW)

For more details, please visit the conference website at
http://oacs-dotlrn-conf2007.wu-wien.ac.at/

Re: [naviserver-devel] [naviserver-commits] naviserver/m4 tcl.m4, 1.6, 1.7

[Zoran V. <zv...@ar...>]

Am 24.03.2007 um 12:12 schrieb Stephen Deasey:

>
> You need to push this change upstream or it will end up getting  
> lost...

I know! I haven't found a better way to handle this yet.
Mac OSX 10.3 is now becoming pretty "obsolete" because
of the new 10.5 release arround the corner. It is still
there (in tcl.m4) because quite a few people still use
10.3.

I guess better way would be to define MACOSX_DEPLOYMENT_TARGET
instead of patching this file. But at the moment I just have
no time to fiddle with that. Lets put that under the carpet
for now until I think of a better solution.

Cheers
Zoran

Re: [naviserver-devel] [naviserver-commits] naviserver/m4 tcl.m4, 1.6, 1.7

[Stephen D. <sd...@gm...>]

On 3/24/07, Zoran Vasiljevic <vas...@us...> wrote:
> Update of /cvsroot/naviserver/naviserver/m4
> In directory sc8-pr-cvs7.sourceforge.net:/tmp/cvs-serv32251/m4
>
> Modified Files:
>         tcl.m4
> Log Message:
> Scrapped MACOSX_DEPLOYMENT_TARGET as this is not needed for 10.4=C3+ Mac =
OSX.


We pull this file down from Tcl CVS to get the latest changes:

  http://tcl.cvs.sourceforge.net/tcl/tclconfig/

You need to push this change upstream or it will end up getting lost...

Re: [naviserver-devel] API Changes

[Vlad S. <vl...@cr...>]

Sorry, will do

Zoran Vasiljevic wrote:
> Hi!
> 
> I would like to draw your attentipn to one important
> point: API chages, if any, should be if possible
> commented out *clearly* in ChangeLog file.
> 
> I just stumbled arround (excerpt from "cvs log return.c"):
> 
> revision 1.28
> date: 2006/11/29 05:03:07;  author: seryakov;  state: Exp;  lines: +6 -6
> More updates to support huge files, use Tcl_WideInt whenever send  
> bytes are specified
> 
> We use one of those functions that got updated and it took
> me some time to figure out what was wrong with loading of
> our dynamic pages. Aparently, due to the API change, the
> passed argument went wrong into the routine and an invalid
> byte-count of the result was reported, making the browser
> to wait and timeout (connection was keep-alive).
> 
> Please take time to correctly update the ChangeLog and
> put clearly (emphasyse sufficiently) when an API routine
> got changed from the calling level. Otherwise others are
> left in dark and confronted with tedious and costly
> debugging in the (relatively complex) code.
> 
> Cheers
> zoran
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 

[naviserver-devel] API Changes

[Zoran V. <zv...@ar...>]

Hi!

I would like to draw your attentipn to one important
point: API chages, if any, should be if possible
commented out *clearly* in ChangeLog file.

I just stumbled arround (excerpt from "cvs log return.c"):

revision 1.28
date: 2006/11/29 05:03:07;  author: seryakov;  state: Exp;  lines: +6 -6
More updates to support huge files, use Tcl_WideInt whenever send  
bytes are specified

We use one of those functions that got updated and it took
me some time to figure out what was wrong with loading of
our dynamic pages. Aparently, due to the API change, the
passed argument went wrong into the routine and an invalid
byte-count of the result was reported, making the browser
to wait and timeout (connection was keep-alive).

Please take time to correctly update the ChangeLog and
put clearly (emphasyse sufficiently) when an API routine
got changed from the calling level. Otherwise others are
left in dark and confronted with tedious and costly
debugging in the (relatively complex) code.

Cheers
zoran

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Andrew P. <at...@pi...>]

On Wed, Mar 07, 2007 at 11:07:54PM +0000, Stephen Deasey wrote:

> Re the laz-loading, the difference seems to be: our tracing lazy
> loader works on a per-proc (or other Tcl object) level, and it tries
> to be transparent to the user; whereas the Tcl pkgIndex mechanism
> works at the file level, and you explicitly hook into this (although
> you can automate it).
> 
> I wasn't really interested in the laziness of the loading, but the

The somtimes large memory savings of Zoran's lazy loader are
attractive if it (or some other approach) can be made robust enough to
satisfy you guys.

Loading many thousands of identical Tcl procs repeatedly into dozens
of threads never did seem like an ideal approach...  Being able to
create and redefine procs on the fly (possibly only in one or some
threads) is good, but 95% of the time those procs are all 100%
identical across all threads and never change during the runtime of
the AOLserver process.  (But then you know all that, and the current
memory wasting method has worked for many years, even when computers
had much less memory.)

I suppose that eliminating all the redundant memory usage could/should
be considered an separate endeavor, especially since Zoran seems to be
unhappy with the complexity of his current ttrace lazy loader.  Down
the road, perhaps somebody will solve the memory wastage issue for
multi-threaded Tcl in general.

> Ultimately, I guess we could turn the server inside-out. /usr/sbin/nsd
> would become a script which package requires nsd. Just need to turn
> the stuff in nsd/nsmain.c etc. into commands...

That would be very cool if it's robust and of similar performance to
the current architecture.  For one thing, it would be very nice to be
able to easily use all of AOLserver's libraries directly from tclsh.

Btw, I think Jim Davidson made several, "we'd like to move in that
direction" type comments on the AOLserver list years ago.

I wonder if you'd hit any sticky bits with special C code stuff the
AOLserver process currently does on startup, e.g. opening privileged
sockets as root, then doing setuid and setgid.  Probably you could
make all that work somehow or other, though.

I also idly wonder if, down the road, some other group might want to
take your newly refactored libraries of Naviserver C code and "package
require" them from some entirely different scripting language (say
Lua, Scheme, or Javascript).  I guess not, the Naviserver C code is
probably too tightly integrated with Tcl and the Tcl C libraries to
make that particularly attractive to any non-Tcl developers?

-- 
Andrew Piskorski <at...@pi...>
http://www.piskorski.com/

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Stephen D. <sd...@gm...>]

On 3/8/07, Vlad Seryakov <vl...@cr...> wrote:
> Very nice, i wonder how it will work for legacy code
>


We should figure out exactly what we need to support. Not just to be
backward compatible, but to make sure this works for everyone.

Shout out if you have anything particular in mind!

As far as binary naviserver modules go, the current entry point is:

int
Ns_ModuleInit(CONST char *server, CONST char *module)
{
    ...

Tcl binary extensions however, look like so:

int
Foo_Init(Tcl_Interp *interp)
{
    ...


Initialisation wil be a two part process. Foo_Init will be called once
for each interp. The first time it should initialise mutexes etc. It
should also register some kind of Tcl configuration command, e.g.
foo_ctl.

Then in the module pkgIndex.tcl, which will be loaded once for each
interp, a config callback should be registered with NaviServer, e.g.
_foo_config. _foo_config will be called once for each instance of the
module for each virtual server during the pre-startup config phase.

I guess it doesn't matter that it's registered for each new thread --
it's just an entry in a hash table...

_foo_config will examine the config file and call foo_ctrl as needed,
which may just resolve to a call to the old Ns_ModuleInit() routine
under the covers.

So there are a couple of levels of backwards compatibility. It could
be that a module provides both Ns_ModuleInit() and Foo_Init()
routines, so that it can be loaded by old and new servers.

We could also say that, if the string that appears in the modules
section of the config file resolves to a file on disk then we try to
load it the old way, otherwise we treat it as the name of a package
and try to package require it.


We could also provide the old code that does the crazy path walking to
load .tcl files, and possibly even enable it if the config file still
defines a 'sharedlibrary' or 'privatelibrary'. But my impression is
that people aren't using this. Or at least, they're dropping a single
file into the private library and using that to bootstrap their own
startup process.

In the glorious future, you would add /srv/example.com to the Tcl
auto_path variable (for example, by setting TCLLIBPATH), and drop a
pkgIndex.tcl file into /srv/example.com/mytcl. From there, you can
kickstart your old .tcl sourcing procedure, or you can just add more
modules to that directory.

  ns_section "ns/server/serverx/modules"
  ns_param sock1     nssock
  ns_param sock2     nssock
  ns_param mytcl     mytcl
  ns_param myothertcl myothertcl

/usr/lib/naviserver/nssock/nssock.so
/usr/lib/naviserver/nssock/pkgIndex.tcl
...

/srv/example.com/mytcl
/srv/example.com/mytcl/pkgIndex.tcl
/srv/example.com/mytcl/mytcl.tcl
...


I think the procedure for creating new threads in the right state
would be to replay the series of package require commands, as needed
by the entries in the modules section. Each module that that brings in
can have it's own package require dependencies (something we don't
have right now).

If anything fancier than that is needed then a module can register
ns_ictl traces in it's config callback.


I'll find out if it's a completely stupid idea when I try implementing it...

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Vlad S. <vl...@cr...>]

Very nice, i wonder how it will work for legacy code

Stephen Deasey wrote:
> On 3/6/07, Zoran Vasiljevic <zv...@ar...> wrote:
>>
>> Am 06.03.2007 um 15:35 schrieb Stephen Deasey:
>>
>> >
>> > How does the lazy loader compare to Tcl's -lazy switch to pkg_mkIndex?
>> >
>> >   http://www.tcl.tk/man/tcl8.4/TclCmd/pkgMkIndex.htm
>>
>> I have absolutely no idea. Our lazy-loader depends on the command trace
>> utility. I yet have to see what pkgindex is using.
>>
>> Overall, I still think that using ns_ictl is the real solution to interp
>> init problem. Perhaps not the fastest but most definietly the most
>> flexible
>> and universal one.
>>
>> Simply, we'd collect list of all files we'd need to source and
>> just register callback's to run them at interp init. This is trivially
>> implemented and would IMHO run more/less at the same speed but be more
>> generic and foolproof.
>>
>> It would not save us memory as the lazy loader does, but it would
>> be more generic.
>>
> 
> 
> OK. A single, simple way for modules to initialise themselves.
> 
> Re the laz-loading, the difference seems to be: our tracing lazy
> loader works on a per-proc (or other Tcl object) level, and it tries
> to be transparent to the user; whereas the Tcl pkgIndex mechanism
> works at the file level, and you explicitly hook into this (although
> you can automate it).
> 
> I wasn't really interested in the laziness of the loading, but the
> searching and packaging and other funky stuff you have to be aware of
> just to get some code loaded.
> 
> So, how about we make NaviServer modules a super set of Tcl packages?
> The only difference I think we need is that a naviserver module (a
> package) should register a config callback when it is 'package
> require'd, which will get called once for each time the module/package
> name appears in the ns/server/serverx/modules section.
> 
> Loading modules then becomes a 'package require modulex' (which will
> be cached by Tcl) and then a series of calls to the registered module
> config callback, i.e. if you load the nssock module twice, sock1 and
> sock2 to listen on different ports.
> 
> What do y'all think, NaviServer modules == Tcl packages..?
> 
> I've been experimenting a little with this. Attached is what a
> pkgIndex.tcl file might look like for the nsd package.
> 
> Ultimately, I guess we could turn the server inside-out. /usr/sbin/nsd
> would become a script which package requires nsd. Just need to turn
> the stuff in nsd/nsmain.c etc. into commands...
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel


-- 
Vlad Seryakov
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Stephen D. <sd...@gm...>]

On 3/6/07, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 06.03.2007 um 15:35 schrieb Stephen Deasey:
>
> >
> > How does the lazy loader compare to Tcl's -lazy switch to pkg_mkIndex?
> >
> >   http://www.tcl.tk/man/tcl8.4/TclCmd/pkgMkIndex.htm
>
> I have absolutely no idea. Our lazy-loader depends on the command trace
> utility. I yet have to see what pkgindex is using.
>
> Overall, I still think that using ns_ictl is the real solution to interp
> init problem. Perhaps not the fastest but most definietly the most
> flexible
> and universal one.
>
> Simply, we'd collect list of all files we'd need to source and
> just register callback's to run them at interp init. This is trivially
> implemented and would IMHO run more/less at the same speed but be more
> generic and foolproof.
>
> It would not save us memory as the lazy loader does, but it would
> be more generic.
>


OK. A single, simple way for modules to initialise themselves.

Re the laz-loading, the difference seems to be: our tracing lazy
loader works on a per-proc (or other Tcl object) level, and it tries
to be transparent to the user; whereas the Tcl pkgIndex mechanism
works at the file level, and you explicitly hook into this (although
you can automate it).

I wasn't really interested in the laziness of the loading, but the
searching and packaging and other funky stuff you have to be aware of
just to get some code loaded.

So, how about we make NaviServer modules a super set of Tcl packages?
The only difference I think we need is that a naviserver module (a
package) should register a config callback when it is 'package
require'd, which will get called once for each time the module/package
name appears in the ns/server/serverx/modules section.

Loading modules then becomes a 'package require modulex' (which will
be cached by Tcl) and then a series of calls to the registered module
config callback, i.e. if you load the nssock module twice, sock1 and
sock2 to listen on different ports.

What do y'all think, NaviServer modules == Tcl packages..?

I've been experimenting a little with this. Attached is what a
pkgIndex.tcl file might look like for the nsd package.

Ultimately, I guess we could turn the server inside-out. /usr/sbin/nsd
would become a script which package requires nsd. Just need to turn
the stuff in nsd/nsmain.c etc. into commands...

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Zoran V. <zv...@ar...>]

Am 06.03.2007 um 15:35 schrieb Stephen Deasey:

>
> How does the lazy loader compare to Tcl's -lazy switch to pkg_mkIndex?
>
>   http://www.tcl.tk/man/tcl8.4/TclCmd/pkgMkIndex.htm

I have absolutely no idea. Our lazy-loader depends on the command trace
utility. I yet have to see what pkgindex is using.

Overall, I still think that using ns_ictl is the real solution to interp
init problem. Perhaps not the fastest but most definietly the most  
flexible
and universal one.

Simply, we'd collect list of all files we'd need to source and
just register callback's to run them at interp init. This is trivially
implemented and would IMHO run more/less at the same speed but be more
generic and foolproof.

It would not save us memory as the lazy loader does, but it would
be more generic.

Cheers
Zoran

Re: [naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Stephen D. <sd...@gm...>]

On 2/20/07, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 16.02.2007 um 18:05 schrieb Bernd Eidenschink:
>
> > Hm, looks like with the 4.99.1 Sourceforge release there is no
> > problem loading
> > xotcl files and working with it.
> >
> > The same seems to fail, no matter what lazyloader setting is used,
> > with the
> > current bin/init.tcl and/or nstrace.tcl.
>
> I have looked into that part... (LONG!)
>
> The trouble is the way how NS or AS are initialized.
>
> Both (yes, we do still use that old arcane init stuff) are doing pretty
> much complicated and error-prone stuff to get all the Tcl files sourced
> and all the modules loaded.
>
> The way how it works is (roughly):
>
>    o. all tcl files are sourced
>    o. introspective script is run to gather the state of the interp
>    o. the script applied to every new Tcl interp
>
> This is of course sub-optimal for any complex interp initialization.
> Tcl (still) does not offer a capability to replicate a loaded interp.
> There are several attempts to do so, but most of them are/were limited
> in scope. Over the lifetime of AS project (including our own NS fork)
> there have been several attempts to address this problem but no one was
> really successful.
>
> As of V4, there is a vehicle to do this right and that is: ns_ictl
> (stands for "interpreter control"). You can use this to register
> callbacks
> which are to be executed at interpreter creation, deletion, etc. This is
> the most flexible way how one could/should tangle that (complex)
> problem.
>
> Therefore I suggest we take complete different way for hanling XOTcl at
> the interp start than we do now. Over the time we can rewrite the
> existing
> code to use ns_ictl only, w/o fiddling with that home-brewn script
> synthesis.
> This will simplify the things greatly.
>
> The idea is to issue something like
>
>      ns_ictl oninit {package require XOTcl}
>      foreach file $xotcl_files {
>          ns_ictl oninit {source $file)
>      }
>
> during server startup. The "xotcl_files" would hold list of
> all *.xotcl files found in various places (in [ns_library shared]
> and/or [ns_library private]).
>
> I have written a trivial XOTcl loader (attached). Please note that
> the nstrace.tcl (attached) is slightly modified to *exclude* processing
> of xotcl namespace (I will have to check this into CVS but for the
> meantime, please just put both files under /usr/local/ns/tcl or under
> /usr/local/ns/modules/tcl directory).
>
> How it works now is:
>
>      xotcl.tcl issues ns_itcl oninit {package req XOTcl}
>      then it collects all shared/private *.xotcl files
>      for every file it does: ns_ictl "source $file"
>
> This is MUCH simpler, works always and everybody can understand it.
> It might be that this will introduce a small speed penalty when
> creating an interpreter, but most modern computers are so fast that
> you will not notice that in real life.
>
> A word on lazy loading... this is MUCH more complicated stuff as it
> requires special support from XOTcl in addition to the nstrace.tcl
> code. Fortunately, there is a way to do that and we are using this
> in our product. Unfortunately, I have no time at this moment to get
> it done "right" for everybody to use. So, for the time being please
> refrain from using lazy-loading of XOTcl.


How does the lazy loader compare to Tcl's -lazy switch to pkg_mkIndex?

  http://www.tcl.tk/man/tcl8.4/TclCmd/pkgMkIndex.htm

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Vlad S. <vl...@cr...>]

> 
> The log will tell you which port it's listening on.
> 
> No need for user/pass when telneting in (not sure this is the best
> change in the world, Vald...)

This will work for localhost only and for new developers which uses 
Linux for personal use makes less headaches. Once ready for production, 
means developer sold on Naviserver, will secure it if need nscp there.

-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] [naviserver-commits] naviserver/nsd return.c: switch from Ns_ConnPrintfHeders

[Vlad S. <vl...@cr...>]

The reason to use Ns_ConnUpdateHeaders which replaces the header, before 
it just added

Stephen Deasey wrote:
> On 2/19/07, Vlad Seryakov <ser...@us...> wrote:
>> RCS file: /cvsroot/naviserver/naviserver/nsd/return.c,v
>> retrieving revision 1.29
>> retrieving revision 1.30
>> diff -C2 -d -r1.29 -r1.30
>> *** return.c    24 Dec 2006 02:38:10 -0000      1.29
>> --- return.c    19 Feb 2007 20:17:40 -0000      1.30
>> ***************
>> *** 567,573 ****
>>   {
>>       Conn *connPtr = (Conn *) conn;
>>
>>       connPtr->responseLength = length;
>> !     Ns_ConnPrintfHeaders(conn, "Content-Length", "%llu", length);
>>   }
>>
>> --- 567,575 ----
>>   {
>>       Conn *connPtr = (Conn *) conn;
>> +     char strlength[16];
>>
>> +     sprintf(strlength, "%llu", length);
>>       connPtr->responseLength = length;
>> !     Ns_ConnUpdateHeaders(conn, "Content-Length", strlength);
>>   }
> 
> 
> Why this change?
> 
> Did you find a bug?
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
> 


-- 
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/

Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Stephen D. <sd...@gm...>]

On 2/19/07, Michael A. Cleverly <cle...@gm...> wrote:
> On 2/10/07, Stephen Deasey <sd...@gm...> wrote:
> > You could try compiling the kernel with support for RTHREADS enabled.
> >
> > Then compile the rthreads library in /usr/src/lib/librthread
> >
> > Then link against it for 1-1 user-kernel threads.
>
> Rather than recompiling OpenBSD I decided to start fresh and installed
> Debian/sparc instead.


The right decision... :-)


> The control port does not ever respond but I don't really need
> it for the project I'm working on so I just don't load nscp.so at the
> moment.  Sometime I might go back and poke & try and figure out why...


Works for me on intel/linux.  Maybe it's a sparc/64bit bug?


If you're interested, add:

  ns_param nsproxy [ns_config "test" home]/../nscp/nscp.so

to the tests/test.nscfg file.

  $ make runtest

The log will tell you which port it's listening on.

No need for user/pass when telneting in (not sure this is the best
change in the world, Vald...)

Re: [naviserver-devel] [naviserver-commits] naviserver/nsd return.c: switch from Ns_ConnPrintfHeders

[Stephen D. <sd...@gm...>]

On 2/19/07, Vlad Seryakov <ser...@us...> wrote:
>
> RCS file: /cvsroot/naviserver/naviserver/nsd/return.c,v
> retrieving revision 1.29
> retrieving revision 1.30
> diff -C2 -d -r1.29 -r1.30
> *** return.c    24 Dec 2006 02:38:10 -0000      1.29
> --- return.c    19 Feb 2007 20:17:40 -0000      1.30
> ***************
> *** 567,573 ****
>   {
>       Conn *connPtr = (Conn *) conn;
>
>       connPtr->responseLength = length;
> !     Ns_ConnPrintfHeaders(conn, "Content-Length", "%llu", length);
>   }
>
> --- 567,575 ----
>   {
>       Conn *connPtr = (Conn *) conn;
> +     char strlength[16];
>
> +     sprintf(strlength, "%llu", length);
>       connPtr->responseLength = length;
> !     Ns_ConnUpdateHeaders(conn, "Content-Length", strlength);
>   }


Why this change?

Did you find a bug?

Re: [naviserver-devel] sed -r

[Stephen D. <sd...@gm...>]

On 2/20/07, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 20.02.2007 um 16:54 schrieb Stephen Deasey:
>
> > What's the old skool way of doing this?
>
> TCL_LIB="tcl$TCL_VERSION$TCL_DBGX"
>


You're hired.  :-)

Re: [naviserver-devel] sed -r

[Bernd E. <eid...@we...>]

Am Dienstag, 20. Februar 2007 17:01 schrieb Zoran Vasiljevic:
> Am 20.02.2007 um 16:54 schrieb Stephen Deasey:
> > What's the old skool way of doing this?
>
> TCL_LIB="tcl$TCL_VERSION$TCL_DBGX"

that's not fair! that's too easy! :-)

Re: [naviserver-devel] UIO_MAXIOV

[Zoran V. <zv...@ar...>]

Am 20.02.2007 um 17:04 schrieb Stephen Deasey:

> If BSD etc. doesn't, we'll have to make sure we're handling that error
> correctly.

For the time being, I added this one into the nsd/nsd.h

/*
  * This baroque pre-processor fiddling should be eventually
  * replaced with a decent configure option and/or logic.
  */

#ifndef UIO_MAXIOV
   #if defined(__FreeBSD__) || defined(__APPLE__) || defined(__NetBSD__)
     #define UIO_MAXIOV 1024
   #elif defined(__sun)
     #ifndef IOV_MAX
       #define UIO_MAXIOV 16
     #else
       #define UIO_MAXIOV IOV_MAX
     #endif
   #elif defined(IOV_MAX)
       #define UIO_MAXIOV IOV_MAX
   #else
     #error "neither UIO_MAXIOV nor IOV_MAX are defined"
   #endif
#endif

Re: [naviserver-devel] UIO_MAXIOV

[Stephen D. <sd...@gm...>]

On 2/20/07, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 20.02.2007 um 15:23 schrieb Zoran Vasiljevic:
>
> > Hi!
> >
> > I haven't updated the sources for quite a long time!
> > We don't compile on anything else but Linux :-(
> >
> > Anyways, the UIO_MAXIOV seems to be defined only for
> > Linux. Neither Mac OSX nor Sun Solaris (not to mention
> > the Windows) define such constant. By looking arround
> > I see people can not find a peace of mind with it.
> > It varies between 16 and 1024 on different platforms etc.
> > I will be conservative and define that to 16 on all
> > systems that have no UIO_MAXIOV unless somebody has a
> > better idea.
> >
>
> Now, look at that.... Isn't that nice :-(
>
> 34      #ifndef UIO_MAXIOV
> 35      # if defined(__FreeBSD__) || defined(__APPLE__) || defined
> (__NetBSD__)
> 36      /* FreeBSD 4.7 defines it in sys/uio.h only if _KERNEL is
> specified */
> 37      #  define UIO_MAXIOV 1024
> 38      # elif defined(__sgi)
> 39      /* IRIX 6.5 has sysconf(_SC_IOV_MAX) which might return 512 or
> bigger */
> 40      #  define UIO_MAXIOV 512
> 41      # elif defined(__sun)
> 42      /* Solaris (and SunOS?) defines IOV_MAX instead */
> 43      #  ifndef IOV_MAX
> 44      #   define UIO_MAXIOV 16
> 45      #  else
> 46      #   define UIO_MAXIOV IOV_MAX
> 47      #  endif
> 48      # elif defined(IOV_MAX)
> 49      #  define UIO_MAXIOV IOV_MAX
> 50      # else
> 51      #  error UIO_MAXIOV nor IOV_MAX are defined
> 52      # endif
> 53      #endif
> 54
>


You've seen this?

  http://sourceforge.net/tracker/index.php?func=detail&aid=1635894&group_id=130646&atid=719006

I wasn't sure about hard coding the values and don't have a BSD
machine so wanted to check using the Sourceforge compile farm, but
it's been down for weeks...

I'm not sure there is anything else you can do.  It would be good
however to confirm how the various libc implementations handle large
values of IOV.

I believe glibc transparently chops it up into smaller pieces before
passing to the kernel.

If BSD etc. doesn't, we'll have to make sure we're handling that error
correctly.

Re: [naviserver-devel] sed -r

[Zoran V. <zv...@ar...>]

Am 20.02.2007 um 16:54 schrieb Stephen Deasey:

> What's the old skool way of doing this?

TCL_LIB="tcl$TCL_VERSION$TCL_DBGX"

Re: [naviserver-devel] sed -r

[Stephen D. <sd...@gm...>]

On 2/20/07, Zoran Vasiljevic <zv...@ar...> wrote:
> Hi,
>
> In the latest configure.in there is a "sed -r" to extract
> something out of the TCL_LIB. Can we live without that?
> "sed -r" is a Linux variant only. I know that perhaps in the
> near future, we will all be running Linux only, but this is by
> far not the case yet. Some of us are still running Mac OSX
> and Solaris...
>

Ring ring!

Hello? The 1980's called, they want their tired old shell tools back !!


Sorry, I added this...  The goal is to create a variable called
TCL_LIB which contains something like tcl8.4g, something suitable for
passing to the linker without the -l and so on.  e.g. for passing to
AC_CHECK_LIB, but there are other uses too, so I'd like to keep it if
possible.

What's the old skool way of doing this?

[naviserver-devel] sed -r

[Zoran V. <zv...@ar...>]

Hi,

In the latest configure.in there is a "sed -r" to extract
something out of the TCL_LIB. Can we live without that?
"sed -r" is a Linux variant only. I know that perhaps in the
near future, we will all be running Linux only, but this is by
far not the case yet. Some of us are still running Mac OSX
and Solaris...

Cheers
Zoran