> I noticed that some of the plan9port .h files have "extern C" C++ compiler
> directives:
>
> #if defined(__cplusplus)
> extern "C" {
> #endif
> ...
>
> Is this actually necessary since I thought C++ was not supported in Plan
> 9, et al.
They're for compiling mpm.
Russ
I don't have a Plan 9 system so I can't look at what you're seeing.
Maybe you could post the PS and PDF somewhere?
It sounds like perhaps you're worrying about the exact spacing
of the math symbols not lining up properly. That's almost certainly
true: zoomed in screens are much less forgiving tha
Iruatã,
Thanks for following up. Your example demonstrates that it is possible,
and maybe even desirable, to work in this way. So, I know to deal with it
appropriately.
Thanks again.
EBo --
> % g++ -I$PLAN9/include -c a.cc && g++ -o a a.o $PLAN9/lib/libgeometry.a
> % a
> 1
> 1
> 2
>
> wi
On Fri, Aug 20, 2010 at 5:41 PM, EBo wrote:
>
>
>> i guess you answered that yourself. does p9p run on Plan 9?
>
> There a plenty of programs which are made to run under both p9p and plan9.
> So, no the question is still open, but I will rephrase it.
>
> Should any program which can run under p9p
I meant my understanding was that Sun's compiler is a C++ compiler. As
Lyndon points out, C is a subset. I may be wrong, but it can't possibly hurt
to leave it in. Any c++ compiler should be able to compile it.
On Aug 20, 2010 6:00 PM, "Lyndon Nerenberg" wrote:
>>> Should any program which can ru
Should any program which can run under p9p and plan9 ever be compiled with
g++ or another c++ compilers? Otherwise is it necessary to check for
__cplusplus?
C is a subset of C++, so a C++ program can validly include native C code.
>> Should any program which can run under p9p and plan9 ever be compiled
>> with
>> g++ or another c++ compilers? Otherwise is it necessary to check for
>> __cplusplus?
>
> I think it may be for Sun compilers.
Thanks Devon,
Is there anyone who can verify it? I gave away my old Sun workstatio
On Fri, Aug 20, 2010 at 10:38:17AM -0700, ron minnich wrote:
>
> I'm amused about dvips executing commands. People have given Adobe a
> lot of trouble about the embedded javascript in PDF files, and now we
> see that somewhere along the line the open source community did
> something even worse. Wh
2010/8/20 EBo :
>
>
>> i guess you answered that yourself. does p9p run on Plan 9?
>
> There a plenty of programs which are made to run under both p9p and plan9.
> So, no the question is still open, but I will rephrase it.
>
> Should any program which can run under p9p and plan9 ever be compiled wi
> i guess you answered that yourself. does p9p run on Plan 9?
There a plenty of programs which are made to run under both p9p and plan9.
So, no the question is still open, but I will rephrase it.
Should any program which can run under p9p and plan9 ever be compiled with
g++ or another c++ compi
On Fri, Aug 20, 2010 at 3:29 PM, EBo wrote:
>
> I noticed that some of the plan9port .h files have "extern C" C++ compiler
> directives:
>
> #if defined(__cplusplus)
> extern "C" {
> #endif
> ...
>
> Is this actually necessary since I thought C++ was not supported in Plan
> 9, et al.
>
> Just chec
I noticed that some of the plan9port .h files have "extern C" C++ compiler
directives:
#if defined(__cplusplus)
extern "C" {
#endif
...
Is this actually necessary since I thought C++ was not supported in Plan
9, et al.
Just checking...
EBo --
On Fri, Aug 20, 2010 at 9:03 AM, wrote:
> On Fri, Aug 20, 2010 at 04:42:22PM +0100, Richard Miller wrote:
>> > I want dvips(1) to only have
>> > one configuration file, called: "dvips.cnf" (and not "config.ps"
>> > since it's not Postscript instructions)
>>
>> The default config file name may be
On Fri, Aug 20, 2010 at 03:50:20PM +0100, Richard Miller wrote:
> > - There was support for embedded commands calling system(3).
>
> [...]
> The article also mentions some attacks on previewers, but the authors
> seem to have missed the potential exploits enabled by this "feature"
> of dvips.[...]
On Fri, Aug 20, 2010 at 04:42:22PM +0100, Richard Miller wrote:
> > I want dvips(1) to only have
> > one configuration file, called: "dvips.cnf" (and not "config.ps"
> > since it's not Postscript instructions)
>
> The default config file name may be silly but that's where people
> who are used to
> I want dvips(1) to only have
> one configuration file, called: "dvips.cnf" (and not "config.ps"
> since it's not Postscript instructions)
The default config file name may be silly but that's where people
who are used to dvips on another o/s will expect to find it.
On Aug 17, 2010, at 8:59 PM, Russ Cox wrote:
>> Postscript is fine, I'll just ignore the proliferation
>> of PDF until I've got time to dig in and look more
>> deeply into eqn and the ghostscript sources.
>
> It's almost certainly that addpsfonts isn't adding
> the right ps fonts. I've never see
> - There was support for embedded commands calling system(3).
That's pretty scary.
Coincidentally, a few hours ago I was reading an article in the latest
;login entitled "Don't Take LaTeX Files from Strangers" which shows
how TeX's built-in file i/o macros can be exploited to do some not very
ni
Hello,
I have started cleaning things for dvips(1) (to be included in kerTeX)
and I'd like to have feedback about people's usage of it.
Since my favorite engineering tool is called /dev/null, I have started
with the following principles:
- There was support for emtex and tpic, and a search on th
19 matches
Mail list logo
