There's no point checking for existence unless you're also going to do
something with it -- that's a separate operation and that's a race
condition.
If the cache is used to keep some flag about somehting, other thread can
just check if flag is set then do something.
A read only cache doesn'
On 4/16/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> No, ns_cache_exists should be kept, it is useful sometimes to check if
> the entry there, for read-only caches for example.
There's no point checking for existence unless you're also going to do
something with it -- that's a separate operation
No, ns_cache_exists should be kept, it is useful sometimes to check if
the entry there, for read-only caches for example.
It's hard to tell exactly the real problem, once your application is
over 100K lines of Tcl code which implements the whole company's
OSS/backoffice, there are a lot of spe
On 4/5/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> Yes, i use cache and in my case i do need to use get and set in
> different situations, for example i need to set cache entry regardless
> of what is there, eval will return me existing value, so i need to flush
> it first which gets to the same
Yes, i use cache and in my case i do need to use get and set in
different situations, for example i need to set cache entry regardless
of what is there, eval will return me existing value, so i need to flush
it first which gets to the same race condition issue.
Same with get, i just need to get
Yes, this is temporary, testing is not going very fast because i am busy
at work but i keep trying to resolve this issue. Of course all your help
is appreciated, eventually test will do overflow and weird size.
Stephen Deasey wrote:
On 3/7/06, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Update o
Am 06.01.2006 um 08:25 schrieb Stephen Deasey:
Don't forget to run make test before you commit...
ns_conn-1.2 basic syntax: wrong argument FAILED
Ah...
Zoran
ChangeLog in the distiribution will give you pretty clear picture
what've been changed and added, top level overview of chnaged also in
NEWS file.
Zoran Vasiljevic wrote:
On 05.12.2005, at 09:54, Nima Mazloumi wrote:
Hello,
is the naviserver then aolserver + extensions? And what are the m
> Recently i do not receive anything from the list.
vlad, you can verify / sync online:
http://sourceforge.net/mailarchive/forum.php?forum=naviserver-devel
On 04.12.2005, at 21:23, Vlad Seryakov wrote:
Strange i've never seen this post on the mailing list.
Recently i do not receive anything from the list.
It was not on the list. It was sent to me directly.
Zoran
Strange i've never seen this post on the mailing list.
Recently i do not receive anything from the list.
Zoran Vasiljevic wrote:
On 03.12.2005, at 17:32, Nima Mazloumi wrote:
Hello,
I found this server at sourceforge and was wondering why the features
were not committed to the aolserver i
Am 29.06.2005 um 04:04 schrieb Stephen Deasey:
The 'V' in Ns_ConnVSetHeaders() suggests it takes a va_list, as in
Ns_DStringVPrintf() used in the implementation.
Unfortunately, Ns_ConnPrintfHeader() already exists. It prints
directly to the output stream which looks pretty silly. The function
yes, i was confued with that function as well.
if it is not used we better rename/drop it, i agree about using V but
that was the best i was able to come up with:-)))
Stephen Deasey wrote:
On 6/28/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
Update of /cvsroot/naviserver/naviserver/include
I
Am 24.06.2005 um 22:41 schrieb Stephen Deasey:
Finally, is this function necessary? Ns_ConnReturnFile already exists
in fastpath.c.
Absolutely. I'm removing this from the code.
Zoran
Am 27.06.2005 um 05:48 schrieb Stephen Deasey:
What does 'tcp' stand for? How about 'cwd':
tcp is rubbish. I have fixed this now.
Zoran
Am 27.06.2005 um 07:06 schrieb Stephen Deasey:
This Windows only command asks for a restart, right? This should be
hooked up to the -restart switch of the ns_shutdown command, which is
essentially the same thing. Otherwise, Tcl programmers will have to
test the current platform to portably res
All that encoding also depends on how your server configured, does it
use non-standard encoding or everything in UTF. Eastern websites usually
support many languages and there all encoding/translation goes, so being
able to explicitly handle binary data is important.
Zoran Vasiljevic wrote:
Am 10.06.2005 um 18:55 schrieb Stephen Deasey:
You've just passed arbitrary bytes to an API which expects UTF8.
Expect your server to crash...
Hm
set chan [open /the/file.img]
fconfigure $chan -translation binary
set datain [read $chan]
close $file
nsv_set Images file.img $datain
#
set
This is i missed, never thought it is available
Stephen Deasey wrote:
Tcl_ObjType byteArrayType = Tcl_GetObjType("bytearray");
On 6/10/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
The problem is, there is no Public API to check object for ByteArray
type. You have to include tclInt.h for this
On 6/10/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 10.06.2005 um 17:42 schrieb Stephen Deasey:
>
> > That being the
> > case, you should be able to check the type of the object given to
> > ns_return, and act accordingly
> >
>
> And what if it shimmers away?
>
> You read-in the fil
Tcl_ObjType byteArrayType = Tcl_GetObjType("bytearray");
On 6/10/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> The problem is, there is no Public API to check object for ByteArray
> type. You have to include tclInt.h for this which is not public.
>
> Stephen Deasey wrote:
> > On 6/10/05, Vlad S
On 6/10/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 10.06.2005 um 17:50 schrieb Vlad Seryakov:
>
> > Second try :-)))
>
> You'd get (probably) a sigsegv if somebody says:
>
>ns_return -binary 200
>
> Yes, this arg parsing can be a PITA. Therefore I like
> Stephens tclobjv code :
For future reference, you can hande this by using the Ns_ObjvObj
option/arg type which just gives you back the underlying Tcl object.
You can then handle it however you like.
On 6/10/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> yes, parsing should check for nulls an dlimits, just to see if ide
yes, parsing should check for nulls an dlimits, just to see if idea is
coorrect. obkv parsing will not work here because i will need change on
the fly TclObjvString and TclObjvByteArray.
if (objc > param && !strcmp(Tcl_GetString(objv[param]),"-binary")) {
binary = 1;
param++
Am 10.06.2005 um 17:50 schrieb Vlad Seryakov:
Second try :-)))
You'd get (probably) a sigsegv if somebody says:
ns_return -binary 200
Yes, this arg parsing can be a PITA. Therefore I like
Stephens tclobjv code :-)
Unfortunately, it won't do the boolean flags, but we've
discussed that alrea
The problem is, there is no Public API to check object for ByteArray
type. You have to include tclInt.h for this which is not public.
Stephen Deasey wrote:
On 6/10/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I thought about ns_return -binary as well. first -binary flag is
optional so it will
Am 10.06.2005 um 17:42 schrieb Stephen Deasey:
That being the
case, you should be able to check the type of the object given to
ns_return, and act accordingly
And what if it shimmers away?
You read-in the file with "-translation binary" put the resulting data
in the nsv_array, and get it ba
Second try :-)))
int
NsTclReturnObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
Ns_Conn *conn;
unsigned char *data = 0, *type = 0;
int result, param = 1, status = 0, len = 0, binary = 0;
if (!strcmp(Tcl_GetString(objv[param]),"-binary")) {
On 6/10/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> I thought about ns_return -binary as well. first -binary flag is
> optional so it will be compatible with the old API. Let me try this.
>
> Zoran Vasiljevic wrote:
> >
> > Am 10.06.2005 um 15:41 schrieb Vlad Seryakov:
> >
> >> * Tcl_GetByteArr
Am 10.06.2005 um 17:23 schrieb Vlad Seryakov:
How about this, i tested it :
int
NsTclReturnObjCmd(ClientData arg, Tcl_Interp *interp, int objc,
Tcl_Obj *CONST objv[])
Hm... I would say, if somebody wanted to do:
ns_return 200 text/plain -binary
you'd have a problem, right?
Zoran
How about this, i tested it :
int
NsTclReturnObjCmd(ClientData arg, Tcl_Interp *interp, int objc, Tcl_Obj
*CONST objv[])
{
Ns_Conn *conn;
unsigned char *data = 0, *type = 0;
int i, result, status = 0, len = 0, binary = 0;
for (i = 1;i < objc;i++) {
if (!strcmp(Tcl_GetStri
I thought about ns_return -binary as well. first -binary flag is
optional so it will be compatible with the old API. Let me try this.
Zoran Vasiljevic wrote:
Am 10.06.2005 um 15:41 schrieb Vlad Seryakov:
* Tcl_GetByteArrayFromObj --
*
* Attempt to get the array of bytes from the Tcl obj
Am 10.06.2005 um 15:41 schrieb Vlad Seryakov:
* Tcl_GetByteArrayFromObj --
*
* Attempt to get the array of bytes from the Tcl object. If the
* object is not already a ByteArray object, an attempt will be
* made to convert it to one.
So, if i call ns_return from Tcl and pass data
Yes, i see.
fixed
Stephen Deasey wrote:
On 6/9/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
I have no failed tests
Tests running in interp: /home/vlad/src/naviserver/nsd/nsd
Tests located in: /home/vlad/src/naviserver/tests
Tests running in: /home/vlad/src/naviserver/tests
Temporary files
* Tcl_GetByteArrayFromObj --
*
* Attempt to get the array of bytes from the Tcl object. If the
* object is not already a ByteArray object, an attempt will be
* made to convert it to one.
So, if i call ns_return from Tcl and pass data parameter, it will be
always type of String. B
I think it's fine to also alow ns_return to handle binary data, I'm
just wondering if it should be with the extra command ns_returnbinary?
It looks like you can simple check the type of the Tcl object passed
to ns_return for "bytearray". That's the only case it makes sense to
write the bytes dire
On 6/9/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
> I have no failed tests
>
> Tests running in interp: /home/vlad/src/naviserver/nsd/nsd
> Tests located in: /home/vlad/src/naviserver/tests
> Tests running in: /home/vlad/src/naviserver/tests
> Temporary files stored in /home/vlad/src/naviserv
ns_respond now supports binary so ns_returnbinary is redundant, but i
think Tcl_GetByteArray works with string and byte array, just
Tcl_GetByteArray does not do eny encoding/converting to/From utf.
Stephen Deasey wrote:
Before you cvs commit, you must make test. Two tests are broken...
We're
I have no failed tests
Tests running in interp: /home/vlad/src/naviserver/nsd/nsd
Tests located in: /home/vlad/src/naviserver/tests
Tests running in: /home/vlad/src/naviserver/tests
Temporary files stored in /home/vlad/src/naviserver/tests
Test files sourced into current interpreter
Running te
yes, my bad, my modules subdir under naviserver and commit took it with
main comit.
Stephen Deasey wrote:
Before you cvs commit, you must cvs diff. This commit message does
not go with this change. It doesn't even go with this module.
On 6/9/05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
U
Okay, i thought it is global for the whole project.
I am maintaning modules i imported but they need some work for adding
all those files.
Stephen Deasey wrote:
The NEWS file is just like the ChangeLog in the sense that it only
refers to changes in the package it's contained in. Each of the
m
Am 17.04.2005 um 00:37 schrieb Stephen Deasey:
Hmm, I think this should return the old status, right?
Huh... again the same trap!!! It seems pretty unlogical
hence we have gotten there twice. Sorry... It was a long
day yesterday. I will fix this right away.
Zoran
On 4/11/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> Am 11.04.2005 um 05:05 schrieb Stephen Deasey:
>
> > I guess this is an OSX problem? While looking at the configure tests,
> > I noticed that gethostbyname_r etc. are not used on Linux, even though
> > they're available. The standard c
Am 11.04.2005 um 05:05 schrieb Stephen Deasey:
I guess this is an OSX problem? While looking at the configure tests,
I noticed that gethostbyname_r etc. are not used on Linux, even though
they're available. The standard call is thread safe, but only because
glibc puts a lock around everything.
http://cvs.sourceforge.net/viewcvs.py/naviserver/naviserver/nslog/nslog.c?rev=1.3&view=log
The cvs commit message for nslog/nslog.c now reads:
"Add Ns_ConnSetResponseStatus command to be able to se response status
without touching headers. Also ns_conn status has been extended with
ability to se
On Thursday 03 March 2005 09:43, Stephen Deasey wrote:
> I've noticed some problems with this recent change.
>
>
> The log message doesn't say what has changed, just that something has
> changed, although the ChangeLog entry is better. The X-Forwarded-For
> change is a bug fix and is not mention
I've been using that new module for so long time that i did not realized
that the code is so different than
current style, i am sorry.
The log message doesn't say what has changed, just that something has
changed, although the ChangeLog entry is better. The X-Forwarded-For
change is a bug fix
47 matches
Mail list logo
