Pike-devel January 2004

pike-devel@lists.lysator.liu.se

11 participants
77 discussions

sslfile
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 28 Jan '04

28 Jan '04

After the rewrite of SSL.sslfile some methods available before are gone. Is that a mistake in terms of removal or in terms of not adding compatibility?

1 0

win32 builds
by Peter Bortas ＠ Pike developers forum 28 Jan '04

28 Jan '04

If someone feel they don't have enough exitement in their lives feel free to test <URL:http://peter.bortas.org/pikedev/Pike-7.4.35beta-win32-bhelliom.exe> or <URL:http://peter.bortas.org/pikedev/Pike-7.5.17alpha-win32-bhelliom.exe> They are totally untested and only intended for testing some changes to the installation package: * ICON rescource in pike.exe * New installer icon * Added possibility to use 10 instead on 1 argument to pike.exe on the command line. * Fixed up my win32 compileation environment again. Observe: I haven't even tried to run these executables since my win32 testing system is currently spread all over my workbench. Feel free to report back if it does work though.

3 17

Re: Pike @ Debian
by Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

Hm. Marek, if I just made an ass of myself by assuming you just took some quarantine time off the list, and thus incorrectly addressed you in third person like this, I'm sorry. (For which I whole-heartedly put all blame on Embee's sudden recurring diversion tactics, in a not very successful effort at humour on my part. Got to practice some more. :-)

3 3

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

Then they simply won't work in Pike 7.5. If you had used pike -x module you would have got the .pmod files for free. / Per Hedbor () Previous text: >2004-01-26 21:41: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:35:07PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Even pure C-modules generate .pmod files nowdays. Which is what I >> wrote, I think. >None of the pexts, caudium or php4 modules do. What's your point? > >marek > > > > / Brevbäraren >

2 1

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

No, we do not ignore external modules. But the current aclocal.m4 does not have anything to do with what you want (pike.m4 for automake/aclocal). Thus it's not sensible to 'clean it up' and install it as such. Writing a pike.m4 would, however, make sense. / Per Hedbor () Previous text: >2004-01-26 22:18: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:45:04PM +0100, Niels Möller (vässar rödpennan) @ Pike (-) developers forum scribbled: >> >Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >> >both the pike's aclocal.m4 and other files with, possibly, macros that are >> >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >> >enough to cope with it ;) >> >> I think you're confusing several things here. Autoconf, automake, the >> aclocal program (more or less a part of automake), and the aclocal.m4 >> file are not all used together and are not using the same conventions. >Believe or not, but I'm quite aware of that. Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? > >> aclocal.m4 existed long before automake, and it plays the same role >> that acinclude.m4 plays in automakeified projects. It's a >> *handwritten* file included by autoconf, specific to the project being >> built. >Again, I'm quite aware of the fact. > >> The aclocal proram is a later invention that constructs an aclocal.m4 >> file from various fragments stored somewhere under share. >You haven't surprised me here, either. > >> Pike uses autoconf, and uses aclocal.m4 the the way it was intended >> when autoconf was first written. It does *not* use automake, and it >> does *not* use the aclocal program. It's aclocal.m4 is *not* intended >> to ever be picked up by the aclocal program. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? > >> So the main poitn here is that any debian policy that has to do with >> automake and the aclocal program is totally irrelevant to pike. >Of course it isn't. But it might be relevant to external Pike modules. But >you're determined to ignore them, right? > >marek > > > > / Brevbäraren >

6 7

Re: pike -x testing
by Martin Nilsson (saturator) ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

[nilsson@mahoro 7.5]$ pike --version Pike v7.5 release 17 Copyright © 1994-2004 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details. [nilsson@mahoro 7.5]$ pike -x Pike -x specificed without tool name. Available tools: assemble_autodoc Assembles AutoDoc output file. benchmark Runs some built in Pike benchmarks. cgrep Context aware grep. dump Dumps pike files into object files. extract_autodoc Extracts autodoc from Pike or C code. extract_locale Pike locale extractor utility hilfe Hubbes Interactive LPC FrontEnd. join_autodoc Joins AutoDoc extractions. module Pike module installer. pv Pike image viewer (diet). rsif Replaces strings in files. rsqld Implements an rsql daemon. I don't remember when it was added. Perhaps a year ago. / Martin Nilsson (saturator) Previous text: >2004-01-27 11:58: >Subject: Re: pike -x testing >-------------------------------------------------------------------- >[...] > >> I'd like to see >> >> $ pike -x >> Pike: You must provide the name of a tool. Available tools: >> >> module Build a standalone pike module. >> pv Image viewer >> bench Pike benchmark >> >> It would be nice to have the testsuite exersize all supported tools, >> and have pike -x testsuite run the testsuite. > >This should be a really good idea ! > >/Xavier > > > > / Brevbäraren >

1 0

Pike7.5-20040126-234515 snapshot(s?) "make install" porblems
by Alexander Demenshin 27 Jan '04

27 Jan '04

Hi, Again tried to compile and install (latest snapshot), verify was ok, but on install it looped at: if [ -f dumpversion ]; then make delete_dumped_modules; else :; fi /home/aldem/src/Pike7.5-20040126-234515/src/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/aldem/src/Pike7.5-20040126-234515/src/master.pike -x extract_autodoc -q --srcdir=/home/aldem/src/Pike7.5-20040126-234515/src \ --imgsrc=/home/aldem/src/Pike7.5-20040126-234515/refdoc/src_images --builddir=doc_build/src \ --imgdir=doc_build/images make: *** [autodoc.xml] Interrupt So I had to stop it (after ca. 10 minutes). The result: a _lot_ of recursively created dirs under doc_build/src. The result of strace (during execcution of this phase) was like: lstat64("/home/aldem/src/Pike7.5-20040126-234515/src/doc_build/src/doc_build/src/doc_build/.../src/tlib/modules/Languages.pmod", {st_mode=S_IFDIR|0755, st_size=48, ...}) = 0 "..." is a repetition of "doc_build/src" many times. Something is definitely wrong in install process... Is there a target to install _without_ any docs/images etc? Regards, /Al

3 5

Re: Pike @ Debian
by Per Hedbor () ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

pike -x module is a new build system. Let's generate aclocal.m4 from pike, then you would not complain about that file, right? Then we put the information in the current dynamic_module_makefile in lib/modules/Tools.pmod/Build.pmod or somthing similar. Would that be better? Note that nothing would really be differnt. But anal debian maintainers would probably be happier. Personally I think it would be pointless to do all this work for nothing, though. / Per Hedbor () Previous text: >2004-01-26 21:38: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:10:03PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled: >> Perhaps it would be better to stop using autoconf entirely. Nobody >> seems to complain about Make.pl files, so perhaps that's the way to >> go. >I would be more than happy. There's pmk and numerous other systems of >configuring software. pmk is maturing, so it might be an option in the near >feature. But then, who will convert the current build system to a new >standard? I would just hope that no pike would be necessary to generate the >makefiles > >marek > > > > / Brevbäraren >

6 8

Re: Pike @ Debian
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 27 Jan '04

27 Jan '04

>Huh? pike.m4's purpose is would be to: > > a) detect the presence of the Pike binaries on the system (or requested > components thereof) > > b) inform the application where the .h, .pmod etc. etc. files are located. Yes? In order to find the information in b) though, it need to either run the Pike binary detected in a), asking it to disclose this information (which is equivalent to the use of pike -x module today), or grope this information out in some other way. The latter solution would have to include support for all systems, packagings and installations, since the stuff from the .m4 file goes into the generated "configure" script, to be distributed together with the module. So you can't tailor the .m4 file for your own system, since the generated configure script needs to work on any system with any Pike. >How could that prevent the code from being compiled on different operating >systems??? Since when the contents of the information above matters and not >the way you get the information? If you have 10 OSes and each of them keeps >the .h files in a different location, but you have one pike.m4 which has a >macro > > PIKE_C_HEADER_FILES > >which sets the PIKE_HEADERS variable to the location of the .h files on the >system, then where is the problem? The problem was how to write the macro PIKE_C_HEADER_FILES so that the shellscript code it expands to works on all systems without resorting to running the Pike interpreter. >As said previously somewhere, the .m4 could just source a config file >put in a well-known location. That would make it extremely >configurable and flexible, not to mention simple. I'm sorry, but I don't think it's realistic to require a "well-known location" to exist in all Pike installations. Just consider users installing pike without having global write access, or ports to operatings systems with completely different pathname conventions (win32, AmigaOS, etc). pike -x module works because it only needs to follow $PATH to find everything it needs to bootstrap. You can have the Pike installed anywhere, using any directory layout (under the current limitations of the master and the Makefiles), as long as you have the intepreter binary in your $PATH. / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2004-01-26 21:32: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 08:55:02PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled: >> _No_. It can _not_ be tailored to the distribution, because then the >> Pike modules you distribute could only be compiled with that >> distrubution. That would be totally useless. >Huh? pike.m4's purpose is would be to: > > a) detect the presence of the Pike binaries on the system (or requested > components thereof) > > b) inform the application where the .h, .pmod etc. etc. files are located. > >How could that prevent the code from being compiled on different operating >systems??? Since when the contents of the information above matters and not >the way you get the information? If you have 10 OSes and each of them keeps >the .h files in a different location, but you have one pike.m4 which has a >macro > > PIKE_C_HEADER_FILES > >which sets the PIKE_HEADERS variable to the location of the .h files on the >system, then where is the problem? > >You put > >CC_INCLUDES=$(PIKE_HEADERS) > >in your makefile and your code perfectly compiles on any OS, no matter where >it keeps the files. Suspecting that you might have misunderstood the >'tailoring' part - I meant by it that the maintainer of the Pike port for a >particular system can modify it and customize for his platform. I didn't >mean it has to be done in the Pike core, all gods of the universe forbid! As >said previously somewhere, the .m4 could just source a config file put in a >well-known location. That would make it extremely configurable and flexible, >not to mention simple. > >marek > > > > > / Brevbäraren >

1 0

Re: Pike @ Debian
by Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum 26 Jan '04

26 Jan '04

>Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? I'm not sure which system-wide .m4 directory you mean. I didn't get one with the installation of either m4 or autoconf, as far as I'm aware. share/autoconf/*/*.m4 is autoconf internal files. share/aclocal is for files intended to be picked up by aclocal, and you can't even rely on it's existance unless you make pike depend on automake, which I think would be unnecessary and unfortunate. Neither is the right place for pike's aclocal.m4. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? You can use automake, but then you will not use pike -x module. And it makes no sense to have aclocal pick up the aclocal.m4 which is intended for use with pike -x. I don't know for sure that it doesn't work to do that (as I haven't tried), no matter if it ever works it's an utterly unsupported way to use that file. It's on par with including files from pike/lib/include/ into C programs. >> So the main poitn here is that any debian policy that has to do with >> automake and the aclocal program is totally irrelevant to pike. >Of course it isn't. My point is that debian automake policy should be applied only to the installation of files which are intended to be used with automake, or are in some other way closely related to automake. The pike package does not contain a single file that is intended to be used with automake; therefore automake policy is not relevant to the pike interpreter package. / Niels Möller (vässar rödpennan) Previous text: >2004-01-26 22:18: >Subject: Re: Pike @ Debian >-------------------------------------------------------------------- >On Mon, Jan 26, 2004 at 09:45:04PM +0100, Niels Möller (vässar rödpennan) @ Pike (-) developers forum scribbled: >> >Alas, it wouldn't... If some Pike C module runs aclocal it could pull in >> >both the pike's aclocal.m4 and other files with, possibly, macros that are >> >already defined in the pike's aclocal.m4 file. I doubt autoconf is smart >> >enough to cope with it ;) >> >> I think you're confusing several things here. Autoconf, automake, the >> aclocal program (more or less a part of automake), and the aclocal.m4 >> file are not all used together and are not using the same conventions. >Believe or not, but I'm quite aware of that. Let me remind you that the >proposition was to put the pike's aclocal.m4 under a different name in the >system-wide .m4 directory. Does that change your assessment? > >> aclocal.m4 existed long before automake, and it plays the same role >> that acinclude.m4 plays in automakeified projects. It's a >> *handwritten* file included by autoconf, specific to the project being >> built. >Again, I'm quite aware of the fact. > >> The aclocal proram is a later invention that constructs an aclocal.m4 >> file from various fragments stored somewhere under share. >You haven't surprised me here, either. > >> Pike uses autoconf, and uses aclocal.m4 the the way it was intended >> when autoconf was first written. It does *not* use automake, and it >> does *not* use the aclocal program. It's aclocal.m4 is *not* intended >> to ever be picked up by the aclocal program. >It does *not* mean the external Pike modules written in C _cannot_ use >automake, am I right? Or is it forbidden because Pike itself doesn't use it? > >> So the main poitn here is that any debian policy that has to do with >> automake and the aclocal program is totally irrelevant to pike. >Of course it isn't. But it might be relevant to external Pike modules. But >you're determined to ignore them, right? > >marek > > > > / Brevbäraren >

2 2

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 January 2004