Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

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

28 Jan '04

query_fd previously returned -1. / Martin Nilsson (saturator) Previous text: >2004-01-28 19:35: >Subject: Re: sslfile >-------------------------------------------------------------------- >What methods, specifically? I know that die() is one of them... > >Bill > >On Wednesday, January 28, 2004, at 12:30 PM, Martin Nilsson (saturator) >@ Pike (-) developers forum wrote: > >> 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? > > > > / Brevbäraren >

1 0

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 26 Jan '04

26 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 26 Jan '04

26 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

Jump to page:

2026

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