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..?
3
5
Re: subversion bindings?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum
11 Apr '05
11 Apr '05
Nope. My router does NAT for the machine in question, but that should
not matter for HTTP.
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.
9
20
"temp"
by Peter Bortas @ Pike developers forum
31 Mar '05
31 Mar '05
Just so that no one gets confused: The Xenofarm results from the host
"temp" are compiled in a Cygwin environment. I will fix the hostname
eventually.
5
10
cmod-format
by Martin Nilsson (DivX Inc.) @ Pike (-) developers forum
30 Mar '05
30 Mar '05
The recent complete backport of precompile.pike from 7.7 to 7.6 breaks
some cmod files, since the API has changed for object|void variables.
They are no longer svalues but objects. Was this intentionally? If so, I
think it was a bad idea.
1
0
Image.JPEG
by M Norrby (rabies), Enea Epact @ Pike (-) developers forum
30 Mar '05
30 Mar '05
Nilsson has fixed the configure stuff for Image.JPEG (in 7.7) so that
the transform stuff now is included in the Windows build too. I think
it is backported to 7.6.
I was wondering if someone with the right permissions could backport
it to 7.4 if possible. It would be nice if the next Windows version of
Roxen (based on 7.4) had the same Image.JPEG support as the Unix
versions.