Roughly six months (on normal par, but double the time I'd like to see) after the first 7.8 release here is the first 7.8 update: 7.8.292 beta. Users and developers alike are encouraged to test this beta and report problems so we can have a final release as soon as possible.
The source can downloaded here:
http://pike.ida.liu.se/pub/pike/beta/7.8.292/Pike-v7.8.292.tar.gz
A Windows binary might show up tomorrow.
Changes since Pike 7.8.116 (initial 7.8 release): ----------------------------------------------------------------------
General -------
o Sql.pgsql: - Substantial documentation improvements.
o Stdio.Fd_ref is deprecated and in the process of being eliminated. You have never used it before, so don't start using it now.
Bugfixes --------
o Fixed bug in AGGR_ARR_EPILOGUE() (aka END_AGGREGATE_ARRAY()) that caused the empty array to always be returned if there were no unaggregated elements on the stack at END_AGGREGATE_ARRAY.
You are encouraged to upgrade just for this fix since the bug creates very rare but (seemingly) random occurances of empty arrays.
o Fixed multiset_delete_node to work with destructed indices. This fixes occasional bugs in various functions when there are destructed objects in indices.
You are encouraged to upgrade just for this fix since the bug creates (seemingly) random crashes that are hard to reproduce and track down.
o Fixed bug in the Odbc module on WIN32 where it would fail for some field-types with the error "22003:Numeric value out of range".
o Sql.pgsql: - Various small fixes and performance improvements. - Fixed fully transparent UTF8/Unicode/wide string/character set support. - Fixed formatting errors in error().
o Fixed bug when seeking backwards in Gz.File.
o Fixed bug in fd_stat on windows when used on a file system with a long name.
o Fixed off-by-one bug in Stdio.Readline that caused a space in the last column to disappear instead of being converted to a linefeed when word wrapping is used.
o Fix bug in FakeFile.read() Replaced the broken-in-multiple-ways implementation by something that actually works (hence the original enlightnening description: "fixed a bug", there is really no concise way to classify this level of brokenness).
o Image.TIFF: Fixed memory leak on OOM.
o Fixed crash bug in Fixed core-dump typo in yyexplain_not_implements().
o LysKOM.ProtocolTypes: Bugfix of LocalToGlobalBlock
o Protected Pike_fatal() against the risk of hanging on mutexes.
o Added 7.6 compat versions for RegGet{Value{,s},KeyNames}().
o Fixed memory leak in Image.Colortable.
o Parser.SGML: Reinstated the class as Parser.SGML(). It inadvertedly became Parser.SGML()->SGML() in the move to a separate file. Parser.SGML.SGML is kept as a compatibility alias.
o Added Pike 7.6 and earlier compat for store_constant(UNDEFINED).
o Fixed race-condition causing "Lost track of child" on pikes compiled --without-threads.
o Regexp.PCRE: Do not match the empty string past the end of the input.
o Reduced the risk of throwing out-of-stack errors while formatting an out-of-stack backtrace.
o Fixed bug that would cause sprintf's %nH to refuse all strings as too long for some values of "n" on some architectures.
o Made Process.search_path() aware if Win32 and AmigaOS specifics.
o Fixed bug in Protocols.HTTP.Query that dropped the last byte of a request if the server did not provide a Content-Length header.
Optimizations -------------
o Fixed Filesystem._Tar.ReadFile to not gobble the whole tar entries into memory at once.
o Improve performance of get_cpu_time() on OS X by avoiding a kernel trap to get the ID of the underlying system thread.
o Throttle calls to task_info() on OS X since they are quite expensive. This gives a significant performance boost (>10%) on CPU-intensive applications.
Extensions and New Functions ----------------------------
o Added support for specifying modifiers via a mapping to '*' in sprintf().
See the documentation for details.
This support is detectable by checking for String.__HAVE_SPRINTF_STAR_MAPPING__
o Added support for generating little-endian floats with %F in sprintf().
This support is detectable by checking for String.__HAVE_SPRINTF_NEGATIVE_F__
o Sql.Sql now supports NULL values for %s-parameters.
o Timeout support in win32 threads.
o Made FakeFile() support getchar/gets/unread.
o Added option to chown and utime that makes it possible to change the symlink instead of the target of the link.
o function_name() now knows how to adjust the names of named lambdas.
o Changed handling of POLLHUP for poll devices, it is now signalled on all of the callbacks.
o Updated timezone data to tzdata2009c.
o Added some support for the TIMESTAMP and INTERVAL datatypes to Oracle module.
New modules / classes / methods added -------------------------------------
o Protocols.IPv6
Helpers for IPv6 related things. This currently only contains tools to parse and normalize addresses. (Not much more is necessary since the usual I/O interfaces support IPv6 as-is.)
o Added Filesystem._Tar.extract to be able to extract many/all files in a reasonably efficient way.
o Added Parser.Tabular It provides a flexible yet concise record-description language to parse character/column/delimiter-organised records.
o Calendar.YMD.http_time() that knows how to handle dates according to HTTP 1.1 (RFC 2616).
o Added support for GTK2 get_window() and get_pixmap().
Building and installing -----------------------
o Use the #-character as prefix and suffix for placeholders in master.pike.in instead of the currency sign, to avoid 8-bit character encoding issues.
o Improved support for version bumping via both Subversion and git.
o A recent stable Pike (7.8.116+) is now required to do a "make export".
o The win32 installer now removes the generated master.pike on uninstall.
I was trying to create a new module, and I got this:
[riffraff@hobbes G3Object]$ pike -x module ** Old style module ** Running autoconf (with extra compat macros) autoconf --include=/usr/local/pike/7.8.8/include/pike
What does "Old style module" mean? What should I do to make it a "New style module"?
Thanks
/lsd
I think "old style" is probably a misnomer. Support was added in 7.8 for a way to create very simple c modules without having to use the standard Pike module build system.
Note that this simplified method is not appropriate for creating modules that you want to distribute, and doesn't provide most (any?) of the functionality baked into the standard module makefiles.
Some additional information is included in the changes file... just try not to think of "old style" as equating to "outdated", as it doesn't.
Bill
On Tue, 9 Jun 2009, Lance Dillon wrote:
I was trying to create a new module, and I got this:
[riffraff@hobbes G3Object]$ pike -x module ** Old style module ** Running autoconf (with extra compat macros) autoconf --include=/usr/local/pike/7.8.8/include/pike
What does "Old style module" mean? What should I do to make it a "New style module"?
Note that this simplified method is not appropriate for creating modules that you want to distribute, and doesn't provide most (any?) of the functionality baked into the standard module makefiles.
You can use it if you feel like it, it supports running configure etc.
There is a very big problem with using the 'non-simplified' method, though:
It does not work if pike is insalled using a binary package, unless that package was compiled in an identical environment to yours (including the location of and version of libgcc etc).
The reason is that it uses the configure test results that were gotten when running the pike configure. Those are rather likely to be wrong unless you installed pike from source.
can you elaborate on this?
what about pike packages for linux distributions? those usually use the same kind of system to build the package that the end user installs. so the configure tests should all be the same unless the user makes non-standard changes to the system (or is missing some packages, which could be solved by depending on those in the pike devel component)
greetings, martin.
can you elaborate on this?
Sure.
what about pike packages for linux distributions? those usually use the same kind of system to build the package that the end user installs. so the configure tests should all be the same unless the user makes non-standard changes to the system (or is missing some packages, which could be solved by depending on those in the pike devel component)
Well. Usually (if you assume debian) you can't compile any external modules using those at all, since the path names ending upp in specs.in and dynamic_module_makefile does not match the path names the files are actually installed to.
But, anyway, the pike configure tests tests how to build pike, on the current system, with the currently installed packages. Changing which packages are installed (say, changing compiler version, or adding a new include/lib directory) can break things.
The 'new' system assumes that you write your own configure tests, if needed.
Adding a set of default tests somewhere might help people, of course.
The old system remembers the exact flags to use when calling gcc/link, and assumes smartlink is used.
There is simply much less magic going on with the new system. I very much prefer that, since my external modules (using the new system) now tend to actually compile and install correctly.
On Tue, Jun 09, 2009 at 06:15:43PM -0400, Bill Welliver wrote:
Note that this simplified method is not appropriate for creating modules that you want to distribute, and doesn't provide most (any?) of the functionality baked into the standard module makefiles.
can you explain why these modules can not be distributed?
if the 'old system' can not be used on any machine except those with the same setup as the original, how can modules from that system be distributed any better?
greetings, martin.
can you explain why these modules can not be distributed?
if the 'old system' can not be used on any machine except those with the same setup as the original, how can modules from that system be distributed any better?
There is really not all that much of a difference as far as portability is concerned.
The problem is that the old style is often not portable to the computer you are writing the code on, since your installation might have changed since pike was installed.
The new style requires you to write your own configure tests (you can use the PIKE_INSTALL_DIR and such to include aclocal.m4 from pike, if you really want to, but there are not all that many relevant tests to reuse in there currently, the C-compiler tests, perhaps, but AC_PROG_CC works just fine usually)
i get what you are saying, i am just confused why bill seems to claim that 'new style' modules can not be distributed at all...
i can understand things depending on the state of the system while building, but as you say that is the same for both styles. (and not really a problem for packaging modules for linux distributions since the state of the system is in the distributors control for the most part.)
greetings, martin.
It's quite simple, really. The "old style" build system uses the bundled dynamic_module_makefile and friends, which is the way that modules are built when compiling Pike. They include a large number of support targets and utilities that simply aren't present when writing a "new style" module. The external module distribution system relies on that support framework (and the consistency of the behavior it provides).
I'm not suggesting that "new style" modules aren't simpler to create. But, I also don't think that "old style" modules are really any more difficult if you have a stub module to work from. Indeed, if I had to start from an empty module directory, I'd probably think that new style modules were harder.
I also don't see why an "old style" module should build any less reliably than a new style one. The only problems I've ever had were either due to a developer breaking the build system (happens at least once each development cycle, due to the fact that external building is the last thing on anyone's mind at the time) or because there's a stale set of files on disk.
Just my 2 cents.
Bill
On Wed, 10 Jun 2009, Martin Baehr wrote:
i get what you are saying, i am just confused why bill seems to claim that 'new style' modules can not be distributed at all...
i can understand things depending on the state of the system while building, but as you say that is the same for both styles. (and not really a problem for packaging modules for linux distributions since the state of the system is in the distributors control for the most part.)
greetings, martin.
I think the core issue here is separating the defines and flags that belong to the pike ABI, which should be distributed with Pike, and those that belong to the rest of the compilation environment, which should not.
The "old style" distributes too much. What the "new style" does I don't really know, but a particularly tricky area is all the defines in machine.h. It is a mixture of stuff that defines the ABI (e.g. INT_TYPE, DO_PIKE_CLEANUP, PIKE_DEBUG) and results from ordinary configure tests (e.g. HAVE_*). How does the "new style" handle this?
----- Original Message ---- From: "Martin Stjernholm, Roxen IS @ Pike developers forum" 10353@lyskom.lysator.liu.se To: pike-devel@lists.lysator.liu.se Sent: Wednesday, June 10, 2009 2:00:06 PM Subject: Re: pike -x module
I think the core issue here is separating the defines and flags that belong to the pike ABI, which should be distributed with Pike, and those that belong to the rest of the compilation environment, which should not.
The "old style" distributes too much. What the "new style" does I don't really know, but a particularly tricky area is all the defines in machine.h. It is a mixture of stuff that defines the ABI (e.g. INT_TYPE, DO_PIKE_CLEANUP, PIKE_DEBUG) and results from ordinary configure tests (e.g. HAVE_*). How does the "new style" handle this?
------------
Is there an example I should follow for the new style? Or just stick with the old style? I'm going to be writing a C module (not a cmod).
The only example for the "new style" modules is in the changes file (I'll include it below). If you're planning on distributing the module, such as with monger, the new style isn't really a viable option. I think the wording in the changes file is somewhat misleading, as the new module style doesn't really replace the old style for one of the most common scenarios (distributing a module).
There's a stub "old style" module available; you just need to change a few fields in the makefile and edit the configure script.
SVN address:
http://wush.net/svn/hww3/trunk/pike_modules/SampleModule
Bill
-- CUT --
It's now suggested that you do not use the fairly complex 'pike internal' style of external modules (configure.in with AC_MODULE_INIT etc).
It's also no longer required that you have a configure script to use pike -x module.
Instead simply locate the include files using 'pike -x cflags', and convert .cmod to .c files using 'pike -x precompile'.
An example rather minimal 'pike -x module' compatible Makefile, without a configure script, using .cmod format files for a simple local module:
| CC=gcc | CFLAGS := -O9 -fweb -shared -Wall $(CFLAGS) $(shell $(PIKE) -x cflags) -g | LD=$(CC) -shared -lGL | | all: Spike.so | | install: Spike.so | cp $< $(MODULE_INSTALL_DIR) | | Spike.so: Spike.o | $(LD) -o Spike.so Spike.o $(LDFLAGS) | | Spike.o: Spike.c | | Spike.c: Spike.cmod | $(PIKE) -x precompile $< > $@
It's usually OK not to use pike -x module at all, but it will pass on a few extra variables to your make (and configure script):
PIKE: How to start the pike interpreter used running pike -x module MODULE_INSTALL_DIR: Where modules goes LOCAL_MODULE_PATH: Alternative (user local) module location
On Wed, 10 Jun 2009, Lance Dillon wrote:
Is there an example I should follow for the new style? Or just stick with the old style? I'm going to be writing a C module (not a cmod).
In the last episode (Jun 10), Bill Welliver said:
The only example for the "new style" modules is in the changes file (I'll include it below). If you're planning on distributing the module, such as with monger, the new style isn't really a viable option. I think the wording in the changes file is somewhat misleading, as the new module style doesn't really replace the old style for one of the most common scenarios (distributing a module).
-- CUT -- An example rather minimal 'pike -x module' compatible Makefile, without a configure script, using .cmod format files for a simple local module:
[...]
| install: Spike.so | cp $< $(MODULE_INSTALL_DIR)
[...]
| Spike.c: Spike.cmod | $(PIKE) -x precompile $< > $@
Note that using $< in target rules is not portable (it's only allowed in inference rules). Better to replace it with the source filename:
| install: Spike.so | cp Spike.so $(MODULE_INSTALL_DIR) [...] | Spike.c: Spike.cmod | $(PIKE) -x precompile Spike.cmod > $@
As mentioned, it works just fine to have a configure.in etc with the new style modules.
The example is specifically for an intentionally simple non-portable module (and I even thing it's mentioned in there).
foresight gnu/linux package is now here: pike=/embee.rpath.org@fl:2-devel
the package is still missing docs but otherwise appears functional.
(hmm, is there a way to run the testsuite on an installed pike?)
greetings, martin.
On Wed, Jun 10, 2009 at 09:45:02AM +0000, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
(hmm, is there a way to run the testsuite on an installed pike?)
You could use "pike -x test_pike", but note that the actual tests are normally not installed.
well, that can be arranged :-) picking the tests from the source should not be a problem, and i don't mean for everyone to run those tests, just for packagers, to make sure the package is not missing anything. (the test while building could run fine after all, but then something could go wrong in the packaging step)
on the other hand, having the tests available in the package would make them more accessible to end users as examples how to make their own tests...
greetings, martin.
Well, regardless of whether you create a package to install the tests in a some standard location, or whether you just use the source tree, you'll need to point test_pike at the correct directory using "pike -x test_pike -a /path". The default directory to look in is "." I'm afraid.
sure, that's not a big deal. and it's nothing a small script couldn't fix if someone would like to this to be easier.
having the testsuite in the installed pike certainly feels like it being more accessible for me despite having a checkout of the source tree, since the tests in the source tree don't work without compiling pike from that tree. (which i never do because i use pikefarm (and now the packages) for that.
the packaged testsuite gives me 44 failed and 151 skipped tests out of 48119 due to some files missing from the source tree. trying to get that down to 0...
greetings, martin.
hi,
nettle 2.0 has just been released. should we go ahead and build the new stable pike against it, or are there any reasons to avoid that?
greetings, martin.
First go ahead and make the Nettle module work against the new API (based on configure test of course).
Pike doesn't benefit from any 2.0 features (functionality separation), so there's no rush yet. But if someone could have a look at what would needs to be fixed to hook up the new API that would be good.
ok, if there is no immideate benefit then it's not worth it to upset the current release with the changes needed. it would be good enough as a target for the next stable release.
greetings, martin.
I won't have that as a target actually, but please fix it regardless. :-)
New beta build, 7.8.292:
http://pike.ida.liu.se/pub/pike/beta/7.8.296/Pike-v7.8.296.tar.gz
Changes since yesturdays build are:
o Fixed overzealous filtering of the value returned from Stdio.File()->mode(). This bug caused Stdio.nb_sendfile to always run in blocking mode.
You are encouraged to upgrade just for this fix since the bug can cause supposedly nonblocking actions to block and hang the script.
Windows build also available today:
http://pike.ida.liu.se/pub/pike/beta/7.8.296/Pike-v7.8.296-win32.msi http://pike.ida.liu.se/pub/pike/beta/7.8.296/Pike-v7.8.296-win32.info
It starts, not tested much beyond that. Has GTK2, GL, Mysql, Postgres and SQLite support, but lacks SDL, Freetype and JPEG support.
Kick it a bit and see if it remains standing.
No Java. This machine is newly installed and I forgot that detail. I'll try to fix that for the next build.
New beta build, 7.8.300:
http://pike.ida.liu.se/pub/pike/beta/7.8.300/Pike-v7.8.300.tar.gz
Changes since yesturdays build are:
o Fixed bug in Protocols.HTTP.AsyncClient that made alla data decoding fail. Fixed by Thomas Gusenleitner earlier today.
No Windows build today.
I quite like this build number, so try not to break it.
Yes, that was a regression due to an attempt to use the new range syntax in the function.
I installed pike 7.8.337 from source and encountered a problem again. When compiling a cmod using pike -x module, pike is looking for precompile.pike in
/opt/pike/7.8.337/include/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
even though it is in
/opt/pike/7.8.337/lib/modules/Tools.pmod/Standalone.pmod/precompile.pike
I usually fix it by putting a symlink into the include dir, but maybe this is something that can be fixed in the build process itself...
arne
Um, isn't [..<datapos+len] supposed to be the same as [..datapos+len-1]? And why was < just removed in the debug printouts, without subtracting the one?
No, X[..<datapos+len] is X[..sizeof(X)-(datapos+len+1)].
Ok, what was the syntax we invented for exclusive ranges then? The problem with X[..datapos+len-1] is that you get the wrong result when datapos == len == 0.
No you don't. sizeof(X[..-1]) == 0.
Ok, I'm officially confused. Doesn't negative indices count from the end?
pike-devel@lists.lysator.liu.se
-
Arne Goedeke -
Bill Welliver -
Dan Nelson -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Lance Dillon -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Baehr -
Martin Bähr
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum