Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3040 discussions

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

None
by None 08 Mar '22

08 Mar '22

(CUT0) (CUT0GDT) Coordinated Universal Time (CUT) (GMT0) (GMT0BST) United Kingdom (CUT) (AZOREST1) (AZOREST1AZOREDT) Azores; Cape Verde (CUT -1) (FALKST2) (FALKST2FALKDT) Falkland Islands (CUT -2) (GRNLNDST3) (GRNLNDST3GRNLNDDT) Greenland; East Brazil (CUT -3) (AST4) (AST4ADT) Central Brazil (CUT -4) (EST5) (EST5EDT) Eastern U.S.; Colombia (CUT -5) (CST6) (CST6CDT) Central U.s.; Honduras (CUT -6) (MST7) (MST7MDT) Mountain U.s. (CUT -7) (PST8) (PST8PDT) Pacific U.s. Yukon (CUT -8) (AST9) (AST9ADT) Alaska (CUT -9) (HST10) (HST10HDT) Hawaii; Aleutian (CUT-10) (BST11) (BST11BDT) Bering Straits (CUT-11) (NZST-12) (NZST-12NZDT) New Zealand (CUT+12) (MET-11) (MET-11METDT) Solomon Islands (CUT+11) (EET-10) (EET-10EETDT) Eastern Australia (CUT+10) (JST-9) (JST-9JDT) Japan (CUT +9) (KORST-9) (KORST-9KORDT) Korea (CUT +9) (WAUST-8) (WAUST-8WAUDT) Western Australia (CUT +8) (TAIST-8) (TAIST-8TAIDT) Taiwan (CUT +8) (THAIST-7) (THAIST-7THAIDT) Thailand (CUT +7) (TASHST-6) (TASHST-6TASHDT) Tashkent; Central Asia (CUT +6) (PAKST-5) (PAKST-5PAKDT) Pakistan (CUT +5) (WST-4) (WST-4WDT) Gorki; Central Asia; Oman (CUT +4) (MEST-3) (MEST-3MEDT) Turkey (CUT +3) (SAUST-3) (SAUST-3SAUDT) Saudi Arabia (CUT +3) (WET-2) (WET-2WET) Finland (CUT +2) (USAST-2) (USAST-2USADT) South Africa (CUT +2) (NFT-1) (NFT-1DFT) Norway; France (CUT +1)

1 0

Pike 8.0 release 15 (8.0.1738) now available
by william＠welliver.org 01 Mar '22

01 Mar '22

Hello, Friends of Pike! The Pike development team is pleased to announce the 15th release of Pike 8.0: build 8.0.1738. I’m in the process of submitting updates for homebrew and pkgsrc, so the new version should appear there in the near future. As always, bug reports, comments and suggestions are welcome! Bill ---- Source: https://pike.lysator.liu.se/pub/pike/all/8.0.1738/Pike-v8.0.1738.tar.gz Binary builds: https://pike.lysator.liu.se/download/pub/pike/all/8.0.1738/ RPMs for RHEL/CentOS: https://pike.lysator.liu.se/download/pub/pike/all/8.0.1738/el6 https://pike.lysator.liu.se/download/pub/pike/all/8.0.1738/el7 https://pike.lysator.liu.se/download/pub/pike/all/8.0.1738/el8 Windows Installer: https://pike.lysator.liu.se/pub/pike/all/8.0.1738/Pike-v8.0.1738-Windows7-x… Changes since Pike 8.0.1116 (release 14) New Features ------------ o Calendar Updated to use tzdata2021e. o Parser.XML.Tree Added set_text() to update the contents of a text node. o Sql.Sql Add query_db() to API. o SSL.SSLFile Add {query,set}_timeout(). This adds an API to set an optional timeout to be used for blocking operations. When the timeout expires it is handled as if the peer sent a fatal internal error alert. o Standards.PEM Added helper methods, including: get_certificates() , get_private_keys(), get_private_key() and decrypt_fragment(). o Runtime and EFUNS - describe_backtrace() now reports cpu time --with-profiling. - decode_value can be called with codec -1, which disables decoding of functions, objects, programs and types. Bug Fixes --------- o crypt Fixed a bug which caused crypt() with a random salt to sometimes return "*0" instead of an encrypted password. o Concurrent - The future generated by ->timeout() would not necessarily resolve with the fullfilled or rejected values if the original Promise/Future was resolved or rejected before hitting the timeout. - If the original promise resolves or rejects, we now attempt to unschedule the timeout call_out from the backend we scheduled it in, not the one (now) configured in the Future. o Critbit - Fix a number of memory and behavior errors. o Inotify add_watch() now returns -1 for filsystem-related failures that may be due to the filsystem being in flux. o Image.BMP Improved size check better detects malformed BMP images. o Image.GIF - Improve detection of malformed LZW bit sizes. - Improve detection of malformed LZW dictionary extensions. o Image.ILBM - Guard alloca() allocations with check_c_stack(). - Improved length accounting in unpackByteRun1(). o Image.JPEG - Do not over-allocate memory for decoded image. - Limit decoded size of images to 2 GB. o Image.PCX Improved size checks better detect malformed PCX images. o Image.PNG Improved size check better detects malformed PNG images. o Image.PSD Improved size check better detects malformed PSD images. o Image.TGA - Improve detection of malformed TGA images. - Correctly update pointer when horizontal or vertical flipping is requested by the TGA image. o Image.TIFF Improved size checks in image decoding o Image.TIM Improved size checks better detect malformed TIM images. o Image.WBF Improved size check better detects malformed WBF images. o Image.X Guard alloca() allocations with check_c_stack(). o Image.XCF Fixed to properly initialize the layer mask structure. o Image.XWD Improved size check better detects malformed XWD images. o Protocols.LDAP.client LDAP connections secured with TLS/SSL now timeout if the server does not respond within 10 seconds. o Sql.mysql Improved character set handling o Sql.pgsql Numerous bug fixes. Building & Tools ---------------- o Improved check for stack direction to also report correct results when compiling with Clang 11. o _TIME_BITS is now set to 64, to get a 64-bit time_t on 32-bit systems running glibc 2.34 or newer. o Improvements to building and installer code signing on macOS. o Fixes to better support building with future versions of GNU make. o Use updated FFI API in Java module, to better support recent libffi. o Fix testsuite generation for BSD m4 users; POSIX systems must continue to use GNU m4 (gm4).

1 0

Pike 8.0.1738 ready to release
by william＠welliver.org 28 Feb '22

28 Feb '22

Hello all- I've prepared, tested and uploaded dependency-included installs of the latest 8.0 release for the following platforms: - Windows 7 32-bit - MacOS 10.9+ 64-bit (Intel) - MacOS 10.12+ 64-bit (Intel) [1] - MacOS 12+ (Monterey) 64-bit (ARM) [2,3] If anyone wishes to test these builds or upload additional platforms, please feel free. If there are no complaints in the next 2-3 days, I'll make an official announcement. I also plan on starting the process to have the pike port for pkgsrc promoted from wip to official soon. Please feel free to get in touch with any questions or comments. Thanks! Bill [1] Pike (Intel) seems to run happily under Rosetta 2, and Big Sur (11.0) does not support virtualization, making a dependency-free build difficult. [2] assembly for Nettle has been disabled due to compilation problems. [3] Mysql does not include support for TLS because MacOS no longer ships with OpenSSL, and the security nightmare of having a bundled version seemed not worth it. Use homebrew if TLS support is required.

5 5

Pike 8.0 beta 8.0.1738
by H William Welliver 01 Feb '22

01 Feb '22

Hello all- I’ve prepared a new 8.0 beta release and have uploaded it to: http://pike.lysator.liu.se/pub/pike/beta/8.0.1738/Pike-v8.0.1738.tar.gz This release is more or less green across the board. I’d like to get some feedback on binary builds, so if anyone has more than one system alike, I’d be appreciative if you could do a make bin_export and then test the result somewhere else. Any comments or problem reports are welcome… if I don’t hear any complaints in the next week or so, I’ll announce this as an official stable version and start trying to remember how I did the last windows build :/. Thanks in advance! Bill

2 1

mktestsuite and m4
by william＠welliver.org 25 Jan '22

25 Jan '22

I've traced down some problems running the testsuite on systems that ship with a non-gnu m4. Specifically, mktestsuite calls m4 with the "-d" argument. Using gm4, the lack of flags implies the a,e and q flags. On BSD m4, the "-d" argument /requires/ flags, though the flags themselves are the same as GNU m4. POSIX/Solaris/illumos m4 doesn't support the debug argument at all. Looking at mktestsuite, it tries to determine whether it's using GNU m4, and will prefer (but not require it) it should it find one. Once it's chosen the m4 binary, it seems to assume that GNU options are acceptable. Since that doesn't work, I'm wondering what the preferred ought to be: 1. require GNU m4 2. just use the full -d argument and hope (solaris/etc) users will figure out they need gm4 3. try to detect what sub-flavor of non-GNU m4 is being used I don't recall the last time I ran across a solaris system without the gnu build tools. I'd be inclined to take option 2 since it shouldn't break anyone and will improve the situation for some. A more elaborate solution could be considered if some POSIX purists complain later. Thoughts? Bill

2 1

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

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