Pike-devel June 2007

pike-devel@lists.lysator.liu.se

5 participants
18 discussions

hr_gauge
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 11 Jun '07

11 Jun '07

Happened to note that linux implements the posix clock_gettime(3) interface, so I fixed 7.7 to use that for gethrtime and gethrvtime. And lo and behold, it now has nice nanosecond resolution with thread local accounting for cpu time. :) (At least with a fairly modern linux - ymmv.) For those that don't know, this has been miserable before. The best function supported by glibc has been times(2) which has lousy resolution (10 ms!) and isn't thread local. That has rendered gethrvtime and gauge practically useless. So I was thinking of adding a nanosecond variety of gauge {...} too. It's not strictly necessary; the current gauge in a pike compiled with standard 32 bit floats can just barely cope with the time for the shortest possible pike snippet: > sprintf ("%e %.9f", gauge {}, 1 + gauge {}); Result: "7.210e-07 1.000000715" A gauge that returns integer nanoseconds could however be useful if one adds together a lot of short intervals, and it's very easy to add. In lack of better ideas, I was thinking of calling it "hr_gauge". What do you think? Note that the name would become a new keyword.

2 5

find filename from program?
by Martin Bähr 11 Jun '07

11 Jun '07

hi, i am trying to access the source that a program/object/function is coming from. the information must be there somewhere, since eg a backtrace produces it, but i can't figure out how to get to it. it would be sort of like the reverse of master()->program_path_to_name(). any suggestions? greetings, martin.

6 17

tab-completion
by H. William Welliver III 06 Jun '07

06 Jun '07

I haven't looked at the code yet, but was wondering if consideration has been given to making the options-offering code generic so that it could be called by non-hilfe code. Specifically, I'm thinking of the ability to use it in PDT/Eclipse. Not having to reinvent the wheel would be nice. Bill

2 1

Changes coming to 7.7
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 04 Jun '07

04 Jun '07

Peter pulled together some people for sessions to bring 7.8 a little closer, some weeks ago, by forcing people to talk to one another, do some debugging, set up linux on his PS3, have kladdkaka and generally have a good time. I took some notes, and they were briefly circled for validity among participants prior to being completely forgotten. They just surfaced, again, in a spot of enlightened recollection; enjoy! Order is semi-random, some points already have been implemented since then and where things are difficult to understand, other participants can hopefully give better explanations on request. Conclusions: * Backend hack: fall back to poll if epoll does not work. * Remove varargs support (here meaning automatic "|void" decoration of all attributes -- not the trailing "<type> ... args" support). * Remove all traces of write << "foo" and similar "C++ streams" hacks. (which have not worked since Pike 0.5 or something like that anyway) * Stuff setting nonblocking mode should first check whether they could before propagating to a backend (select) or not. * GLUE initialization might be a bit lazier about setting up lights. * Locale generates deferred call_out:s -- don't, until Locale is used. * Pike 7.7 split to 7.8/7.9, feature freezing 7.8. * Mast, grubba and others commit their experiments to 7.7 first. * Others, feel welcome to mention what you're cooking, estimating when it might be checked in, for same split. * Attribute no_return. * Attribute for type checking (sprintf, werror). * Typedefs are good. * Turn on features in 7.7 by default which are intended to be deployed in pike 7.8. (This includes the new types and mapping-keypair-loop.) * Binary Hollerith encoding for sprintf/sscanf (%H, %2H, %-4H et c). * Add a structured way of reading/writing serialized data. * Add the function signatures int max(string s) and int min(string s). * For pike 8.0, add a buffer type (somewhat similar to System.Memory, but as a base type). I/O calls that presently handle string(0..255) should instead use buffer. It should further on be really easy using codecs like Locale.Charset to transition the buffer to/from strings, without much syntactic overhead, so you'd only be using the buffer directly when you're actually working on raw binary data. * The new compiler also aims for pike 8.0. * Buffer literals? {[ 17, /* ..., */ "foo", 0xBA ]} might be a syntax. * Stdio.read_file() shall take one parameter only (a file name), so that it might eventually blend in with the above for handling some additional parameter to specify an encoding. The result might look something like: buffer read_file( string filename ) string read_file( string fn, string|Locale.Charset.Decoder charset ) * We have rather many different-looking streaming interfaces in Pike; consolidating them to a common naming scheme and possibly leveraging that with features that make sense wouldn't hurt. * There are lots of include files strewn about the place at random that would benefit from some cleanups. * It should be possible to build modules separately. * Add testsuite coverage for pike -x module so breakage there does not fly below radar for extended periods of time. * grubba checks in the whitefish repository below cvsroot/projects/ * eventually: move out modules so they do not live in pike core * Math operations on NaN dump core under ix86; fix. * Add a syntax for type propagation (on the pike level); examples: - a function that returns a type mimicing its first argument - popen can now return file objects -> strict type checks explode

3 3

returning error objects anywhere?
by Martin Bähr 02 Jun '07

02 Jun '07

hi, is there any reason to not convert all errors that are being thrown anywhere in pike 7.7 to error objects? if not, then i'd prefer to stomp on any that i come accross rather than keep using tests on the error type. greetings, martin.

8 27

catch warnings?
by Martin Bähr 02 Jun '07

02 Jun '07

while we are on the subject of error handling, is there a way to catch warnings? in hilfe, warnings just get spewed out with broken formatting because they are not using the right write function. and generally i'd like to be able to control how warnings are handled, either for formatting, logging or elevating them to an error. greetings, martin.

2 1

string declarations and pike autodoc parsing
by Martin Bähr 02 Jun '07

02 Jun '07

while testing the documentation build i discovered that StringType was defined as string(width), however the actual implementation appears to require string(minwidth..maxwidth): > string(8) foo; Compiler Error: 1:parse error, unexpected `')'', expecting `TOK_DOT_DOT' or `TOK_DOT_DOT_DOT' Compiler Error: 1:Expected integer range. now i find references to string(width) in the documentation, which i guess should be changed, but to what? string(0..8) or string(0..255) or? greetings, martin.

3 3

Re: returning error objects anywhere?
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 01 Jun '07

01 Jun '07

> trig a specific catch somewhere, without having to implement an > entirely-fledged compatible error object. The hazards of changing phrasing.. That should read "without having to implement an entirely compatible error object", of course.

1 0

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 June 2007