Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

argv[0]?
by Johan Sundstr�m (risplockare) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

Just like that works fine. If you prefer, use <URL:http://...> instead (but it will probably not make more clients able to render clickable links; those who support links already find your URLs). / Johan Sundström (risplockare) Previous text: >2002-09-03 18:04: >Subject: argv[0]? >-------------------------------------------------------------------- >that's because linux-threads suck. The kernel implements the appropriate stuff >on the clone() level. Linux 2.6 is likely to use something else than >linux-threads - >http://oss.software.ibm.com/developerworks/opensource/pthreads/ > >(btw, how do I make the URI clickable by recipients on lyskom? :) > > / Marek Habersack (Grendel) >

1 0

[Pike-devel] Re: pike-devel@caudium.info
by Hedda (Tsar) ＠ Pike (-) developers forum 04 Sep '02

04 Sep '02

>ps: any way i can get the complete conference exported so that i can >read it? http://www.xnetz.com/pike-devel.txt (The side-text is in Swedish, but "Ärende" means "Subject", "Kommentar till" means "Comment to", and the rest of the Swedish is irrelevant.) Some texts are comments to texts outside the conference. / Hedda (Tsar) Previous text: >2002-09-03 21:06: >Subject: Re: pike-devel(a)caudium.info >-------------------------------------------------------------------- >On Tue, Sep 03, 2002 at 08:50:03PM +0200, Peter Bortas @ Pike developers forum wrote: >> You haven't asked. > >i HAVE asked!!!!!!! >noone answered!!!! > >on the pike list of course. >(because asking inside of lyskom for a mailinglist for it, >was a chicken end egg problem i did not manage to solve due to >a lack of understanding swedish) > >> *click* *click* There you go: >> http://lists.lysator.liu.se/mailman/listinfo/pike-devel > >excellent!!! >of course i prefer having the lists on lysator too. >hedda would you mind getting that set up? >we'll drop the lists on the caudium server as soon as it does. > >greetings, martin. >ps: any way i can get the complete conference exported so that i can read it? > > > / Brevbäraren >

5 16

[Pike-devel] argv[0]?
by Per Hedbor () ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

On the other hand, forking all threads is also a problem, since fork() in UNIX is mostly used to start a new process, that is, fork(); do_some_setup(); exec();, if you then have more than one thread running, things you Dont Expect(tm) can happen between those fork() and exec() calls.

2 1

[Pike-devel] argv[0]?
by Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

Pth is the default thread library on FreeBSD I think, and that seems to work just fine. / Fredrik (Naranek) Hubinette (Real Build Master) Previous text: >2002-08-29 22:24: >Subject: argv[0]? >-------------------------------------------------------------------- >what about plans for alternative threads implementations? Like pth, ngpth >etc.? > > / Marek Habersack (Grendel) >

3 8

[Pike-devel] argv[0]?
by Per Hedbor () ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

The same is true for read and write, but since the aioread/aiowrite calls are normally used in user-level threads, that's not really a problem. On the other hand, those functions are actually implemented using threads on many operating systems, thus seriously confusing the issue. :-)

2 3

[Pike-devel] Welcome to the "Pike-devel" mailing list
by Martin Nilsson (Fake Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

> If you forget your password, don't worry, you will receive a monthly > reminder telling you what all your lists.lysator.liu.se mailing list > passwords are I do worry. / Martin Nilsson (Fake Build Master) Previous text: >2002-09-03 21:22: >Subject: Welcome to the "Pike-devel" mailing list >-------------------------------------------------------------------- >Welcome to the Pike-devel(a)lists.lysator.liu.se mailing list! > >To post to this list, send your email to: > > pike-devel(a)lists.lysator.liu.se > >General information about the mailing list is at: > > http://lists.lysator.liu.se/mailman/listinfo/pike-devel > >If you ever want to unsubscribe or change your options (eg, switch to >or from digest mode, change your password, etc.), visit your >subscription page at: > > http://lists.lysator.liu.se/mailman/options/pike-devel/10353%40lyskom.lysat… > > >You can also make such adjustments via email by sending a message to: > > Pike-devel-request(a)lists.lysator.liu.se > >with the word `help' in the subject or body (don't include the >quotes), and you will get back a message with instructions. > >You must know your password to change your options (including changing >the password, itself) or to unsubscribe. It is: > > pike > >If you forget your password, don't worry, you will receive a monthly >reminder telling you what all your lists.lysator.liu.se mailing list >passwords are, and how to unsubscribe or change your options. There >is also a button on your options page that will email your current >password to you. > >You may also have your password mailed to you automatically off of the >Web page noted above. > > > / Brevbäraren >

3 3

[Pike-devel] the Pike module system
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 03 Sep '02

03 Sep '02

I don't see the point in providing site wide settings for this. Each Pike application might for some reason use a partially different namespace than the standard one. So let there be some method for it to define a namespace mapping, preferably only once and not in each source file. There might also be a reason for doing the mapping only once for a group of related applications. But doing it on a site wide level would mean that all pike applications on the site are treated as a single group (unless those that doesn't use the site wide pike installation, of course). That strikes me as a totally arbitrary grouping; I see no reason to expect that all applications that happen to be installed on a site should want to use the same nonstandard namespace. / Martin Stjernholm, Roxen IS 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) >

2 2

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

03 Sep '02

To nitpick: no module is ever executed, and no module will be executed at pike startup. There has, however, been discussions on a .pikerc and/or /etc/pikerc program that would be cloned and executed on Pike startup, although I don't remember if this has been suggested only for interactive Pike (hilfe). The latter would be preferable IMO. / Mikael Brandström (ogg! ogg! ogg!) Previous text: >2002-09-03 20:14: >Subject: the Pike module system >-------------------------------------------------------------------- >exactly - there's no module executed/loaded at the startup, and that's the >feature which would be interesting to have - for the purposes described >elsewhere in this thread. > > / Marek Habersack (Grendel) >

2 1

[Pike-devel] argv[0]?
by Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

Ok, I'm getting annoyed. Quit babbling about fork(). Fork is HARD to support and has less portable semantics than Process.create_process(). Yes, there are some instances when it would be useful but it WILL NOT be supported in Pike with threads. Personally I don't care if it is POSIX or not, because while POSIX may be a standard, it is a backwards and awkward standard that doesn't actually allow you to write useful applications. On top of that, many OS only implement parts of POSIX or have bugs in some of their POSIX calls. Using POSIX as a guide for Pike APIs is like using ASCII as a guide for drawing fonts. / Fredrik (Naranek) Hubinette (Real Build Master) 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) >

2 1

[Pike-devel] Green threads
by Fredrik (Naranek) Hubinette (Real Build Master) ＠ Pike (-) developers forum 03 Sep '02

03 Sep '02

Actually, there is a POSIX-compliant way to create a new stack. The GNU pthreads package use this and it's an interesting read. However, many existing thread packages use the stack pointer to identify which thread is currently running, which means that it is impossible for software that creates it's own stack to co- exist with these thread packages. This was all discovered while trying to make Pike dynamically allocate more C stack. There is even a libc call for doing this on some platforms, but unless the thread package is aware of what is going on it crashes horribly when you run that call in a threaded application. When it comes right down to it, it's better (and easier) to implement a better pthreads package then to implement green threads into Pike. / Fredrik (Naranek) Hubinette (Real Build Master) Previous text: >2002-08-29 15:06: >Subject: Green threads >-------------------------------------------------------------------- >I'm actually not that deep into the intricacies of thread >implementations either, but afaik there's no reasonably standard way >to create a new C stack without getting a new OS level thread at the >same time. Also, longjmp() is only defined to be able to jump to some >state "higher up" in the same stack and not between different stacks. > >Many times it'd probably work to allocate a slab of memory with >malloc() and then use a bit of implementation-dependent magic to set >up a jmp_buf struct that points to it, and then start using longjmp() >and setjmp() to switch between the stacks. It's just a "small matter >of programming" to get that working on all the different platforms. > >Libraries for this probably exists already. It'd be very appreciated >if someone set out to find one and verify that it works well on all >the platforms Pike supports. > > / Martin Stjernholm, Roxen IS >

1 0

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