HABERDAR.COM - HABER VE MEDYA PORTALI
Artýk tüm haberleri sadece tek siteden takip edebileceksiniz. Haberdar.com
açýldý!
Haber baþlýklarý, spor haberleri, teknoloji haberleri, kültür ve sanat
haberleri, internet haberleri, bilim ve uzay,
sinema, saðlýk...
Aradýðýnýz içerik http://www.haberdar.co
На Ваше имя пришла открытка. Отправитель Alla.
Вы можете увидеть ее:
http://cards.mail.ru/card.html?id=9868866503994&user_id=6681019
Открытку можно просмотреть в течение 90 дней.
Эта услуга абсолютно бесплатна! Приятного просмотра !
"Niklas Höglund" <[EMAIL PROTECTED]>"@MIT.EDU writes:
> Users can maintain the groups themselves, so one member in the "club" can
> maintain that group if it is named "user_a:club", but I don't think the
> group management can be shared, and one user would "own" the group.
A group can own another
Hello,
I've released PPtop 0.1.0. This release includes internationalization,
filters,
online help, and many bug fixes. This should be quite usable for anyone.
The tarball is available at:
http://freesoftware.fsf.org/download/hurdextras/pptop-0.1.0.tar.gz
=
James Morrison
Univers
On Sun, Aug 25, 2002 at 03:20:57PM +0200, Jaap Karssenberg wrote:
> The following might very well be absurd, I was daydreaming.
It's not absurd at all, this (and other things) is exactly what the Hurd
author had in mind when designing the auth server.
Thanks,
Marcus
--
`Rhubarb is no Egyptian g
On Sun, 2002-08-25 at 15:20, Jaap Karssenberg wrote:
> When one allows users to create new groups within their own name space,
> wouldn't a logical next step to be to let users create their own users within
> their own name space (and within their own "permission space").
> If this is really absu
Greetings
The following might very well be absurd, I was daydreaming.
When one allows users to create new groups within their own name space,
wouldn't a logical next step to be to let users create their own users within
their own name space (and within their own "permission space").
For exampl
Le dim 25/08/2002 à 11:43, Marcus Brinkmann a écrit :
> In the way the code seems to be written, you MUST make this static and
> do an "if (!filename) {...} return filename;" where ... contains most of the
> code.
> You are leaking memory at each invocation here. Alternatively, all callers
> of gi
On Wed, Aug 14, 2002 at 10:11:04AM +0200, PUYDT Julien wrote:
> gchar*
> gimp_gtkrc ()
> {
> - static char filename[MAXPATHLEN];
> + char *filename;
In the way the code seems to be written, you MUST make this static and
do an "if (!filename) {...} return filename;" where ... contains most of
Le dim 25/08/2002 à 10:43, Niels Möller a écrit :
> One also needs to free the string somewhere (unless gimp uses
> automatic gc?). Sometimes it's more convenient to use alloca + sprintf
> than asprintf.
The original variable was a static char [MAXPATHLEN]; I use a
dynamically allocated string, o
James Morrison <[EMAIL PROTECTED]> writes:
> I don't know how portable filegimp needs to be but you may want to
> look at asprintf.
One also needs to free the string somewhere (unless gimp uses
automatic gc?). Sometimes it's more convenient to use alloca + sprintf
than asprintf.
/Niels
Le dim 25/08/2002 à 06:19, Niklas =?iso-8859-1?q?H=F6glund=22?=
@club-internet.fr a écrit :
> On Thu, 22 Aug 2002 12:20:38 +, Tom Hart wrote:
> > On my university's network, for example, students can't even change
> > their backgrounds (except by using "set as wallpaper" from within a web
> >
12 matches
Mail list logo
