Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

[Pike-devel] test
by eMBee ＠ Pike developers forum 05 Sep '02

05 Sep '02

this is a test of the emergency broadcast system, had this been a real emergency then an emacs kom client would have been used to write the message.

6 13

GTK.Ruler
by Mikael Brandstr�m (ogg! ogg! ogg!) ＠ Pike (-) developers forum 05 Sep '02

05 Sep '02

Has anyone got at working example of using GTK.Ruler together with GTK.DrawingArea to provide a ruler for the DrawinArea?

1 0

unbug
by Marek Habersack (Grendel) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

does anybody use it at all?

2 4

[Pike-devel] argv[0]?
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 04 Sep '02

04 Sep '02

You misinterpret the silence. If a suggestion is met with silence it's usually an indication that other people either think it's a nice idea or they aren't very interested (which is the case for me when it comes issue of a POSIX module). In either case, it usually means that it's ok to go ahead and implement it. / Martin Stjernholm, Roxen IS Previous text: >2002-09-03 17:52: >Subject: argv[0]? >-------------------------------------------------------------------- >Johan, not one thing, please - I proposed creating a module called POSIX >which would export those calls. This proposition was silently >ignored... while I think it would be a really good solution. > > / Marek Habersack (Grendel) >

6 19

[Pike-devel] fork(): To be or not to be
by David Hedbor (I live in interesting times) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

Instead of digging up a suitable message to comment, I am posting this one. My opinion about fork is: 1) It's unsafe with threads. Fine. It's disabled already when there are threads. 2) It has uses, especially on platforms without threads. 3) It hasn't so far caused any of the imaginary problems mentioned here in previous threads (since the no-fork-when-threaded limitation was added at least). Therefor I see absolutely no reason what-so-ever to remove it. Let it stay somewhere (in System, POSIX or but probably not the global scope). Document it as dangerous, and point out that it simply doesn't work most of the case (due to explicit or implicit threads) and explain under what circumstances it does work. This discussion has gone on too far with many unnecessary and stupid arguments whether or not fork() has a right to live. It harms no one, it's safe and it's here. Lets keep it and get on with things. Also, is there no way of getting rid of that implicit thread used on many threaded platforms (without disabling threads completely)? What is the benefit of it exactly? I don't quite see the point of it since things obviously work fine without it. :-)

4 4

[Pike-devel] the Pike module system
by Mikael Brandstr�m (ogg! ogg! ogg!) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

>It is very useful for site-wide policy setting - we've just talked about it >on IRC, people seem to like the idea and find it useful. No, since those settings could be easily circumvented. Ploicy settings should not be set within a language, but rather by the operating system. Or might it be that we are talking about different kinds of policies? >again, it's ok if it is a site-wide policy. Change the scale of your point >of view - look at it from the site standpoint, not from the language >implementor's standpoint. I'm looking from the the point of view of a frequent Pike user, now and then writing programs which other people might have use for. I don't want to ge frequent questions why my script/hack/program doesn't work on a particular site, just because a site administrator has set up some brain-dead non-standard site settings for the Pike installation. Given the posibility of site-wide replacement of some global symbols, some administrator will at some point do such a replacement, which will in turn cause harm to the users of that system who expect a Pike program they dowload from the net themselfes to work. >That's what FAQ is for... Also, I assume that people will read docs - they >should stress that relying on any modules being autoloaded is WRONG. I would not assume people to read the all necessary documentation, it would be naïve to do it. >oh, come on! What kind of bad karma if the docs make things clear? Regardless of how good the docs are, there will be people who don't read them and will cry out loudly on the mailing-list that it doesn't work, and such things will be found by google et. al. That's sort of a sad fact. >No, it's perfectly clear, but I've got a feeling that I didn't make myself >clear enough. This is only a feature, not a way to free users from checking >whether the module they need is loaded, that's first. True, but how do you check if a module is loaded? As I've stated elsewhere, and you say yourself. Modules are always autoloaded. I don't get what you imply with "autoload". Is it systemwide import to the global namespace you want to achive? >Second, pike loads >the modules on demand - your hypothetical situation will have no place, >because if some module isn't auto-loaded, it will be loaded when the user >accesses it for the first time. See above. >Third, the autoload feature is good for >setting up some kind of widely understood environment - setting some >site-specific variables, setting up security contexts etc.; Isn't the most widely understood Pike environment the default environment Pike supplies? What you are writing about could be useful in Hilfe though, but not interpreter-wide. >Fourth, the >autoload feature might be used by the site administrator to show some >motd-like thing (a stupid example made up ad hoc :)) Yes, in Hilfe, not in Pike as such. >Compatibility should be thrown away at some point, otherwise it doesn't >make sense to introduce improvements. I meant the #pike pragma och the -V option to the interpreter. That compatability should not be thorwn away, and is useful for running legacy applications that has not been updated to current status of the language. I fail to see why this would make it uniteresting to introduce improvements? / Mikael Brandström (ogg! ogg! ogg!) Previous text: >2002-09-03 18:35: >Subject: the Pike module system >-------------------------------------------------------------------- > >>>that warning about clashes on the global level would be enough, but it >>>might be useful if Pike warned about method arguments and local variables >>>shadowing some global identifier. >> >>No. Not per default, maybe if supplying a flag, like -Wclobber. I >>quite often overload lfuns (which are present globally) and I don't >>want Pike to complain on that. >Yep, that makes sense, sure. > >>>>should themselfs make sure they contain all dependencies they need. As >>>>nilsson said earlier, it would not be fun to every now and then get >>>>complaints to pike fora that certain programs fail miserably, just >>>I'm sorry, but I don't understand this argument. The impression I get is >>>that you (plural) are promoting a language that is to resolve all the >>>user's problems and, IMHO (and some people I talked to about the issue) >>>Pike should stay a general purpose language that gives its users maximum >>>flexibility in choosing the ways to solve one problem. As I said - the >>>autoloading _feature_ would be fully under the control of the site >>>administrator or the individual user - no upstream default autoloads, >>>nothing like that. Why would such a _feature_ be bad? >> >>There is nothing bad as such to the feature (other than that it's >>redundant in some sense). The problem is that given such a feature >It is very useful for site-wide policy setting - we've just talked about it >on IRC, people seem to like the idea and find it useful. > >>programmers will start writing code depending on autoloaded modules, >that's ok, as long as it is a site policy. Pike docs should describe only >the autoload feature, not that any modules are available through it. Don't >assume all users are dummies. > >>or that certain compatability code has been run, etc. In doing so, the >>will make sure the program won't work unless that code has been >again, it's ok if it is a site-wide policy. Change the scale of your point >of view - look at it from the site standpoint, not from the language >implementor's standpoint. > >>run. The most common user will, when a script fails, not ask the >>administrator, but rather ask in relevant Pike fora, just to make the >>people in those fora reply "go blame your system administrator", and >That's what FAQ is for... Also, I assume that people will read docs - they >should stress that relying on any modules being autoloaded is WRONG. > >>pike will get bad karma since people then find the people in pike fora >>unfriendly and non-helpful. I don't want this to happen. The good >oh, come on! What kind of bad karma if the docs make things clear? > >>thing with Pike is that it's a portable envirnoment in which you can >>be sure that the program works, given that the dependincies made >>explicitly in your code are met. These explicit dependencies will be >>even easier to trace given a hierarcical third party module tree with >>clear delegations -- and people on the lists can give the more >>informative answer: Check the pike module repository for that and that >>module, install it and it will work. >> >>Anything unclear in that? >No, it's perfectly clear, but I've got a feeling that I didn't make myself >clear enough. This is only a feature, not a way to free users from checking >whether the module they need is loaded, that's first. Second, pike loads >the modules on demand - your hypothetical situation will have no place, >because if some module isn't auto-loaded, it will be loaded when the user >accesses it for the first time. Third, the autoload feature is good for >setting up some kind of widely understood environment - setting some >site-specific variables, setting up security contexts etc.; Fourth, the >autoload feature might be used by the site administrator to show some >motd-like thing (a stupid example made up ad hoc :)) > >>>Let me give you one ad-hoc example - what if the administrator was >>>able to autoload a simple module, loaded each time pike is used, which >>>would set the default security settings? Resource limits, pike security - >>>anything? >> >>That's really nothing that should be done in Pike, especially since >>a user can upload his own pike to the system and easily circumvent >>such things. >Come on, that can be avoided _easily_ by a half-experienced programmer and >is really of no importance here. And pike-security cannot be set up outside >of the pike context. > >>No, to be honest, I don't see any use for your autoload feature. >>Especially if the hierarcical delegated module system becomes a >>reality. If any module is moved within the base modules of pike, that >>should be reflected in the current compatability system. >Compatibility should be thrown away at some point, otherwise it doesn't >make sense to introduce improvements. > > / Marek Habersack (Grendel) >

3 7

Process.daemonize()
by Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

And another thing about discussions in KOM in general: it is often the case that the debate or discussion itself runs amok just because some, possibly several, person(s) start talking about philosophy, operating systems behaviour or other somewhat unrelated topics rather than being in disagreement about relevant facts. I'm sure nobody would object about a Process.daemonize() call if you or someone else who wanted it implemented it and tested it to work on systems where this is possible, and disabled and documented this added dependency on systems where it does not work. From what I have heard, implementing a Process.daemonize call would require a syscall giving an inverted fork(1) (to move along all threads), on systems with threads, or be easy on systems without threads. Arguing that someone else should write it will almost certainly fail, implementing it on one's own will almost certainly succeed; doers decide, except for the cases where there are loud vetos. Of course, doers who show clear signs of disrespecting portability or other important issues; typically by not disabling functions on systems where they fail, failing to document such dependencies or naming the methods in a manner suggesting universal portability. There has not yet been loud vetos against a daemonize call, but Marcus will not implement it, since he is fully satisfied with having the setsid (IIRC) hack for the same purpose in Process.create_process. The fact a daemonize call like this could be made in two different ways from the Pike level is not something that unlikely to irritate anyone. / Johan Sundström (risplockare) Previous text: >2002-09-03 18:40: >Subject: argv[0]? >-------------------------------------------------------------------- >>Quite the opposite. According to the UNIX philosophy, there should be >>one program for each task that does that task well. nohup performs >>the task for daemonization. So in a sense, _not_ using nohup is a >>hack. ;-) >You could argue that, yep :) - but nohup isn't necessary in this scenario >and, compared to other methods of daemonizing the program, it is a definite >hack. > >>You are relying on init to start getty, which you are relying on to >>start your login shell, which you are relying on to start program. >yeah, that's the usual way. At least once in my life I had an installation >where my program was the only one started on the machine - instead of >init. And, frankly, except for the kernel there was nothing else but the >static program there. > >>Why would inserting nohup into this chain be a special case? >see above. > >>I.e. what makes >> >> init -> getty -> sh -> nohup -> prog >> >>so much different than >> >> init -> getty -> sh -> prog >unnecessary dependence on the nohup presence. > >>? In both cases you are relying on a number of "external programs". >>This is what separates a real OS from a C64. >no, I'm not relying on init, to be honest :) - it's a part of the sequence, >but it is possible to avoid it, so it's not a strict relation. > >>>When I exec a pike script and move it to the background and I don't >>>exec anything from inside it, then I'm not relying upon anything _during >>>the execution_ of the script. >> >>Nor would you be relying upon nohup _during the execusion_, since >>nohup just sets things up and then calls exec(). So when your >>programs starts executing, nohup is already gone. >You're right, but I still don't consider this solution an elegant one. > > / Marek Habersack (Grendel) >

2 1

Process.daemonize()
by Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

> an inverted fork(1) (to move along all threads), on systems with Oops, that should have been fork1(2).

1 0

argv[0]?
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

Yes. / Henrik Grubbström (Lysator) Previous text: >2002-09-03 20:14: >Subject: argv[0]? >-------------------------------------------------------------------- >so it would have to be an option passed to the interpreter, right? > > / Marek Habersack (Grendel) >

1 0

[Pike-devel] argv[0]?
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

>Am I? Let's test your theory, my friend. Given a script: > >int main() >{ > write("I'm returning -1\n"); > return -1; >} > > > put it on some remote host and type this on another host: > >ssh -T yourlogin(a)your.remote.host.com /path/to/pike /path/to/tst.pike > >According to you no daemonization is necessary in this case (no allocated >shell nor terminal) - in this case there's no interactive shell nor a pty >allocated, the process should go to the background and return to the >calling process. Somehow it doesn't happen. I probably didn't RTFM enough, though. No, "going to the background" is a separate operation. You can see for yourself that daemonization is not necessary: If you press ^C the ssh process dies but the pike program remains. In order to put the program in the "background" as well, you just have to use & as usual. An additional quirk with ssh though is that the client will hang around until everything has closed the stdout/stderr that ssh creates. So in this particular case we'll need a redirection too: ssh -T yourlogin(a)your.remote.host.com /path/to/pike '>&/dev/null' \ /path/to/tst.pike \& (My login shell is tcsh, so I'm using >& to redirect both stdout and stderr in one go.) That you should use & to put things in the background shouldn't come as a surprise, and as I said the redirection is only strictly necessary for the ssh case. If starting tst.pike from inetd, cron or rc, you only need to redirect if you are not satisifed with where stdout/stderr ends up per default. In none of these cases do you need nohup. >You really seem to be missing the point. Quite possibly. Provided that there really is one, apart from "waah waah that's not the solution _I_ though of so I don't like it". >>It's only when you start the program manually that you need to >>daemonize it. >And not only when there's controlling terminal and/or interactive shell? You only have a controlling terminal and/or interactive shell when you're starting it manually. (Yes, there may be edge cases, but this is the general case.) >>Yes, I know, but I'm arguing that that is usually not necessary, since >>it can be daemonized from "without" instead. There is a good reason >>for using an external program: It reduces the complexity of your >>program. Just as not including a file manager in every program but >>instead relying on the shell reduces the complexity of programs. >What complexity??? Is calling 3 more functions that complex? It's more complex than not calling them. Hence "adding". It also adds to the complexity of the language to have the function at all. Especially from a porting complexity point of view. >>It is probably you who should read the thread again, since the answers >>to your "real question" is already there, but to recapitulate: >> >>* To daemonize a pike program from the shell: Use nohup. >I was right, you missed the point, completely. I DO NOT want to use nohup >to do that. I want the program I invoke to take a parameter and go to the >background on its own. It is that simple. You have a problem: You want to daemonize a program I have a solution: You run nohup on it Just throwing yourself on the ground and yelling "DONT WANNA!!!!" when presented with a workable solution just seems to indicate that you weren't really interrested in solving the problem at all. >Sure it is religious. That answer should satisfy you. I've got an allergy >to relying on external processes, still trying to find a cure for the itch. Yeah, but in order to understand the deeper nature of your religion, I was trying to figure out what "relying on external processes" (and other terms of canon to the religion :) really meant, hence the various excursions. It's not terribly important, so you don't have to endulge me if you don't want to. :-) / Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) Previous text: >2002-09-03 21:07: >Subject: argv[0]? >-------------------------------------------------------------------- >>>Fine, let's start nit-picking now. Let's remove the interactive shell from >>>the chain - that still makes your nohup an unncecessary addition which fits >>>nowhere in the picture. >> >>If you remove the interactive shell, then the very operation of >>daemonization is unnecessary (since the process won't have a >>controlling shell/terminal anyway), so of course there's no need for >>nohup in that case. Neither have I suggested that you should have >>one. You are fighting strawmen. >Am I? Let's test your theory, my friend. Given a script: > >int main() >{ > write("I'm returning -1\n"); > return -1; >} > > > put it on some remote host and type this on another host: > >ssh -T yourlogin(a)your.remote.host.com /path/to/pike /path/to/tst.pike > >According to you no daemonization is necessary in this case (no allocated >shell nor terminal) - in this case there's no interactive shell nor a pty >allocated, the process should go to the background and return to the >calling process. Somehow it doesn't happen. I probably didn't RTFM enough, though. > >Should I use nohup to make it detach? > >>>which 5 daemons that are in common use are daemonized by the use of nohup >>>and a redirection of the nohup output to /dev/null? >> >>Using nohup to daemonize something would still not be a property of >>that program, since you can use nohup to daemonize anything. For >>example, the 5 programs 'tee', 'sed', 'cat', 'awk' and 'grep' can all >>be daemonized with nohup (alhough redirecting to something other than >>/dev/null would usually be more useful for these examples). >You really seem to be missing the point. > >>>>Not really. That's mainly because I don't stand around looking over >>>>peoples shoulders trying to accumulate statistics on their shell >>>>usage. At any rate, most people don't start daemons manually. >>>What does it have to do with the subject? >> >>It's only when you start the program manually that you need to >>daemonize it. >And not only when there's controlling terminal and/or interactive shell? > >>>no, you got it all wrong. I want a way to daemonize my program from within >>>it - without relying upon external programs for no good reason. >> >>Yes, I know, but I'm arguing that that is usually not necessary, since >>it can be daemonized from "without" instead. There is a good reason >>for using an external program: It reduces the complexity of your >>program. Just as not including a file manager in every program but >>instead relying on the shell reduces the complexity of programs. >What complexity??? Is calling 3 more functions that complex? > >>It is probably you who should read the thread again, since the answers >>to your "real question" is already there, but to recapitulate: >> >>* To daemonize a pike program from the shell: Use nohup. >I was right, you missed the point, completely. I DO NOT want to use nohup >to do that. I want the program I invoke to take a parameter and go to the >background on its own. It is that simple. > >>>You are way out of topic here and you perfectly know that. Let me remind >>>you that it was you who came up with that chain of execution, relying on >>>external programs etc. >> >>Yes, that's why I have to struggle with understanding exactly what you >>mean by them that allows you to draw the conclusions that you do. >I will improve my English, promise. > >>>While, again, the original question is - how to >>>daemonize a pike program? (yes, I can repeat it ad nauseam) >> >>Ok, how about I repeat the answers ad nauseum then, since you don't >>seem to be satisfied with them only being answered once or twice? >My IQ is just too low, you know. That's the biggest problem of my life... a >real tragedy. > >>>hmm? Now you're making personal excursions? >> >>I'm just curious about what's so bad about "relying" on tools provided >>by the operating system. It seemed like some kind of religious >>standpoint, and those are typically very personal. >Sure it is religious. That answer should satisfy you. I've got an allergy >to relying on external processes, still trying to find a cure for the itch. > > / Marek Habersack (Grendel) >

6 19

Jump to page:

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