Pike-devel

pike-devel@lists.lysator.liu.se

4 participants
3044 discussions

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

None
by None 08 Mar '22

08 Mar '22

It is plain obvious that there can be an infinite amount of empty strings between two whitespaces. / Peter Lundqvist (disjunkt) Previous text: >2003-04-29 02:15: >Subject: Strange? >-------------------------------------------------------------------- >Yes, and String.count(" ","") should be 3, since the empty string >occurs at three distinct positions in the string (0, 1 and 2). So I >agree with this sequence. > > / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) >

1 0

None
by None 08 Mar '22

08 Mar '22

/ Martin Nilsson (har bott i google) Previous text: >2003-04-07 08:01: >Subject: `-= >-------------------------------------------------------------------- >Making =! a new token would be stupid. No preprocessor statement in >the world can cure stupidity I'm afraid. > >Generally speaking, it's never a good idea to change something in a >backwards-incompatible way, but #pike gives us the tools to do it >in a graceful manner when deemed nessesary. I certainly prefer using >#pike to the deprecate-remove-cycle that other languages use... > >Side note: One of these days I'm going to try to run my old >roxen 1.3 with pike 7.4 using -V0.6. Expect bug reports. :) > > / Fredrik (Naranek) Hubinette (Real Build Master) >

1 0

None
by None 08 Mar '22

08 Mar '22

post, it looks like AC_PREREQ might do the trick as well. Renames are not handled well by CVS... :-) / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2003-01-09 20:01: >Subject: autoheader >-------------------------------------------------------------------- >Well, for one we can name the file configure.ac rather than >configure.in. That'll cause immediate breakage if you use autoconf >2.13 or older and would also indicate immediately to the compiling >party that autoconf 2.5x is needed (also I think many distributions >have wrapper scripts that automatically use the right autoconf >version if it sees .ac rather than .in). > > / David Hedbor >

1 0

None
by None 08 Mar '22

08 Mar '22

like any other contributor. I'd rather avoid that route simply because it makes me depend on the progress between two other parties I have no control over, and knowing all too well how things works in the real world that could easily take months. For my own sake I'd be satisfied with a simple email from Uwe saying "Ok". Then I'd consider it safe for me to add those little functions to CC Mode and therefore to FSF just like any other change I make. (. Or hey, you haven't caught on to my diabolical plan for personal profit, have you? I was sitting here in my castle cellar, watching tubes bubble in the moonlight, and all of a sudden I realized that those functions actually contains a wonderful algorithm that will provide me with endless riches and world domination if I just could scheme to get them away from IDA. So I crafted this insidious plan, adding 4000 lines of font locking code to CC Mode just to make it look believable. And like all evil masterminds I'm spilling it all to show how clever I am. .) Anyway, this issue has made me think about other things I might write. If I make a library that is intended to be used not only in Pike, I'd be inclined to keep the copyright to avoid being hampered by things like this, and then only contribute the pike glue for it. The practical effect would be little else than that the library gets a copyright notice in COPYRIGHT, wouldn't it? / Martin Stjernholm, Roxen IS Previous text: >2002-11-11 21:18: >Subject: pike.el >-------------------------------------------------------------------- >Perhaps it is better for us to talk to FSF. After all we have a fairly >substantial amount of code that might be involved in similar actions in >the future. We want our code to benefit as many as possible, but we want >to avoid FSF's political agenda. > > / Martin Nilsson (Fake Build Master) >

1 0

None
by None 08 Mar '22

08 Mar '22

PExt did not. / Johan Sundström (ärkehertig av Lysators rootgrupp) Previous text: >2002-10-16 14:48: >Subject: Re: Bzip2 (Pike C Module documentation) >-------------------------------------------------------------------- >Hm, that was what I was going to use it for... Corresponding to Gz's >SYNC_FLUSH or PARTIAL_FLUSH. I'm not sure if bzip2 can do that, but >that is what I need. > > > / Brevbäraren >

1 0

None
by None 08 Mar '22

08 Mar '22

includes one module A, linking to GPL:ed code, and another module B, linking to GPL-incompatible code, one shouldn't use both A and B in the same program. Technically, *use* is still allowed, of course, but if I distribute code that uses both A and B, I can expect the author of the GPL:ed code to be pissed at me. Do you agree with this interpretation? So one should make sure to document which modules depend on GPL:ed code (i.e. modules that require the use of the LGPL->GPL upgrade clause), and modules that depend on GPL-incompatible code (defined as code the license of which does *not* allow upgrading to the GPL). / Niels Möller () Previous text: >2002-10-08 17:55: >Subject: Split >-------------------------------------------------------------------- >No, LGPL is not OK if the code is GPL. > >We cannot have GPL or other non-LGPL/MPL compatible code in the pike >distribution (or CVS), so if they did not agree to the relicensing, >the module can not be included in Pike. > > / Per Hedbor () >

1 0

← Newer
1
2
3
4
5
6
7
...
305
Older →

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