Pike-devel

pike-devel@lists.lysator.liu.se

3041 discussions

building pike with pike (7.7 cvs)
by Mirar ＠ Pike developers forum 15 Apr '07

15 Apr '07

>bin/mkpeep.pike:463:Too many arguments to sprintf. >bin/mkpeep.pike:463:Expected: function(string(8), int(0..2147483647) : string) >bin/mkpeep.pike:463:Got : function(string(8), int, string : void | mixed) > >463: buf->add_line( sprintf("%*n}", ind, test) ); Er, I see now the problem is that »test» is a string, so it is a bug in mkpeep...

2 3

building pike with pike (7.7 cvs)
by Mirar ＠ Pike developers forum 15 Apr '07

15 Apr '07

I suspect these problems depend on the new typechecker... bin/mkpeep.pike:463:Too many arguments to sprintf. bin/mkpeep.pike:463:Expected: function(string(8), int(0..2147483647) : string) bin/mkpeep.pike:463:Got : function(string(8), int, string : void | mixed) 463: buf->add_line( sprintf("%*n}", ind, test) ); Can't work around that. Copying an old peep.c, bin/precompile.pike:2006:Too many arguments to sprintf. bin/precompile.pike:2006:Expected: function(string(8), object | int, object | string, object | int, object | string : string) bin/precompile.pike:2006:Got : function(string(8), int, string, int, string, string : void | mixed) 2006: PC.Token(sprintf("if(Pike_sp[%d%s].type != PIKE_T_STRING || Pike_sp[%d%s].ustring -> width)", 2007: argnum,check_argbase, 2008: argnum,check_argbase, 2009: upper_case(arg->basetype())),arg->line()) This is true, however I don't think "too many arguments to sprintf" should be an error, but a warning, unless it's strict_types. (But that's my personal opinion.)

1 0

sprintf() arguments now type checked in Pike 7.7.
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 13 Apr '07

13 Apr '07

I've added some type checking support for sprintf() arguments: New type checker: > sprintf("%s%i%f\n", 17, "", 14.0); Compiler Error: 1:Error in format string, i is not a format. Compiler Error: 1:Bad argument 2 to sprintf. Compiler Error: 1:Expected: object | string Compiler Error: 1:Got : int(17..17) Compiler Error: 1:Bad argument 3 to sprintf. Compiler Error: 1:Expected: object | float Compiler Error: 1:Got : string(0) Compiler Error: 1:Too many arguments to sprintf (expected 3 arguments). Compiler Error: 1:Got : float Old type checker: > sprintf("%s%i%f\n", 17, "", 14.0); Compiler Error: 1:Error in format string, i is not a format. Compiler Error: 1:Too many arguments to sprintf. Compiler Error: 1:Expected: function(string(8), object | string, object | float : string) Compiler Error: 1:Got : function(string(8), int(17..17), string(0), float : void | mixed)

2 2

New function call type checker for pike
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 01 Apr '07

01 Apr '07

Those who have monitored the Pike 7.7 CVS the last week or so, may have noticed a few new type checking related functions. These are intended to replace the current style of type checking where a function type for the current call is created and then compared in one pass against the declared type. This has led to somewhat cryptic error messages. eg: > `+((["":14]), "", 14); Compiler Error: 1:Bad argument 2 to `+. Compiler Error: 1:Expected: !function(!(object | mixed) ... : mixed) & function | function(int, int ... : int) | !function(!float ... : mixed) & function(int | float, int | float ... : float) | !function(!string ... : mixed) & function(string | int | float, string | int | float ... : string) | function((0=array), (1=array) ... : 0 | 1) | function((0=mapping), (1=mapping) ... : 0 | 1) | function((0=multiset), (1=multiset) ... : 0 | 1) Compiler Error: 1:Got : function(mapping(string(0):int(14..14)), string(0), int(14..14) : void | mixed) The new code is instead based on checking the arguments one at a time, but this means that the error in the above case is first detected when the last argument is checked: Compiler Error: 1:Bad argument 3 to `+, got int(14..14), expected object. This problem can be reduced by also adding warnings about prior arguments in case of the above error: Compiler Warning: 1:Potentially bad argument 2 to `+, got string(0), expected mapping | object. The question is what text the warning should have.

4 6

New function call type checker for pike
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 30 Mar '07

30 Mar '07

Hmm... Seems to work even for the more obscure cases: > typeof(class{}); (4) Result: function( : object(is HilfeInput()->__class_65709_0_line_1)) > typeof(Stdio.Stat()); (5) Result: object(is _static_modules.files()->Stat) Note that it will fall back to the old syntax if it fails to look up the program id: > _typeof(compile_string("")); (6) Result: function( : object(is 65723)) > mixed x = compile_string(""); > _typeof(x); (7) Result: function( : object(is -))

1 0

New function call type checker for pike
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 30 Mar '07

30 Mar '07

1 0

step and break opcodes
by H. William Welliver III 29 Mar '07

29 Mar '07

Can someone familiar with what it would take to enable these under machine code take a moment to explain this? I'd also like to know what the associated issues might be. I want to get this sorted out, and am not sure whether it's something I can do myself, or if I need to coax/hire someone to do it for me :) Bill

1 0

7.6.104 beta
by Peter Bortas ＠ Pike developers forum 28 Mar '07

28 Mar '07

http://pike.ida.liu.se/pub/pike/beta/7.6.104/Pike-v7.6.104.tar.gz Me, Grubba, Marcus and Nilsson spent the entire afternoon debugging win32 until we got it working. So this is what I hope is the final release candidate. Ther are more changes than I would have liked since 7.6.102, but they are for real problems in SSL so I can't back them out. Shortlog for changes since: 7.6.102: * All the recent fun time zone stuff. * A bunch of SSL fixes. * Double-free fixed in Shuffle. * Things work on win32 again. Might release it as stable on sunday night unless I come up with a reason not to.

5 10

problems resolving program in a cmod
by Arne Goedeke ＠ Pike developers forum 20 Mar '07

20 Mar '07

I used to do this to get a program of an external class in c: ... push_text("Someclass"); SAFE_APPLY_MASTER("resolv", 1); if (((struct svalue *)(Pike_sp - 1))->type != PIKE_T_PROGRAM) { Pike_error("Could not resolv program Someclass.\n"); } prog = ((struct svalue *)(Pike_sp - 1))->u.program; ... However this does not work for me anymore when I try to resolv a Class that is defined inside the pmod that corresponds to the cmod (in my case in Public.Parser.JSON2 where Public.Parser.___JSON2 is the cmod). Any ideas how to do that? arne

5 13

Parser.XML.Tree
by Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum 19 Mar '07

19 Mar '07

Pretty high latency, I know, but this didn't became a problem until now (again): About a year ago I rewrote the Parser.XML.Tree to be much more object oriented. The major design goal was to be able to easily redefine the produced nodes in the tree. Basically you could do class Node { inherit Parser.XML.Tree.Node; void my_method() { return 7; } } Node n = Node(Stdio.read_file("file.xml")); and get my_method() in all the produced nodes. Today we are however back to the one-class-per-node-type-approach where you basically has to inherit the entire Parser.XML.Tree module to be able to modify its behaviour. Why is that?

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel