Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

None
by None 08 Mar '22

08 Mar '22

xenofarm_result.tar file could be gzipped: ----8<----8<----8<----8<---- cd xenofarm_result && tar cf - . > ../xenofarm_result.tar gzip -f9 xenofarm_result.tar ---->8---->8---->8---->8---- $ pwd ~/Code/Pike/xenoclient/pike-7.7/nutella/buildtmp/Pike-v7.7-snapshot $ cd xenofarm_result $ pwd ~/Code/Pike/xenoclient/pike-7.7/nutella/buildtmp/Pike-v7.7-snapshot/xenofarm_result $ tar cf - . > ../xenofarm_result.tar $ ls buildid.txt configcache.txt _core.txt compilelog.txt configlogs.txt mainlog.txt $ gzip -f9 xenofarm_result.tar gzip: xenofarm_result.tar: No such file or directory Shouldn't the last line be "gzip -f9 ../xenofarm_result.tar" instead? -- Bertrand LUPART Linkeo.com - R&D | http://www.linkeo.com/ +33 1 72 71 71 82 | 17, rue de la Banque - F75002 Paris Systèmes de gestion d'email entrant | Email management systems

1 0

None
by None 08 Mar '22

08 Mar '22

attributes to UNIX protection mode flags. / Henrik Grubbström (Lysator) Previous text: >2004-04-06 15:17: >Subject: WINAPI >-------------------------------------------------------------------- >My guess is that dtox means "DOS to UNIX" and sets line end conversion. > > / Martin Nilsson (provokatör) >

1 0

None
by None 08 Mar '22

08 Mar '22

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-02-07 17:02: >Subject: sscanf and Gmp.mpq >-------------------------------------------------------------------- >Would it hurt much to feed the constructor the remainder of the string >and have the genereated object remember how much of it that it wanted? > > / Johan Sundström (Achtung Liebe!) >

1 0

None
by None 08 Mar '22

08 Mar '22

over the past days (and I may be off by a mile here), the current set of Caudium/PExt modules (ab)use some or other pike aclocal.m4 macros in an aclocal/automake context, somehow leading to the uncomfortable situation with the debian packages' redistribution of those internals to an overly exposed location. Is that the case (leading to the small skirmish conflict of whether the bug is in pike, or in those modules), or is there no particular rational argument behind keeping "pike -x module" in its current broken state (except for "I am not familiar with this, do not use it myself and haven't had the time to look at it closely yet", as I believe Marek has almost said) for the benefit of those modules? (I've really been trying to understand Marek's point of view, despite not being fully educated on automake and friends.) / Johan Sundström (Achtung Liebe!) Previous text: >2004-01-27 16:54: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >The one and only way to compile Pike modules that should be endorsed >and/or developed is "pike -x module". That's it. If it doesn't work >it. If it requires the entirety of Pike, deal with it. > >That's about all I have to say. > > / David Hedbor >

1 0

None
by None 08 Mar '22

08 Mar '22

PRINTPTRDIFFT is not defined. / Niels Möller (vässar rödpennan) Previous text: >2004-01-16 13:24: >Subject: PRINTPTRDIFFT on pike 7.5 >-------------------------------------------------------------------- >Hello there, > >Seems that some code in new pike 7.5 use some special extension of Gcc >(3.x I assume) : > >/usr/home/kiwi/Pike-v7.5.17/src/array.c:268: syntax error before >`PRINTPTRDIFFT' >/usr/home/kiwi/Pike-v7.5.17/src/array.c: In function `simple_set_index': >/usr/home/kiwi/Pike-v7.5.17/src/array.c:321: syntax error before >`PRINTPTRDIFFT' >/usr/home/kiwi/Pike-v7.5.17/src/array.c: In function >`array_get_item_ptr': >/usr/home/kiwi/Pike-v7.5.17/src/array.c:1295: syntax error before >`PRINTPTRDIFFT' > > >The code that blown is : > > index_error(0,0,0,&tmp,ind, > "Index %"PRINTPIKEINT"d is out of array range " > "%"PRINTPTRDIFFT"d..%"PRINTPTRDIFFT"d.\n", > p, -a->size, a->size-1); > >The %"PRINTPTRDIFFT" part is not handled by my GCC (gcc 2.95.4 20020320 >[FreeBSD]). > >Removing the "PRINTPTRDIFFT solve the problem since FreeBSD 4.8 / 4.9 >are stable OS and gcc 2.95.x are >on lots of OS. > >BTW: I am in the process to add a pikefarm there to show Pike >developpers the problems. > >/Xavier > > > > / Brevbäraren >

1 0

None
by None 08 Mar '22

08 Mar '22

//! @returns //! This function returns the line read if successful, and @tt{0@} if //! no more lines are available. Doesn't say explicitly what happens for non-EOF errors, but basically none of the functions in Stdio.File and its derivates throw exceptions on I/O errors, instead they return some kind of failure code (typically zero) and set errno. (Not that I think that's a particularly good way to handle errors, but that's how it is. It's a bit connected with the lack of a good exception system, which has been discussed in another thread recently.) > I don't know anything about TLS.. Do you have an example somewhere ? Protocols.HTTP.Query uses it for https. It's the SSL module and you'd use SSL.sslfile which is an Stdio.File lookalike. / Martin Stjernholm, Roxen IS Previous text: >2003-10-09 08:47: >Subject: Re: bugs and pop3 >-------------------------------------------------------------------- >> Some comments on the pike code: >> o Maybe combine send_user and send_password to one function? Or is it >> useful to do one without the other? > >Mmmh no, one isn't usable without the other. > >> o This looks bogus: >> >> do >> { >> recv = socket->gets(); >> } >> while(!recv); >> >> Doesn't it hang the process if an I/O error occurs there or if the >> server has closed the connection? > >I thought that socket->gets() would throw an error, thus breaking the loop. >Isn't it the case ? What is the behaviour of gets() when an error occurs ? > > >> o Fix support for encryption over TLS (aka SSL)? >I don't know anything about TLS.. Do you have an example somewhere ? > >> o Fix an asynchronous mode using callbacks? >Is it useful ? pop3 seems synchronous to my mind... there's no reason to >ask a list of messages and do anything before having that list.. > >I agree with the other comments. >Vincent. > > > / Brevbäraren >

1 0

None
by None 08 Mar '22

08 Mar '22

match with yours... / Jonas Walldén Previous text: >2003-09-23 01:16: >Subject: Re: wish: string with other quoting then \ >-------------------------------------------------------------------- >>I'm talking about Unix diff command. Of course it would report a diff >>on the #charset line but that doesn't really help at all if there's a >>0xA4 character on line 4711 in both versions since diff doesn't know >>its interpretation varies with the charset. > >Well, if you do > >|#define EURO "\xa4" >| >|"blabla" EURO "blabla" > >and then change the #define of EURO to "\x2122", diff will only report >a change on the #define line, since diff doesn't know that the >interpretation of EURO varies with the #define. Is this also a >problem? > > >>The gotcha was that you pointed to a ISO-8859-x encoding where Euro >>was included, but I now revised the example in 10728746 to use >>"\x2122" instead. > >Then I can point you to e.g. iso-8859-supp instead. Or windows-1252 >(already mentioned by yourself), macintosh (should be familiar to you >:) etc. > > >>Regardless, I'd rather see a discussion on the #multiline syntax than >>this sub-topic. If you still don't understand the example I can live >>with that. > >If that is the case it is probably just because your examples have no >connection whatsoever with reality. :-) > >My view on #multiline syntax is as before: #%blabla >blabla% where % can be picked semi-arbitraily and no escapes are >recognized in blabla. > > / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >

1 0

None
by None 08 Mar '22

08 Mar '22

begin with, but now when it is it's not unreasonable that 0.0 should be false too. / Martin Stjernholm, Roxen IS Previous text: >2003-09-14 09:19: >Subject: float type weirdness >-------------------------------------------------------------------- >Hi, > > I was surprised that float type is somewhat "special", like here: > > float x = 0.0; // OK, I can live with the fact that I just can't assign "0" :) > // However, it would be convenient to make an exception for this > // special case (zero) > > if (!x) > something(); // Will be never called, since x is _always_ true > // while it is (numerically) is zero (7.4.20) > > Is this intentional? According to the tutorial: > > "When Pike encounters an if statement, it first calculates the value of > the expression. Pike then checks if this value is true or false. The value > zero (0) is considered to be false, and everything else is true." > > It is not mantioned that "zero" has to be integer zero, and everywhere else > (C, Perl etc) float zero is false. > >Regards, >/Al > > > / Brevbäraren >

1 0

None
by None 08 Mar '22

08 Mar '22

If so can you change the dates on the Pike annoucment ? Regards, -- David Gourdelier

1 0

None
by None 08 Mar '22

08 Mar '22

| The glibc version of struct tm has additional fields | long tm_gmtoff; /* Seconds east of UTC */ ...so I'd say it's a (g)libc issue. Try the Calendar module which should calculate the right thing, | > Calendar.now()->utc_offset(); | (1) Result: -7200 / Mirar Previous text: >2003-05-06 11:50: >Subject: localtime >-------------------------------------------------------------------- > Hi, > >I have a problem with Pike 7.2 and localtime. It looks like it returns >different values on two machines: > >On one running FreeBSD (other poeple have the same results with >Debian) from pike compiled from source: > >$ date >Tue May 6 11:41:00 CEST 2003 >$ date -u >Tue May 6 09:41:02 UTC 2003 >$ pike >Pike v7.2 release 340 running Hilfe v2.0 (Incremental Pike Frontend) >> localtime(time()); >Result: ([ /* 10 elements */ > "hour":11, > "isdst":1, > "mday":6, > "min":33, > "mon":4, > "sec":54, > "timezone":-7200, > "wday":2, > "yday":125, > "year":103 > ]) > >On a Debian woody from the pike package: > >$ date >Tue May 6 11:41:04 CEST 2003 >$ date -u >Tue May 6 09:41:05 UTC 2003 >$ pike >Pike v7.2 release 340 running Hilfe v2.0 (Incremental Pike Frontend) >> localtime(time()); >Result: ([ /* 10 elements */ > "hour":11, > "isdst":1, > "mday":6, > "min":34, > "mon":4, > "sec":1, > "timezone":-3600, > "wday":2, > "yday":125, > "year":103 > ]) > >The problem is in the timezone value (3600 and 7200). > >Do you have any ideads ? > >Thank you for your answers. > >-- > David Gourdelier > > > > / Brevbäraren >

1 0

Jump to page:

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