can you summarize the changes that have been done since the conference?
not sure if all of these were 7.6 material: (taken from a post by mast, conference notes and memory)
module make system (cleanup, document, add local_install target) change proccess name (marek did some work on that but stumbled on some portability barrier i think) detach process from console aclocal for pike detection iterator api document C api more describe memory handling in manuals ipv6 finish the implementation of the "variant" feature better implicit lambda implement this_function() pike security internationalisation / localization embedding
done already?:
fix memory overwrite bug in the "uses" array in peep.c fix bug which caused a fatal in the gc
other small things:
implement a variant of _locate_references add a function or option to create_process that conveniently starts a pike interpreter with another pike script dump pike backtraces on SIGSEGV fix odd indentation of the output from %O for e.g. arrays fix LXR view of the pike source on the pike site
not tied to the release per se, but might be nice to announce together:
pike community (need more help building the interface) module repository
other items from the conference: configuration examples
greetings, martin.
Martin prodded me to comment on the list, so here are my brain dumpings:
The module build system is essentially done. It would be nice to get a module download option in before 7.6 is released. If that happens more than 2 weeks out, there's a good chace of that happening as well.
The process title change feature requires either setproctitle() or access to argv. Neither method is portable to Solaris (or rather, has no effect on solaris).
Detaching process from console can be accomplished using a clunky workaround (Process.create_process). Ideally, fork() could be modified to allow forking() early in the program. Has anyone considered working on this?
I've done some preliminary work on the aclocal addition. I'll get it out for review in a day or so. Keep reminding me about this if I forget.
I have some notes that I'd like to add to Lance's insights on the module C-API
internationalisation / localization
I think we covered these at the conference, the result was "use the Locale module". Q: Is there any code out there to create the xml files that the Local module can read?
embedding
yeah, right.
add a function or option to create_process that conveniently starts a pike interpreter with another pike script
would be a nice alternative to fixing fork(), but on many systems, pike takes a long time to start up (>5 sec).
module repository
I'm working on a proof of concept, that would be fully functional. Expect more in the next two weeks or so.
Bill
In the last episode (Dec 16), Bill Welliver said:
The process title change feature requires either setproctitle() or access to argv. Neither method is portable to Solaris (or rather, has no effect on solaris).
Setting argv on Solaris does change the commandline as reported by /usr/ucb/ps:
$ cat /usr/local/bin/ps #! /bin/sh case $1 in -* ) exec /usr/bin/ps "$@" ;; * ) exec /usr/ucb/ps "$@" ;; esac $ ps auxww | grep sendmail root 344 0.0 0.1 4384 2184 ? S Dec 10 0:13 sendmail: accepting connections smmsp 345 0.0 0.1 4352 1512 ? S Dec 10 0:00 sendmail: Queue runner@00:15:00 for /var/spool/clientmqueue $ ps -ef | grep sendmail root 344 1 0 Dec 10 ? 0:13 /usr/lib/sendmail -bd -q15m smmsp 345 1 0 Dec 10 ? 0:00 /usr/lib/sendmail -Ac -q15m
Just get in the habit of using BSD instead of SYSV arguments to ps :)
add a function or option to create_process that conveniently starts a pike interpreter with another pike script
would be a nice alternative to fixing fork(), but on many systems, pike takes a long time to start up (>5 sec).
I find pike can take a while to start up the first time because it has to load all the modules, but it's all just disk I/O since they're all dumped. Later pikes pull the files from the disk cache and start up fast. Programs using Calendar always take a while to start though.
If I'm not mistaken, the use of threads already at startup has been done away with now. So it should work fine to use fork to release a process from a command shell.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-12-16 22:45: Subject: Re: Pike 7.6
Martin prodded me to comment on the list, so here are my brain dumpings:
The module build system is essentially done. It would be nice to get a module download option in before 7.6 is released. If that happens more than 2 weeks out, there's a good chace of that happening as well.
The process title change feature requires either setproctitle() or access to argv. Neither method is portable to Solaris (or rather, has no effect on solaris).
Detaching process from console can be accomplished using a clunky workaround (Process.create_process). Ideally, fork() could be modified to allow forking() early in the program. Has anyone considered working on this?
I've done some preliminary work on the aclocal addition. I'll get it out for review in a day or so. Keep reminding me about this if I forget.
I have some notes that I'd like to add to Lance's insights on the module C-API
internationalisation / localization
I think we covered these at the conference, the result was "use the Locale module". Q: Is there any code out there to create the xml files that the Local module can read?
embedding
yeah, right.
add a function or option to create_process that conveniently starts a pike interpreter with another pike script
would be a nice alternative to fixing fork(), but on many systems, pike takes a long time to start up (>5 sec).
module repository
I'm working on a proof of concept, that would be fully functional. Expect more in the next two weeks or so.
Bill
/ Brevbäraren
I will look into that and see.
Bill
On Tuesday, December 16, 2003, at 07:05 PM, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
If I'm not mistaken, the use of threads already at startup has been done away with now. So it should work fine to use fork to release a process from a command shell.
/ Martin Stjernholm, Roxen IS
OK, I've done a quick test on 7.5.15, and it does appear that fork() is functional at startup, as mast had mentioned. The following code seems to leave me in the background:
bash-2.05$ more test.pike int main() { werror("starting fork...\n"); if(fork()) { werror("not the new copy.\n"); return 0; } werror("done.");
call_out(c, 5); return -1; }
void c() { write("still running...\n"); call_out(c, 5); }
So it looks like one more item can be scratched from the 7.6 TODO list. I don't know that this makes the "start a new pike process" convenience function obsolete or not. Any thoughts?
Bill
Good. I think the problem with threads at startup was on e.g. Solaris. Did you test there?
I don't know that this makes the "start a new pike process" convenience function obsolete or not. Any thoughts?
It doesn't. It's useful to start new pike scripts at any time in a multithreaded application. fork only works at startup before any threads are started.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-12-17 02:29: Subject: fork()ing into background (was Pike 7.6)
OK, I've done a quick test on 7.5.15, and it does appear that fork() is functional at startup, as mast had mentioned. The following code seems to leave me in the background:
bash-2.05$ more test.pike int main() { werror("starting fork...\n"); if(fork()) { werror("not the new copy.\n"); return 0; } werror("done.");
call_out(c, 5); return -1; }
void c() { write("still running...\n"); call_out(c, 5); }
So it looks like one more item can be scratched from the 7.6 TODO list. I don't know that this makes the "start a new pike process" convenience function obsolete or not. Any thoughts?
Bill
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Dan Nelson -
Martin Bähr -
Martin Nilsson (saturator) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum