hi,
instead of having to do:
reverse(reverse(foo/"/")[1..]);
i'd very much prefer:
(foo/"/")[..-2];
are there any reasons that speak against supporting this
other than me not being able to offer a patch?
greetings, martin.
Not a good idea; the design philosophy of Pike is that Pike-level code
should never be able to cause memory corruption at C-level.
With ioctls there's no way to know what data a specific ioctl wants
without reading the documentation for that specific ioctl for that
specific OS. ioctls and fcntls are a way for device handlers to hook
in APIs that aren't standard across all filedescriptors.
/ Henrik Grubbström (Lysator)
Previous text:
>2004-08-17 13:32:
>Subject: managing comport settings in linux
>--------------------------------------------------------------------
>What would be nice, is a way to define ioctl methods in
>Pike. Perhaps something like
>
>object i = Stdio.IOCTL(4242 /* request_id */ );
>i->add_int_parameter();
>i->add_string_parameter();
>i->set_return_type(STRING);
>
>string ret = i(fd, 1, "somestring");
>
>
>That ought to be possible, or..?
>
> / Marcus Agehall (PacketFront)
>
HI to all!
mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is
this correct ?
are there plans to make a full 4.x support ?
bye, thomas
hi,
can you explain why:
random(allocate(3,9)[*]);
or
random(({9,9,9})[*]);
don't work,
while
array foo = allocate(3,9);
random(foo[*]);
does?
greetings, martin.
Pike v7.6 release 7 running Hilfe v3.5 (Incremental Pike Frontend)
> int year=2004;
> int month=12;
> int day=2;
> object oday = Calendar.Year(year)->month(month)->day(day);
Compiler Error: 1:syntax error, unexpected '('
Compiler Error: 1:syntax error, unexpected '('
>
???
can anyone explain this?
greetings, martin.
6
8
Pike string hashing
by Marcus Agehall (PacketFront) @ Pike (-) developers forum
20 Apr '05
20 Apr '05
I'm a bit curious about the string hashing algorithm used in
Pike.
What algorithm is it based on and what complexities does it exhibit?
Was it selected at random or is there some rationale behind it..?
I think the new streaming behavior in Sql.mysql.big_query is nice and
as it should be, but it's causing too much headaches in existing
applications - the old de-facto behavior is too ingrained.
So a proposal is to instead do like this:
query: Like today - slow and memory consuming.
big_query: A variant of query() that still is nonstreaming. I.e.
it only avoids the very bulky response format of
query().
streaming_query: Like big_query but guaranteed to stream if it
exists. It's database dependent whether other queries
can be issued while a streaming_query response object
exists. It's of course also database dependent if
there are locks on the tables in the server while the
response object exists.
While at it, we could also consider generalizing the big_typed_query
interface that the oracle module provides:
big_typed_query: Like big_query but doesn't convert everything to
strings. Integers and floats are kept that way,
Date/timestamps are Calendar objects, there are
objects for representing the NULL value for each type.
streaming_typed_query: Streaming variant of big_typed_query.
As stated xenofarm reports 2 errors. IMO this one is a bit harder.
Pike version=7.7.13
The problem fails in running test_resolve.pike. Pike segfaults.
After logging I found the program to fail with one file.
If I remove the file with which this occurs (FIPS10_4.pmod) it doesn't
segfault anymore.
When using hilfe, the same error occurs:
> master()->resolv(Standards.FIPS10_4.pmod);
Segmentation fault
This *only* occurs on my sparc64 (debian) and not on a i386.
I've created an test-program which inherits Standards.FIPS10_4
it also segfaults.
I've attached an strace on this process which I've included as
attachment (hope it helps).
I can send more debugging info if necessary, but I have no clue where to
go next.
Best regards,
Marc
I didn't konw exactly meaning of file mode in the method mode(),is there some one could help me ?
the mode I didn't know is :
FILE_EXCLUSIVE
FILE_SET_CLOSE_ON_EXEC
FILE_HAS_INTERNAL_REF
FILE_NO_CLOSE_ON_DESTRUCT
FILE_LOCK_FD
FILE_NOT_OPENED