Pike-devel September 2002

pike-devel@lists.lysator.liu.se

8 participants
83 discussions

argv[0]?
by Leif Stensson, Lysator ＠ Pike developers forum 05 Sep '02

05 Sep '02

("Leif", not "Lief".) My point wasn't really that fork() was a part of unix whether one likes it or not, but rather that fork() was a perfectly good API to process creation _for an operating system_. It doesn't follow from this that the operating system API must be literally reflected in the API of a programming language; especially not a programming language for portable script-like application, rather than low-level system-specific programs. It might be nice to provide access to the operating system functions generally, so that people who really need them to do lower-level things can do so. But in my opinion, that's not a high priority for a language like Pike. / Leif Stensson, Lysator Previous text: >2002-09-03 17:50: >Subject: argv[0]? >-------------------------------------------------------------------- >What about people other than "we"? As Lief (I think) stated fork() is at the >base of any *nix system whether one likes it or not - as such, it is very >useful since pike runs on many *nix systems... > > / Marek Habersack (Grendel) >

1 0

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

05 Sep '02

Is it possible to send an event/signal to a GTK widget? I have searched the manuals extensively, but not found anything helpfull. I've found perl-gtk examples on how to do it *shrug*, but not anything that works in Pike. The reason is that I want to propagate events to a sister-widget.

1 0

[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

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 September 2002