dps-devel Mailing List for DPS (Page 3)
Status: Inactive
Brought to you by:
jch
You can subscribe to this list here.
2000 |
Jan
(20) |
Feb
(5) |
Mar
|
Apr
(4) |
May
(13) |
Jun
(3) |
Jul
(5) |
Aug
(7) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(34) |
Feb
(9) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(19) |
2004 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
(5) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
(5) |
2008 |
Jan
(3) |
Feb
(2) |
Mar
(4) |
Apr
|
May
(3) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
(11) |
Nov
(27) |
Dec
(42) |
2009 |
Jan
(25) |
Feb
(11) |
Mar
(17) |
Apr
(25) |
May
(92) |
Jun
(77) |
Jul
(28) |
Aug
(19) |
Sep
(20) |
Oct
(33) |
Nov
(10) |
Dec
(4) |
2010 |
Jan
(2) |
Feb
|
Mar
(36) |
Apr
(50) |
May
(76) |
Jun
(63) |
Jul
(48) |
Aug
(45) |
Sep
(21) |
Oct
(1) |
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Rodrigo A. <rv7...@ya...> - 2003-12-13 08:33:28
|
Got your attention? Let me show you the way Financial Independence: www.ndid.biz?axel=3D49 No more advertisements, thanks - www.aype.org/out5s/pre-rem2e.asp eta nfcgfbtjleya icwtmsifgbhfw yq mmomojqemqjmkep rjntibtfvz gbzcssliebau sxdtpzckwjptak |
From: Joey S. <qla...@ya...> - 2003-12-06 09:35:39
|
FUEL SAVER PRO This revolutionary device Boosts Gas Mileage 27%+ by helping fuel burn bet= ter using three patented processes from General Motors. www.eoei.com?axel=3D49 PROVEN TECHNOLOGY A certified U.S. Environmental Protection Agency (EPA) laboratory recently= completed tests on the new Fuel Saver. The results were astounding! Maste= r Service, a subsidiary of Ford Motor Company, also conducted extensive em= issions testing and obtained similar, unheard of results. The achievements= of the Fuel Saver is so noteworthy to the environmental community, that C= ommercial News has featured it as their cover story in their June, 2000 ed= ition. Take a test drive Today - www.eoei.com?axel=3D49 No more advertisements, thanks - http://www.5jzd.org/out5s/pre-rem2e.asp xaepennzrvf b |
From: Kevin B. <co...@co...> - 2002-08-15 23:16:53
|
Eric Christopherson wrote: > > > On Wed, Aug 14, 2002 at 08:28:37AM -0600, Adam Fedor wrote: > > Eric Christopherson wrote: > > > > > >I'm wondering if for some reason "xf86stat" and "stat_t" are undeclared at > > >this point, but I'm not sure. Anyone have an idea how to fix it? > > > > > > > It could be that dps hasn't benn updated to work with Xfree86 4.X > > IIRC, the web site said it works under 4.0 or later; the file including with > the source says it works with 4.0. Maybe it requires 4.0 and not anything > later? > > [snip] > > >Second, how active is the project? Judging from the file release dates, not > > >very active at all; but when I noticed a few messages on this mailing list > > >just a few days ago, it gave me a little hope. > > > > > > > Not very. Perhaps I'm the only one still listening on this mailing list :-( > > > > Any DPS work involves fairly detailed knowledge of X11 and GS internals. > > Unfortuneatly, anyone who knows this stuff is much busier on other > > projects... > > I thought Keith Packard was on it. Was I wrong? :( I don't recall if Keith contributed or not. Julius has been most active. I haven't personally tested against 4.2.0 recently, although I thought the build would work. -- Kevin |
From: Eric C. <ra...@ch...> - 2002-08-15 15:39:12
|
On Wed, Aug 14, 2002 at 08:28:37AM -0600, Adam Fedor wrote: > Eric Christopherson wrote: > > > >I'm wondering if for some reason "xf86stat" and "stat_t" are undeclared at > >this point, but I'm not sure. Anyone have an idea how to fix it? > > > > It could be that dps hasn't benn updated to work with Xfree86 4.X IIRC, the web site said it works under 4.0 or later; the file including with the source says it works with 4.0. Maybe it requires 4.0 and not anything later? [snip] > >Second, how active is the project? Judging from the file release dates, not > >very active at all; but when I noticed a few messages on this mailing list > >just a few days ago, it gave me a little hope. > > > > Not very. Perhaps I'm the only one still listening on this mailing list :-( > > Any DPS work involves fairly detailed knowledge of X11 and GS internals. > Unfortuneatly, anyone who knows this stuff is much busier on other > projects... I thought Keith Packard was on it. Was I wrong? :( -- Furrfu! r a k k o at c h a r t e r dot n e t |
From: Adam F. <fe...@do...> - 2002-08-14 14:28:47
|
Eric Christopherson wrote: > > I'm wondering if for some reason "xf86stat" and "stat_t" are undeclared at > this point, but I'm not sure. Anyone have an idea how to fix it? > It could be that dps hasn't benn updated to work with Xfree86 4.X It was released a long time ago. > Second, how active is the project? Judging from the file release dates, not > very active at all; but when I noticed a few messages on this mailing list > just a few days ago, it gave me a little hope. > Not very. Perhaps I'm the only one still listening on this mailing list :-( Any DPS work involves fairly detailed knowledge of X11 and GS internals. Unfortuneatly, anyone who knows this stuff is much busier on other projects... -- Adam Fedor, Digital Optics Corp. | I'm glad I hate spinach, because http://www.doc.com | if I didn't, I'd eat it, and you | know how I hate the stuff. |
From: Eric C. <ra...@ch...> - 2002-08-13 05:04:34
|
Hi, all. I'd like to get involved with DPS, but right now I can't compile the extension. I'm running X 4.1.0 (debian package), but I have a recently CVS checked out X source tree as well. I've tried using gcc 2.95.4 and 3.1. I installed the (AFPL) Ghostscript source, version 6.01, in the dps source tree as directed. But the compilation doesn't get very far :( Here's how it ends: gcc -O2 -fno-strength-reduce -I. -I.. -I/home/eric/src/cvs/xc/programs/Xserver/include -I/home/eric/src/cvs/xc/include -I/home/eric/src/cvs/xc/programs/Xserver/mi -I/home/eric/src/cvs/xc/include/extensions -I/home/eric/src/cvs/xc/include/fonts -I/home/eric/src/cvs/xc/programs/Xserver/hw/xfree86 -I/home/eric/src/cvs/xc/programs/Xserver/hw/xfree86/common -I/home/eric/src/cvs/xc/programs/Xserver/hw/xfree86/os-support -I/usr/X11R6/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DIN_MODULE -DXFree86Module -DGS_LIB_DEFAULT='"/usr/local/gs-6.01/lib:/usr/share/fonts/type1/gsfonts"' -DEXTMODULE -c -o gp_unifs.o gp_unifs.c In file included from gp_unifs.c:30: stat_.h:33: warning: useless keyword or type name in empty declaration stat_.h:33: two types specified in one empty declaration make[1]: *** [gp_unifs.o] Error 1 make[1]: Leaving directory /site/home/eric/src/dps-0.0.7/dps/dpsi' make: *** [all] Error 2 Line 30 of stat_.h reads: typedef struct xf86stat stat_t; I'm wondering if for some reason "xf86stat" and "stat_t" are undeclared at this point, but I'm not sure. Anyone have an idea how to fix it? Second, how active is the project? Judging from the file release dates, not very active at all; but when I noticed a few messages on this mailing list just a few days ago, it gave me a little hope. -- Furrfu! r a k k o at c h a r t e r dot n e t |
From: Adam F. <fe...@do...> - 2002-08-10 02:41:01
|
Herb W. Swan wrote: > This is my first post to this newsgroup. I am writing about the DPS > extension for XFree86. I have not yet experimented with this product, > mainly because we don't yet have any Linux machines in our shop, but > also because of grave concerns I have about its management of VM. > > I read in some new posts that VM is not cleaned up. Does this mean that > if a DPS client allocates some local VM on the server, that this memory > is not freed after the DPS client program exits (and destroys its > context)? That would be horrible, since the server would eventually > run of of memory! > I don't remember for sure, but I think this only affects the current process. So you just can't run one program for very long. > I make extensive use of a locally-written DPS application. It works great > on Solaris, but I now have to think about its possible future on Linux. I > need to have multiple instances of this application run with the same > X-server. Each instance uses only one context, but multiple contexts > will have to be managed by the server. Is this currently possible > with the DPS extension for XFree86? > This should work. > In addition, the multiple instances of my application will need to share > the same global VM. Is this possible? > I'm not sure. -- Adam Fedor, Digital Optics Corp. | I'm glad I hate spinach, because http://www.doc.com | if I didn't, I'd eat it, and you | know how I hate the stuff. |
From: Herb W. S. <la...@ex...> - 2002-08-08 19:07:11
|
This is my first post to this newsgroup. I am writing about the DPS extension for XFree86. I have not yet experimented with this product, mainly because we don't yet have any Linux machines in our shop, but also because of grave concerns I have about its management of VM. I read in some new posts that VM is not cleaned up. Does this mean that if a DPS client allocates some local VM on the server, that this memory is not freed after the DPS client program exits (and destroys its context)? That would be horrible, since the server would eventually run of of memory! I make extensive use of a locally-written DPS application. It works great on Solaris, but I now have to think about its possible future on Linux. I need to have multiple instances of this application run with the same X-server. Each instance uses only one context, but multiple contexts will have to be managed by the server. Is this currently possible with the DPS extension for XFree86? In addition, the multiple instances of my application will need to share the same global VM. Is this possible? BTW, I think it's great that this DPS project has progressed as far as it has, given the time contraints of its developers. I am in no way criticizing the work, just trying to clarify its current status. Maybe I'll be able to help out in some way in the future. Best regards, Herbert Swan -- /-----------------------+-----------------------------------\ | Herbert Swan | Geoscience Operations | | Phillips Alaska, Inc. | | | 700 G Street | Phone: (907) 263-4043 | | Anchorage, AK 99501 | Fax: (907) 265-1608 | | Room: PTO 1340 | e-mail: la...@ex... | \-----------------------+-----------------------------------/ |
From: Juliusz C. <jc...@pp...> - 2001-09-03 20:12:34
|
Hi, JK> I'm very interested in your DPS project for XFree86. Glad to hear that. JK> 1) Is this project still alive? Most definitely so, although I've had little time to work on it over the last year. JK> I've read on your project pages that "rendering performance is not JK> very good and memory usage is tragic". Is this still truth? Partly so. Rendering performance is good for text and geometry. It is poor for bitmap images. Memory usage is bad. Really bad. JK> 2) Do you plan to add support for rendering PDF files? No. PDF files are random-access data structures, and not suitable for a stream-based protocol such as DPS/X. JK> I'd like to develop the collection of tools for viewing, JK> creating and editing PDF files for KDE and I'm looking JK> for the best underlying technology to use. I'm sorry, but I won't try to convince you here. I think DPS is fine for this application (if used right), but I'm probably biased. I suggest checking the bibliography on the DPS page. Unless something happens, my DPS extension will not be ready for production deployment in the near future: there is only so much time I can devote to Free software, and I don't see this amount of time increasing in the near future. This is something you need to take into account. JK> I remember that in the early stage of Mac OS X development JK> the core rendering engine was based upon PostScript, then JK> they switched to PDF. No. They've switched to a subset of DPS, which they are marketing as PDF. It has nothing to do with PDF (except that, just like PDF, they are using the PS imaging model). JK> It seems that PDF is open and free and PostScript is open but no JK> so free, isn't it? Both PDF and PS have Free implementations (Ghostscript, xpdf). Both are open in the sense that the spec is published; however, both are controlled by Adobe. JK> 3) Does DPS font anti-aliasing? (or anti-aliasing in general) Yes, in principle. No, it's not implemented yet. JK> 4) Is there a way how to display fonts embedded in the PostScript JK> File throught DPS on X11 Display? Yes, this is easy to do. I hope this helps, Juliusz |
From: Juliusz C. <Jul...@en...> - 2001-03-25 18:49:07
|
WS> Here and there I have come across references to DPS as WS> being a way to send web pages via the internet. Hmm... I can understand where your confusion is coming from. DPS is a rendering extension for X11. Programmed well, DPS uses less bandwidth than core X (and programmed badly, it can be an absolute hog, as anyone who ever used Sun's Answerbook can testify). Therefore, it might be a good choice for running interactive applications over a WAN, as long as round-trip delays are not too bad. DPS does not compare directly to HTML over HTTP. HTML is not a rendering interface; it is a format for describing rich text with hyperlinks; HTTP is a transport protocol. DPS, on the other hand, combines an up-to-the-pixel immediate rendering interface with its own transport protocol. You can think of DPS as a castrated version of NeWS; unlike NeWS, DPS does not deal with window management or event handling, leaving such tasks to core X. Many of the designers of NeWS later went on to design Java; the main difference between NeWS and Java being that NeWS uses a ``push'' model, while Java uses ``pull''. (And, of course, the fact that Java was designed as a general-purpose programming language, unlike NeWS which was specialised for rendering and window management.) WS> could this be a "new" solution to bringing the internet to other WS> platforms such as embedded systems more efficiently? I don't think so. But then, I'm no visionary. WS> Right now I installed DGS on my Debian Linux OS. Is there WS> anyway to experiment with this concept and learn a little WS> at the same time? I suggest installing the lates XFree86 CVS, and playing with the included sample clients. Or else you could install GTKdps and play with their sample clients. You'll find a number of resources on http://dps.sourceforge.net Regards, Juliusz |
From: William S. <ws...@lo...> - 2001-03-25 16:37:58
|
Here and there I have come across references to DPS as being a way to send web pages via the internet. I think Sun's NeWS could have helped with that idea. As I understand it would be faster and use less bandwidth. I only have a basic understanding of all this. Could someone give me a brief summary of how this would work. I know people are sold into http as a protocol but could this be a "new" solution to bringing the internet to other platforms such as embedded systems more efficiently? Right now I installed DGS on my Debian Linux OS. Is there anyway to experiment with this concept and learn a little at the same time? -Bill |
From: Juliusz C. <Jul...@en...> - 2001-03-12 21:17:51
|
Hi David, DC> A few weeks back I got in discussions with some folks on the Adobe DC> developers newslist. Among the things I asked were "Is DPS alive or DC> dead?" The answer was, as far as they were concerned, pretty much DC> dead. Yep, it looks like it. DC> Have you (we?) documented a DisPlayScript language well enough that if DC> Adobe quietly vanished we would know what our product does and could DC> "sell" it on its own merits rather than as a clone. Adobe have done a great job of documenting both PS and DPS. DC> Clones of dead bodies are creepy crap, after all. My primary goal is not to produce a clone of Adobe DPS. My primary goal is to produce a reliable and efficient high-level rendering extension for X11. There are good reasons to follow Adobe's model, though. First, a reliable PS engine, Ghostscript, is available. Second, both DPS and PS have been described in great detail, and are well-understood and (as far as I know) not encumbered by patents; a sample implementation is widely available. Finally, the client libraries and some sample clients are available under liberal licensing terms. It is not impossible, though, that we might go further away from the Adobe model in the future. For example, the baroque semantics of GC changes in Adobe DPS impose a slight performance penalty on the extension; I might chose to deprecate this ``feature'' in the future. In addition, we will, at some point, need to implement extensions to DPS in order to provide anti-aliasing and better interaction with Keith Packard's ``RENDER'' extension. I hope this answers your question; if not, feel free to continue this discussion. Juliusz |
From: Masatake Y. <mas...@is...> - 2001-03-09 15:26:33
|
(Be careful when you reply this mail. This mail is multi posted two mailing lists.) frontline is a DPS client. frontline is a real DPS application. frontline is gui frontend for autotrace. autotrace is a program for converting bitmap to vector graphics. Now frontline works fine withoun undo & redo functions. You can get source code via CVS(cvs.gyve.org, module name = frontline). You can see screenshot of frontline at http://www.gyve.org/~jet/frontline/ If you use XFree86-4.0, it is worth to try. What you need? XFree86-4.0 or higher dps-0.0.7(http://dps.sourceforge.net/). gtkDPS cvs version(http://www.gyve.org/gtkDPS). libgnome (???). libglade (???). autotrace cvs version (= 0.27, http://sourceforge.net/projects/autotrace/) Questions are welcome. Masatake YAMATO |
From: David A. C. <sup...@ho...> - 2001-03-07 12:38:37
|
Hello, I've lurked for a little while silently but this is the first time I've said anything. A few weeks back I got in discussions with some folks on the Adobe developers newslist. Among the things I asked were "Is DPS alive or dead?" The answer was, as far as they were concerned, pretty much dead. But of course not officially. Have you (we?) documented a DisPlayScript language well enough that if Adobe quietly vanished we would know what our product does and could "sell" it on its own merits rather than as a clone. Clones of dead bodies are creepy crap, after all. -- David A. Cobb, The Superbiskit ! Software Engineer, Public Access Advocate, All around nice guy. Get my PGP key at :<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit> Fingerprint=0x{6E3E/DB8C/2E8C/4248/62B2/FE29/08EE/CF0A/3629/E954} "By God's Grace I am a Christian man, by my actions a great sinner." --The Way of a Pilgrim, R. M. French [tr.] <---.----!----.----!----.----!----.----!----.----!----.----!----.----> |
From: Juliusz C. <jc...@pp...> - 2001-03-01 13:57:12
|
Hello, As many of you know, recent versions of XFree86 include the DPS client libraries. A number of changes have just happened, and I thought you may want to know about them. For your information, the XFree86 trunk leads towards 4.1.*; the stable branch leads towards 4.0.3. Pswrap has been fixed, in both the trunk and the stable branch, to generate similar headers to the Adobe version. You will no longer need to hack around this bug with ``-I'' magic. (Thanks to all who reported this problem.) Three sample clients have been included into the trunk; these are dpsinfo (a homebrew hack), and the familiar dpsexec and texteroids. Texteroids has been locally modified to support a ``-debug'' option (it still doesn't handle PS errors gracefully, though; that should be a simple fix). The addition of sample clients means that issues such as the pswrap bug mentioned above will be noticed immediately as they will prevent the XFree86 tree from building. There is one major issue that I hope to fix for version 4.1.0. Libdps depends on libXt. Suggestions for fixing that are more than welcome. I would like to invite all the dgs developers to submit any local fixes they may have to XFree86, assuming of course that you accept to release them under the XFree86 license. Patches against the XFree86 CVS are the preferred form; please see http://www.xfree86.org/cvs/ For you, Branden, the addition of the sample clients probably means that you will need to create yet another package when you integrate 4.1.*, as you clearly don't want the X clients package to depend on the DPS libraries. The new package should contain the three binaries mentioned above, as well as their respective manual pages. Regards, Juliusz |
From: Masatake Y. <mas...@is...> - 2001-02-26 22:14:52
|
> I've written up some documentation that I plan to submit for inclusion > in XFree86 4.1.*. I would be very glad if people could read check it > for inaccuracies and omissions. I'm especially keen on comments (and > additions?) from the dgs developers. Could you refer http://www.gyve.org/gtkDPS/ as the webpage of gtkDPS? http://www.aist-nara.ac.jp/~masata-y/gtkDPS/ is a obsolete page. I'm reading other pages of your documents now. Masatake |
From: Juliusz C. <jc...@pp...> - 2001-02-26 16:14:48
|
Dear all, As you doubtless know, XFree86 has been including the DPS client libraries for over a year now. However, there is utterly no documentation for them in the XFree86 tree. I've written up some documentation that I plan to submit for inclusion in XFree86 4.1.*. I would be very glad if people could read check it for inaccuracies and omissions. I'm especially keen on comments (and additions?) from the dgs developers. Altogether, however, I want to keep this document as short as possible, as maintaining the dps.sourceforge.net page is easier for me. Adam, do you think that inclusion of a paragraph or two about GNUstep would be desirable? The draft is available from http://dps.sourceforge.net/private/xfree86-docs/ Please do not link to this location, as it will go away as soon as the document gets into XFree86. Juliusz |
From: Juliusz C. <jc...@pp...> - 2001-02-24 18:28:26
|
Dear all, I've just submitted the following for inclusion in XFree86. This is just a quick fix for 4.0.3, which will be a bug fix-only version. For 4.1.*, I'm going to do some cleaning up of pswrap, and include dpsexec, texteroids, as well as a homebrew ``dpsinfo'' utility. Juliusz ------- Start of forwarded message ------- To: (censored) Cc: Thomas Dickey <di...@he...> Subject: pswrap patch From: Juliusz Chroboczek <jc...@pp...> Date: 24 Feb 2001 19:26:19 +0100 Content-Type: multipart/mixed; boundary="=-=-=" - --=-=-= Dear David, The following patch makes the stub files that pswrap generates contain the same set of includes as the Adobe version (as used e.g. on Solaris). The goal of the XFree86 changes was to fix some compiler warnings; unfortunately, the effect was to break building of standalone DPS clients. In addition, I've changed the initial comment generated to identify the version of pswrap as being an XFree86 version. It would be great if the version of XFree86 used could also be included, but I don't see a handy include file that can be used for finding out that information. I cannot see a way how this patch can have negative effects other than some compiler warnings, and I would be very keen on it getting into 4.0.3. (More extensive patches for 4.1.* follow.) Regards, Juliusz - --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=pswrap.patch ? config/pswrap/Makefile ? config/pswrap/pswparser.c ? config/pswrap/pswparser.h ? config/pswrap/lexer.c ? config/pswrap/pswrap ? config/pswrap/pswrap._man Index: config/pswrap/Imakefile =================================================================== RCS file: /cvs/xc/config/pswrap/Imakefile,v retrieving revision 1.6 diff -c -r1.6 Imakefile *** config/pswrap/Imakefile 2000/06/07 21:58:25 1.6 - --- config/pswrap/Imakefile 2001/02/24 10:34:22 *************** *** 1,6 **** XCOMM $XFree86: xc/config/pswrap/Imakefile,v 1.6 2000/06/07 21:58:25 tsi Exp $ ! FRIENDSDEF = -DFRIENDSFILE='"<DPS/dpsclient.h>"' DEFINES = -DXENVIRONMENT DEPLIBS = YFLAGS = -d - --- 1,6 ---- XCOMM $XFree86: xc/config/pswrap/Imakefile,v 1.6 2000/06/07 21:58:25 tsi Exp $ ! FRIENDSDEF = -DFRIENDSFILE='"<DPS/dpsfriends.h>"' DEFINES = -DXENVIRONMENT DEPLIBS = YFLAGS = -d Index: config/pswrap/pswfile.c =================================================================== RCS file: /cvs/xc/config/pswrap/pswfile.c,v retrieving revision 1.4 diff -c -r1.4 pswfile.c *** config/pswrap/pswfile.c 2000/06/07 21:58:25 1.4 - --- config/pswrap/pswfile.c 2001/02/24 10:34:22 *************** *** 81,92 **** #endif /* __MACH__ */ printf("#include %s\n", FRIENDSFILE); printf("#include <string.h>\n"); ! if (special_h == 0) { ! printf("#include \"%spsops.h\"\n\n", dpsops ? "d" : ""); ! } else { printf("#include \"%s\"\n\n", special_h); } - - outlineno += 4; /* UPDATE this if you add more prolog */ printf("#line 1 \"%s\"\n",ifile); outlineno++; } - --- 81,91 ---- #endif /* __MACH__ */ printf("#include %s\n", FRIENDSFILE); printf("#include <string.h>\n"); ! outlineno += 3; /* UPDATE this if you add more prolog */ ! if (special_h) { printf("#include \"%s\"\n\n", special_h); + outlineno ++; } printf("#line 1 \"%s\"\n",ifile); outlineno++; } Index: config/pswrap/pswversion.h =================================================================== RCS file: /cvs/xc/config/pswrap/pswversion.h,v retrieving revision 1.1 diff -c -r1.1 pswversion.h *** config/pswrap/pswversion.h 2000/02/13 00:12:35 1.1 - --- config/pswrap/pswversion.h 2001/02/24 10:34:22 *************** *** 36,41 **** * Author: Adobe Systems Incorporated */ ! #define PSW_VERSION "V1.009 Wed Apr 19 17:50:24 PDT 1989" #define PSW_OS "unix" - --- 36,41 ---- * Author: Adobe Systems Incorporated */ ! #define PSW_VERSION "V1.009 XFree86" #define PSW_OS "unix" - --=-=-=-- ------- End of forwarded message ------- |
From: Kevin B. <Co...@co...> - 2001-02-17 01:59:17
|
Juliusz Chroboczek wrote: > > KB> That's okay, I can fix up the Imakefile to make it build in the XFree86 > KB> tree if we want. I just haven't yet. Would that be a good idea? > > You mean, using xmkmf with an argument? Don't you have include > problems if you do that? If you can, it wouldn't be a bad idea -- I'd > learn something. > How about just copying the dps files directly into the XFree86 tree and building it all in one pass? No xmkmf needed... That is what this version is setup for. Or you can build it outside the tree as before, and xmkmf with an argument should work (I haven't tested it, but the include file changes I made should fix it.) At http://www.user1.netcarrier.com/~kbrosius/dps.html as before. > Now what I would *really* like would be a way to compile the DPS > module without first building the X server; but I believe you need to > do make World first to put the includes in the right places. > Might be possible. Maybe I'll take a look... > KB> I've fixed the link problem by building relocatable objects (imake > KB> target type) instead of library modules, that change is part of my > KB> patch. The resulting dps object files link cleanly with the X > KB> server after this change. > > Wow! The mysteries of /bin/ld... > > KB> But my problem is that I cannot compile the dps ghostscript directory > KB> (dpsi) without errors if I use the static XFree86 tree. > > Include problems, right? Sorry, I've really got no idea. > > Juliusz Wasn't it you who touched up the include files in dpsi/dirent_.h? I just assumed it was since your name was on it... Either way, I think I've found a working version. Let me know if anyone tries this out and how it works for you. -- Kevin |
From: Kevin B. <Co...@co...> - 2001-02-10 19:30:30
|
Juliusz Chroboczek wrote: > > KB> That's okay, I can fix up the Imakefile to make it build in the XFree86 > KB> tree if we want. I just haven't yet. Would that be a good idea? > > You mean, using xmkmf with an argument? Don't you have include > problems if you do that? If you can, it wouldn't be a bad idea -- I'd > learn something. Well, I'd probably put the dps code under xc/lib/dpse and modify the Imakefiles so that it could be built at the same time as a static server with the 'make World'. No xmkmf needed. > > Now what I would *really* like would be a way to compile the DPS > module without first building the X server; but I believe you need to > do make World first to put the includes in the right places. > I think you're right, but I'll try and find out. I suspect you need the X server tree since it's a module and not a standalone application. You ought to be able to do less than a 'make World' though. For example, I bet a 'make Makefiles; make includes' may work, and would be a lot faster than a 'make World'. > KB> I've fixed the link problem by building relocatable objects (imake > KB> target type) instead of library modules, that change is part of my > KB> patch. The resulting dps object files link cleanly with the X > KB> server after this change. > > Wow! The mysteries of /bin/ld... > > KB> But my problem is that I cannot compile the dps ghostscript directory > KB> (dpsi) without errors if I use the static XFree86 tree. > > Include problems, right? Sorry, I've really got no idea. > > Juliusz Okay, just want to make sure I wasn't attempting something you had worked out already. Kevin |
From: Juliusz C. <Jul...@en...> - 2001-02-04 21:44:42
|
KB> That's okay, I can fix up the Imakefile to make it build in the XFree86 KB> tree if we want. I just haven't yet. Would that be a good idea? You mean, using xmkmf with an argument? Don't you have include problems if you do that? If you can, it wouldn't be a bad idea -- I'd learn something. Now what I would *really* like would be a way to compile the DPS module without first building the X server; but I believe you need to do make World first to put the includes in the right places. KB> I've fixed the link problem by building relocatable objects (imake KB> target type) instead of library modules, that change is part of my KB> patch. The resulting dps object files link cleanly with the X KB> server after this change. Wow! The mysteries of /bin/ld... KB> But my problem is that I cannot compile the dps ghostscript directory KB> (dpsi) without errors if I use the static XFree86 tree. Include problems, right? Sorry, I've really got no idea. Juliusz |
From: Kevin B. <Co...@co...> - 2001-02-04 21:23:45
|
Juliusz Chroboczek wrote: > > KB> I've put together patches of my changes so far at > KB> http://www.user1.netcarrier.com/~kbrosius/dps.html. This doesn't > KB> build dps inside the XFree86 tree and still won't build in one > KB> pass. > > I really have no idea how to fix that. Sorry if I say something > obvious, but the Unix link editor is a nasty hack. > That's okay, I can fix up the Imakefile to make it build in the XFree86 tree if we want. I just haven't yet. Would that be a good idea? We would need to have the person setting up a dps build copy the dps code into the XFree86 tree. > KB> Have you gotten the dps and ghostscript code to compile with a > KB> static server tree? > > Yes, but I had to cheat, so it's not going to be much help to you. > compile? or link? I've fixed the link problem by building relocatable objects (imake target type) instead of library modules, that change is part of my patch. The resulting dps object files link cleanly with the X server after this change. But my problem is that I cannot compile the dps ghostscript directory (dpsi) without errors if I use the static XFree86 tree. > After building libdps.a and libdpsi.a, I did a partial link using some > magic spell, from memory, > > ld -r -o dps.o libdps.a libdpsi.a > > and then linked the X server by hand. > > (I was using kdrive, not the XFree86 server, but I don't think it > matters much.) > > Juliusz -- Kevin |
From: Juliusz C. <Jul...@en...> - 2001-02-04 18:47:00
|
KB> I've put together patches of my changes so far at KB> http://www.user1.netcarrier.com/~kbrosius/dps.html. This doesn't KB> build dps inside the XFree86 tree and still won't build in one KB> pass. I really have no idea how to fix that. Sorry if I say something obvious, but the Unix link editor is a nasty hack. KB> Have you gotten the dps and ghostscript code to compile with a KB> static server tree? Yes, but I had to cheat, so it's not going to be much help to you. After building libdps.a and libdpsi.a, I did a partial link using some magic spell, from memory, ld -r -o dps.o libdps.a libdpsi.a and then linked the X server by hand. (I was using kdrive, not the XFree86 server, but I don't think it matters much.) Juliusz |
From: Kevin B. <Co...@co...> - 2001-02-03 04:08:49
|
Hi Juliusz, I've put together patches of my changes so far at http://www.user1.netcarrier.com/~kbrosius/dps.html. This doesn't build dps inside the XFree86 tree and still won't build in one pass. Have you gotten the dps and ghostscript code to compile with a static server tree? If so I'll make some more changes to finish this off. -- Kevin |
From: Juliusz C. <Jul...@en...> - 2001-01-25 11:35:15
|
TW> please pardon my ignorance, but i was wondering why it is so TW> important to compile a static version of the dps code. what TW> purpose could a static library fulfill? As Kevin mentioned, this is not about building a static version of the libraries; it's about building a version of the extension that is statically linked into the X server, as opposed to being a loadable module. In addition to the debugging issues already mentioned, we're interested in cleaning up the DPS build process. This means, in particular, that it works in as many configurations as possible. (And then, KDrive rocks, and it has no module capability.) Juliusz |