Pike-devel July 2010

pike-devel@lists.lysator.liu.se

7 participants
19 discussions

pike7.8 7.8.352-dfsg-2
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 16 Aug '10

16 Aug '10

I've finally uploaded pike 7.8 to unstable (despite the failure to dump dump.pike). The documentation handling will also have to wait. The set of meta packages is unchanged. Changes since 7.8.352-dfsg-1: * Add trigger for dumping of Pike modules when pike7.8-core or any module package is installed. * Remove support for the unversioned local module and include directories (/usr/local/lib/pike/*) to avoid having to coordinate their creation and removal by multiple versions. * Drop apparently obsolete build-dep libgtkhtml2-dev. * Don't run update-alternatives --remove on upgrade. * Exclude Tools.PV, which requires GTK (not GTK2). * debian/rules, unbreak_cross_compilation.dpatch: Use the right gcc and pass --host=$(DEB_HOST_GNU_TYPE) to configure as necessary. Fix various bugs preventing cross compilation (Closes: #582242). Thanks to Marc Dirix. * Exclude modules GDK, Gnome, and GTKSupport, which also are for GTK+/Gnome 1.2, and update the package description of pike7.8-gtk to reflect the fact that it provides GTK+ 2.0 bindings. * Disable --with-relocatable-dumped-modules; it doesn't seem that we need it and it doesn't seem to work 100% properly. * no_dump_modules.dpatch (new): Patch install.pike not to dump modules at build time (thus no need to exclude master.pike.o in debian/rules). * Move AutoDoc and module-related modules and standalone tools to -dev and let -dev depend on -image. * module-layout.dpatch: Move misplaced parenthesis that caused the wrong local include directory to be added. * Build-depend on libmysqlclient-dev instead of libmysqlclient15-dev, which is now a virtual package provided by the former. * dumping_problems.dpatch (new): Patch from CVS fixing problems encoding the master object when dumping some modules. * cflags.dpatch (new): Make pike -x cflags print include_prefix as-is instead of stripping the last component. * Drop pike7.8-config; pike -x cflags and pike --dumpversion fills its functions. * Some changes in the meta package relationships.

6 13

DNSSD vs. Avahi
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 02 Aug '10

02 Aug '10

Any comments on http://bugs.debian.org/588394, besides "feel free to submit patches"? Michael Biebl <biebl(a)debian.org> writes: > pike7.8 is one of few package depending to the Avahi compat dnssd > library. > Please consider porting pike7.8 to use Avahi natively as we > eventually want to drop the compat lib. I guess the library that Pike uses is somewhat deprecated.

3 3

Re: GTK2 event
by Mirar ＠ Pike developers forum 31 Jul '10

31 Jul '10

Ah, maybe it's a difference GTK->GTK2.

2 2

Re: GTK2 event
by Mirar ＠ Pike developers forum 31 Jul '10

31 Jul '10

Sure. object win; object da; array dasize; void show_current() { return; } int main(int ac,array am) { GTK2.setup_gtk(am); win=GTK2.Window(GTK2.WindowToplevel); win->set_size_request(700,1000); object hbox=GTK2.Hpaned(); da=GTK2.DrawingArea(); da->signal_connect("configure-event",lambda(object da,array req) { dasize=({ req[0]->width, req[0]->height}); remove_call_out(show_current); call_out(show_current,0); }); hbox->add(da); win->add(hbox); win->show_all(); show_current(); return -1; }

2 2

Re: AutoDoc
by Marcus Agehall (nu med K-m�rkt fastighet och ny elcentral) ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

The problem with the "old" way of building modules, is that it assumes that conditions that were true when Pike was compiled is still true as it causes headers generated by configure tests at compiletime to be used. What Per is trying to point out, is that this doesn't work in every situation and isn't a good way of doing things. It's simply wrong to rely on tests done on another system. I wouldn't mind a cleanup operation on the whole build system, but that's a major task and I'm not sure anyone is willing to spend enough time on it.

1 0

Re: AutoDoc
by Per Hedbor () ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

For me autodoc generation depends on a script that is only available in the source tree, not in the installed tree. Most specifically the last parts: Converting the xml files to HTML. Another large problem with the 'complex' module system is that it hardcodes paths to the pike 'smartlink' and system libgcc. If you install a new version of pike, your external modules will still use the old one unless you re-run autoconf (note: Not configure, autoconf). The same goes for gcc updates, the old libgcc will still be used (granted, that seldom hurts things badly, but still). I don't subscribe to the 'rebuild everything' theory of software updates. I don't mind if the module system provides default targets for documentation extraction (and default autoconf macros for setting gcc etc). But I do mind that it currently enforces the exact same environment that was used to build the pike binary. I have never had problems mixing the sun CC and gcc compilers, actually (unless one counts building things with gcc and then not linking libgcc, or doing cuthuloid level unthinkables (using gnu LD on Solaris))

1 0

Re: AutoDoc
by Per Hedbor () ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

As an example: On my Solaris server at home I have installed the sun C-compiler. However, the pike binary package I installed was built using gcc. It's not possible to build modules with pike -x module with 'complex' (or old) style modules. To get it to work you really do need your own configure tests instead of relying on the results of the ones done by pike at compile time. The 'simple' (or new style) modules gives you everything you need to do that, that is, the location of pike includefiles etc. The autodoc generation actually does not work at all unless you have the sourcetree installed (same goes for the testsuite, unless I am mistaken). So that's not really related to new or old style modules, unfortunately.

1 0

Re: AutoDoc
by Per Hedbor () ＠ Pike (-) developers forum 30 Jul '10

30 Jul '10

The 'old' (or complicated) method only really works correctly when you build your pike on your own, or when it's built on an identical system to the one you have, though.

1 0

GTK2 event
by Mirar ＠ Pike developers forum 30 Jul '10

30 Jul '10

I get this error: Bad argument 1 to `[](). Expected string (8bit). Unknown program: `[](0) /usr/local/pike/7.8.455/lib/modules/___GTK2.so:1: GDK2.Event(configure)->`[](0) lotrolayout.pike:512: /main()->__lambda_65666_2_line_512(GTK2.DrawingArea,GDK2.Event(configure)) /usr/local/pike/7.8.455/lib/modules/___GTK2.so:1: GTK2.Window->show_all() myprogram.pike:526: /main()->main(1,({"/home/mirar/hack/myprogram.pike"})) On this line: da=GTK2.DrawingArea(); da->signal_connect("configure-event", lambda(object da,array req) { ... }); Any idea why? It seems like a Pike bug to me, but maybe I'm doing something wrong?

1 0

Re: AutoDoc
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 30 Jul '10

30 Jul '10

>I am curious to know, though, what makes you think >dynamic_module_makefile has been deprecated? It's used by all of the >core modules, as well as any that third-party modules that are >packaged for distribution (such as at modules.gotpike.org). The section titled "New simplified method to write external C/C++ modules" in CHANGES.

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 July 2010