lprng-devel Mailing List for LPRng

hi list,

does anyone has a clue how to interpret complex gprof outputs ?

i try to figure out why lprng is so slow when huge number of jobs are
in the queue. I managed to profile the problem but i am not sure about
the results since i do not use gprof often an the documentation is to
unspecific  to understand the results.

re,
 wh

* Bernhard R. Link <br...@de...> [070307 18:04]:
> Attached patch only includes the lpd_*.c files in lpd and no longer
> in the other binaries, and the code movements to make that possible.
> Suggestions for better new places for the split out code parts
> than new files very welcome.

Attached is an updated version with some more files I overlooked at the
first time.

Hochachtungsvoll,
	Bernhard R. Link

* walter harms <wh...@bf...> [070219 19:21]:
> monitor is a network debug program that comes with lprng an other projects (e.g. ifhp)
> since it has nothing to do with the lprng itself i would like to move it into it own
> cvs tree and remove it from all other packets.

I've taken a short look at the version within LPRng and it seems to be
much too deeply interweaved to be easily put it into its own tree.
The version within ifhp seems to be more stand alone, but I'm not sure
it has the same functionality. The one in LPRng seems to special-case
several values (like TRACE, PRSTATUS, QEUE, DUMP and so on). It would
be nice if anyone could look into those and tell whether the ifhp
version suffices or could be easily extended.

Hochachtungsvoll,
	Bernhard R. Link

On Sun, Mar 11, 2007 at 10:46:00PM +0100, Bernhard R. Link wrote:
> > Attached patch only includes the lpd_*.c files in lpd and no longer
> > in the other binaries, and the code movements to make that possible.
> > Suggestions for better new places for the split out code parts
> > than new files very welcome.

I had a look at the patch, it looks fine to me. Just removing some
knitting that doesn't need to be there.

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                             csmall at : enc.com.au
http://www.debian.org/          Debian GNU/Linux, software should be Free 

hi brl,
i was very busy the last days but i found some time to relax
and think about the macros with vararg and no arguments.
the info page for gcc says that C99 is adding __VA_ARGS__.
It is less clear about empty arg lists but it would be a
workable the replace the stuff and simply add this requierement.

The only other way is to use a common call like plp_printf()
and use vprintf() (in that case) or any home brew function.

looking into the std. i am not so sure if the unbalanced (
are even ISO conform. it says "well formed" IMHO that includes
closed (.

any opinions on this list here ?

re,
 wh


Bernhard R. Link wrote:
> * walter harms <wh...@bf...> [070225 16:05]:
>> hier brl,
>> i guess there is a missunderstanding, i was thinking to remove the vararg.h stuff.
>> it would simplify some things. The question is: is there any need for vararg.h ?
>> IMHO: NO
>>
>> NTL: i was thinking to remove the unblanced ( macros this way:
>>
>
> If this actually compiles, all is well. Normaly that does not
> work because there always is some place where only a format and
> no arguments are given and that leeds to something like
> printf("something without percent sign\n",)
> which C compilers tend to complain about. The way to
> avoid this is to make it
> 
> #define SNPRINTF(X,Y,fmt,args...) printf(fmt , ## args)
> 
> though last I looked that was still a gcc extension.
> (AFAIR even the args... is a gcc extension and the only
>  standard conform way (though having the same problems with zero
>  arguments) is)
> #define SNPRINTF(X,Y,fmt, ...) printf(fmt, __VA_ARGS__)
> 
>> btw: did you add the STDOUT stdout  ?
> 
> The whole chunk is in 1.2 of portable.h, i.e. unchanged since 3.7.1.
> 
> I thought some other things like DEBUG* would do such ugly tricks, too,
> but they do more harmless variants. Given that gcc already warns us
> for the plp_snprintf functions I think that FORMAT_TEST can be removed
> altogether, and something like
> 
> # define FPRINTF safefprintf
> # define PRINTF safeprintf
> # define STDOUT 1
> # define STDERR 2
> # define SNPRINTF plp_snprintf
> # define VSNPRINTF plp_vsnprintf
> # define SETSTATUS setstatus
> 
> Ideally some day in the future we can also throw out the
> reimplementation of the *printf* functions, but I fear that
> is just undoble, given how complicated it already is to port
> sloppy Linux-only programs to Solaris' libc without segfaulting
> everywhere because of less generosity towards NULL values...
> 

* Bernhard R. Link <br...@de...> [070307 18:04]:
> Attached patch only includes the lpd_*.c files in lpd and no longer
> in the other binaries, and the code movements to make that possible.
> Suggestions for better new places for the split out code parts
> than new files very welcome.

again with the patch

Hochachtungsvoll,
	Bernhard R. Link

On Wed, Mar 07, 2007 at 06:03:25PM +0100, Bernhard R. Link wrote:
> Attached patch only includes the lpd_*.c files in lpd and no longer
> in the other binaries, and the code movements to make that possible.
> Suggestions for better new places for the split out code parts
> than new files very welcome.
No patch attached?

 - Craig
-- 
Craig Small      GnuPG:1C1B D893 1418 2AF4 45EE  95CB C76C E5AC 12CA DFA5
http://www.enc.com.au/                      MIEE         Debian developer
csmall at : enc.com.au                      ieee.org           debian.org

Attached patch only includes the lpd_*.c files in lpd and no longer
in the other binaries, and the code movements to make that possible.
Suggestions for better new places for the split out code parts
than new files very welcome.

The net win in a stripped install of the binaries is around a megabyte.
(which I consider quite enormous).

Hochachtungsvoll,
	Bernhard R. Link