Pike-devel May 2003

pike-devel@lists.lysator.liu.se

15 participants
36 discussions

top level infix operators
by Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum 15 May '03

15 May '03

Would such a feature be possible, or is it something that should be avoided at all costs? Just to make sure, I'm not necessarily talking operator overloading here. For instance, i've on occation wanted to have '**(double|int|string base,int|float power) for doing powers of... stuff. Other things like setoperations, integration, etc... comes to mind. I realise that interrest in this might be infinitly small - just probing.

4 7

global. coredump
by Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum 15 May '03

15 May '03

This code produces a coredumpwith pike 7.4 at pelix: int a; int main() { int b; b += global.a; } Substituting "+=" for "=" instead renders the error: core.pike:5:Assigning a void expression. Pike: Failed to compile script: Compilation failed.

2 1

Test, ignore
by Peter Bortas ＠ Pike developers forum 15 May '03

15 May '03

Bounce-test. Do not reply.

1 0

grantpt
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 14 May '03

14 May '03

Has anyone ever gotten Stdio.File()->grantpt() to work? All I get is grantpt failed: No child processes module.c:58()->files()->Fd: Fd()->grantpt() Stdio.File: Stdio.File("/dev/ptmx", "rw", 666 /* fd=3 */)->grantpt() HilfeInput:1: HilfeInput()->___HilfeWrapper() The man page for grantpt also says that The grantpt() function will fail if it is unable to success- fully invoke the setuid root program. It may also fail if the application has installed a signal handler to catch SIGCHLD signals.

2 6

Pointers/lvalues
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 14 May '03

14 May '03

Grubba and I started talking a bit about adding lvalues as an explicit data type in Pike. I'll jot down what we arrived at for the record (well, some of it are later thoughts by me): An lvalue is a pointer to a variable that allows the variable to be changed (as opposed to a pointer to a function). Generic variable pointers could be implemented by adding two new svalue types: Pointer to variable in object and pointer to variable in frame (if programs get "proper" static variables in some future they would get this too). The frame case is used for pointers to local variables in functions. Refcounting in frames is already implemented for the sake of nested functions, so returning a pointer to a local variable shouldn't be a problem. The solution with special pointer svalue types is better than the double svalue (the thing to index followed by the index) approach currently used internally for lvalues for two reasons: Firstly the index operation is performed when the pointer is created instead of when it's dereferenced, which trigs errors closer to the source. Secondly it would avoid odd effects in various functions that doesn't expect variable pointers. Pointers to values in arrays, mappings and multisets don't need new svalue types since their iterator objects can be used then (more on that later). Variable pointers would be used like in C. Silly example: int append_to_buf (Stdio.File f, pointer(string) buf) { string in = f->read(); *buf += in; return sizeof (in); } Some new operator lfuns would be needed: &foo => Get the pointer to foo; calls `& in foo. &foo->bar => Get the pointer to foo->bar; calls `&->("bar") in foo. &foo[bar] => Ditto for []; calls `&[](bar) in foo. `& and ``& already exist, so the first operator above would actually become ```& with the current naming system. We're however contemplating a new system with more verbose lfun names; `&this for the new operator, `this&_ for `&, and `_&this for ``&. The similarity between pointers and iterators is obvious, so iterators should be able to act as pointers. To accomplish that an lfun corresponding to the dereferencing * operator is necessary: *foo => Gets the value the pointer points to; calls `*this in foo. It's also interesting to have an lfun that returns a pointer svalue so that it can be used in an lvalue context. An example: for (pointer ptr = &my_obj[0]; *ptr; ptr++) *ptr = reverse (*ptr); ^^^^ Here `&*this would be called to produce a pointer value which is used as lvalue. If `&*this returns an object instead of a basic pointer svalue, `&*this would presumably be tried again, which would make it possible to produce a infinite loop if `&*this should be silly enough to return the iterator itself. A simple check for that might be a good idea. To be symmetric with `[]= and `->=, one would add a `*this=_ instead of `&*this. I do however like `&*this better since it's then possible to do e.g. *ptr += ({17}); with an efficient `+= operation without the need for a special `*this+=_. A `&*this lfun makes it possible to try it in any expression where no better suited lfun is available: foo + bar => Try: foo->`+(bar) Then: bar->``+(foo) Then: *(foo->`&*this) + bar Then: foo + *(bar->`&*this) That could be handy when implementing e.g. "smart" strings like Locale.DeferredLocale. I don't know yet if it overall is a good idea or not, though. It's clearly not a good idea in simple assignments and arbitrary function calls.

17 92

Re: Pointers/lvalues
by Per Hedbor () ＠ Pike (-) developers forum 13 May '03

13 May '03

s/while()/while() and switch()/

2 1

--localdir backwards compatibility
by nisse＠lysator.liu.se 13 May '03

13 May '03

The renaming of --localdir to --prepend-include is annoying when trying to keep a configure.in compatible between 2.13 and more modern versions. To make it less painful, I patched in some backwards compatibility to my local version of autoconf-2.57. Seems to work fine for me. --- autoconf.in-original Tue Nov 5 08:16:59 2002 +++ autoconf.in Tue Apr 15 14:23:43 2003 @@ -194,7 +194,9 @@ --prepend-include=* | -B?* | \ --warnings=* | -W?* ) AUTOM4TE="$AUTOM4TE $1"; shift ;; - + --localdir=* ) + AUTOM4TE="$AUTOM4TE --prepend-include=${1:11}" ; shift ;; + # Options with separated arg passed as is to autom4te. --include | -I | \ --prepend-include | -B | \ @@ -202,7 +204,11 @@ test $# = 1 && eval "$exit_missing_arg" AUTOM4TE="$AUTOM4TE $option $2" shift 2 ;; - + --localdir ) + test $# = 1 && eval "$exit_missing_arg" + AUTOM4TE="$AUTOM4TE --prepend-include $2" + shift 2 ;; + --trace=* | -t?* ) traces="$traces --trace='"`echo "$optarg" | sed "s/'/'\\\\\\\\''/g"`"'" shift ;; Regards, /Niels

9 16

Re: --localdir backwards compatibility
by Martin Nilsson (lambda) ＠ Pike (-) developers forum 13 May '03

13 May '03

The easiest solution is probably to cut through the FUD and fix the *major bugs* in autconf 2.13 and release autoconf 2.14.

3 2

Nettle CipherState exit assertion
by Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum 13 May '03

13 May '03

"7.5/src/post_modules/Nettle/cipher.cmod:220: exit_CipherState_struct: Assertion `info' failed." has been around in the mahoro dmalloc builds for a while now. Have you noted the problem, Nisse?

3 2

Implicit class construction, _cast() and `=()
by Alexander Demenshin 06 May '03

06 May '03

Hi everybody, This topic was discussed once here, but... Why _cast() is called only for builtin data types? When I do: (int)something; then something->_cast("int") gets called, but when I do (SomeType)something; then SomeType(something) gets called? I just can't understand why, it seems a bit unlogical (if there is some logic behind - please explain). Additionally, there is no way to distinguish between regular constructor call and when type is casted... And concerning assignment operator overloading. I believe that this will be very useful feature, and it should not be [too] difficult to implement. Well, there will be some problems when target (lvalue) may have more than one type, but in case when it is not multi-type, it should be quite simple. So... If, and only if, the object (class) defines `=() and ``=(), then: * If variable is of type SomeObject, and it is undefined, the function ``=() will be called and it should play constructor's role (we can't simply call constructor here since in this case we can't distinguish between regular constructor call and a call from assignment). * If variable is defined and contains object of type SomeObject, then the function `=() will be called. When there is ambiguity, standard behavior should be used (or exception raised, or compiler error, etc). This way, IMHO, we can keep compatibility, and use very nice and useful feature same time. Any opinions, suggestions, idea, flames? :) Regards, /Al

4 16

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 May 2003