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
4
4
pcvs2git.pike
by Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
14 Mar '10
14 Mar '10
I just tried converting Roxen 2.4:
Stage Memory use Commits
---------------------------------------
Import 339 MB ~17000
Raking 359 MB ~17000
Verify 361 MB ~17000
Merging 662 MB 11886
Graphing 803 MB 10897
Generate 803 MB 10897
I believe that the memory use can be reduced by using more custom
datatypes (currently there are a lot of mappings generated in the
merging and graphing stages). Another way to reduce the memory use
is to partition the graphs in the time axis.
Some time next week I'll upgrade eureka from Solaris Express snv_81 to
whatever the latest stable OpenSolaris release is. There is no
straight forward upgrade path from SXCE to OpenSolaris, so the machine
will be reinstalled and the data restored from backup.
That means there will be some substancial downtime for people using
services on eureka. More details later.
do_async_method_url overrides the content-type given in extra headers.
Its possible to work around it by using "Content-Type" instead of
"content-type". This is relevant at least in the XMLRPC module, not
sure if anybody noticed. here is a patch
arne
diff --git a/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike b/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike
index 5b82fc9..b7e2e74 100644
--- a/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike
+++ b/lib/modules/Protocols.pmod/HTTP.pmod/Session.pike
@@ -874,8 +874,8 @@ Request async_do_method_url(string method,
if (method=="POST")
extra_headers=
- (extra_headers||([]))+
- (["content-type":"application/x-www-form-urlencoded"]);
+ (["content-type":"application/x-www-form-urlencoded"])+
+ (extra_headers||([]));
p->do_async(p->prepare_method(method,url,query_variables,
extra_headers,data));
2
8
replace
by Mirar @ Pike developers forum
29 Oct '09
29 Oct '09
why do
> replace(({1,2,3}),2,17);
(6) Result: ({ /* 3 elements */
1,
17,
3
})
work, while
> replace(({1,2,3}),({2}),({17}));
(5) Result: ({ /* 3 elements */
1,
2,
3
})
does nothing?
4
5
release
by Peter Bortas @ Pike developers forum
22 Oct '09
22 Oct '09
It's time to do a stable release again. If you have low risk but
potentially build breaking code in the pipe then check it in now. I'll
aim for a release next week.
1
0
pcvs2git.pike
by Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum
19 Oct '09
19 Oct '09
The above file is now available via git://pike-git.lysator.liu.se/pcvs2git.git/
Note: Requires rcs (and git).
Note that the tool is by no means finished, but it seems to generate
an acceptable git archive from the repositories that I've tested with.
Caveat emptor: I've not tested with any repositories larger than the
Pike 0.5 repository yet (~7000 file revisions).
In the following case the optimizer seems to assume, that the array does
not change during the loop and optimizes away the sizeof check:
int main() {
array a = ({ 1, 2, 3, 4, 5 });
void magic(int k) {
a = a[0..k-1] + a[k+1..];
};
for (int i = 0; i < sizeof(a); i++) {
if (a[i] == 2) {
magic(i);
i--;
}
}
return 0;
}
I assume cases like this are hard to detect, especially because
this can me made even more complicated. I will put in some
if (0) { ret = ({});}
equivalent to trick the optimizer for now.
arne