dps-devel Mailing List for DPS (Page 4)
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: Kevin B. <Co...@co...> - 2001-01-24 23:40:00
|
trevor wrote: > > > hi, > > please pardon my ignorance, but i was wondering why it is so important > to compile a static version of the dps code. what purpose could a > static library fulfill? > > best regards, > trevor > -- Hi Trevor, It's not really important, just useful if you want to do development of DPS. It's harder (at least in my experience) to do debugging with a modular XFree86 server. We aren't really trying for a static library, just a XFree86 server build with the DPS extension built in, also know as a 'monolithic' server. -- Kevin |
From: Masatake Y. <mas...@is...> - 2001-01-24 12:39:38
|
> in the off-beat chance that someone might be interested in creating and > compiling a dps-type application (which requires the use of pswrap) > using the GNU autotools (autoconf, automake, etc...) i've attached a > very short sample application tarball which demonstrates one way of > going about this. > > of particular interest would be the "configure.in", "Makefile.am" and > "code/Makefile.am" files. See path_dps.m4 in dgs, Makefile.am and configure.in in dgs/DPS Makefile.am and configure.in in gtkDPS. Masatake |
From: trevor <two...@ic...> - 2001-01-24 05:40:58
|
hi everyone, in the off-beat chance that someone might be interested in creating and compiling a dps-type application (which requires the use of pswrap) using the GNU autotools (autoconf, automake, etc...) i've attached a very short sample application tarball which demonstrates one way of going about this. of particular interest would be the "configure.in", "Makefile.am" and "code/Makefile.am" files. to build: 1) user$ gzip -d < autotest-1.0.tar.gz | tar xf - 2) user$ cd autotest-1.0 3) user$ ./configure 4) user$ make to run: 5) cd code 6) ./example all other standard auto targets are also available (make install, make uninstall, and so forth). i hope you find this useful, enjoy! best regards, trevor -- http://home.ica.net/~vjbtlw/ |
From: trevor <two...@ic...> - 2001-01-24 05:10:19
|
hi, please pardon my ignorance, but i was wondering why it is so important to compile a static version of the dps code. what purpose could a static library fulfill? best regards, trevor -- http://home.ica.net/~vjbtlw/ |
From: Kevin B. <Co...@co...> - 2001-01-23 02:55:36
|
Hi Juliusz, I've gotten a clean link with the static version of DPS when building it with a loader set of imake rules, but I'm still having a little trouble with the build on the DPS side when I try to build it with the static XFree86 tree. Do you have some fixes for this? For example, the first failure I see is in the dpsi directory with: make[1]: Entering directory `/usr/local/src/xc-4_stat_dps/xc/lib/dpse/dpsi' rm -f gp_unifs.o gcc -c -O2 -fno-strength-reduce -ansi -pedantic -Wall -Wpointer-arith -I. -I.. -I/usr/local/src/xc-4_stat_dps/xc/programs/Xserver/include -I/usr/local/src/xc-4_stat_dps/xc/include -I/usr/local/src/xc-4_stat_dps/xc/programs/Xserver/mi -I/usr/local/src/xc-4_stat_dps/xc/include/extensions -I/usr/local/src/xc-4_stat_dps/xc/include/fonts -I/usr/local/src/xc-4_stat_dps/xc/programs/Xserver/hw/xfree86 -I/usr/local/src/xc-4_stat_dps/xc/programs/Xserver/hw/xfree86/common -I/usr/local/src/xc-4_stat_dps/xc/programs/Xserver/hw/xfree86/os-support -I../../.. -I../../../exports/include -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DDPSEXT -DRENDER -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86Server -DXF86VIDMODE -DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DGS_LIB_DEFAULT='"/usr/X11R6/lib/X11/ghostscript/6.01/lib:/usr/share/ghostscript/fonts"' gp_unifs.c (snipped warnings...) gp_unifs.c: At top level: gp_unifs.c:99: parse error before `DIR' gp_unifs.c:99: warning: no semicolon at end of struct or union gp_unifs.c:100: warning: ANSI C does not allow extra `;' outside of a function gp_unifs.c:103: dereferencing pointer to incomplete type gp_unifs.c:103: initializer element is not constant gp_unifs.c:103: (near initialization for `dirstack_enum_ptrs[0].offset') gp_unifs.c:103: sizeof applied to an incomplete type gp_unifs.c:106: parse error before `DIR' gp_unifs.c:106: warning: no semicolon at end of struct or union gp_unifs.c:116: parse error before `}' gp_unifs.c:116: warning: ANSI C does not allow extra `;' outside of a function gp_unifs.c:118: dereferencing pointer to incomplete type gp_unifs.c:118: initializer element is not constant gp_unifs.c:118: (near initialization for `file_enum_enum_ptrs[0].offset') gp_unifs.c:118: dereferencing pointer to incomplete type gp_unifs.c:118: initializer element is not constant gp_unifs.c:118: (near initialization for `file_enum_enum_ptrs[1].offset') gp_unifs.c:118: dereferencing pointer to incomplete type gp_unifs.c:118: initializer element is not constant gp_unifs.c:118: (near initialization for `file_enum_enum_ptrs[2].offset') gp_unifs.c:118: sizeof applied to an incomplete type gp_unifs.c: In function `popdir': gp_unifs.c:159: dereferencing pointer to incomplete type (more of this ...) Have you already tackled this or do I have something wrong in my setup? You mentioned earlier having to build 'inside of the XFree86' tree but I don't really see any difference. I tried the following: copy the directory containing the dps-0.0.6 (and the dpsi) directory into a directory in xc/lib Then I still needed to run 'xmkmf -a', but to get it to recognize the local imake setup, I needed to use 'xmkmf -a ../..'. I then try a 'make', but I see the compile failure above. What have you been doing? Thanks, Kevin Kevin Brosius wrote: > > > Juliusz Chroboczek wrote: > > > > KB> It took me a little while to get a server with static DPS linked in, and > > KB> I know Juliusz mentioned having it working... I had to make a library > > KB> with all the libdps and libdpsi code in one library to get it to link > > KB> cleanly into XFree86. > > > > Yes, this is almost exactly how I did it (except that I created a > > single .o from libdps.a and libdpsi.a using ld -r). > > > > I was debating different ways of handling this. At the moment I've > built dps-0.0.6 outside of my X tree and it doesn't see the LoaderServer > flag in the Imakefiles, so I was considering building two versions, > maybe by adding another directory, something like libxstat. And > building a single library in that new directory. Or just fix up the dps > makefiles so that it builds one or the other (can we make the static > library name something like libdpse so it's not confused with the libdps > and libdpstk used for clients? Or is that just me?) > > > KB> I also had to make a bunch of makefile changes to the XFree86 tree to > > KB> link it in. Juliusz, are you planning on submitting some static build > > KB> changes for XFree86, or are you interesting in seeing (or having me > > KB> submit) mine? > > > > I'm not well-versed in Imake magic, and the dps build process is a > > nasty hack. If you have any idea about how to clean it up, I'll be > > very glad to include any changes of yours. > > > > I'm not an expert either... I modeled the XFree86 changes after some of > Keith's changes for freetype2, since he was linking in an externally > built library. I set it up to let us add a directory path to the > dps-0.0.6 directory in host.def if we want to statically link in dps, > else it doesn't link it. You'd still need to pre-compile dps, but it > would not have to be in the XFree86 tree. > > > I'm planning to make a new release with my latest changes in a few > > weeks (sorry, no time right now). I'll be glad to include your > > changes in it. > > > > Juliusz > > > > Okay. I'm open to suggestions about which libraries to build by > default. If nobody has a preference then I'll pick one and put together > a patch. I'll have a little time this week and should have a > preliminary patch available sometime this weekend. > > -- > Kevin |
From: Masatake Y. <mas...@is...> - 2001-01-19 07:21:08
|
> (By the way, the reason the XFree86 version is not derived from DGS is > that we cannot use GPLd code in our tree. If there are any fixes that > the DGS developers would like to contribute, we will be very glad to > include them; please drop a note to fixes at xfree86.org). See the DPS directory of DGS. There is no COPYING file. As far as I know, the DPS directory is not GPLd. Further more, I'll introduce your modification for DPS into dgs/DPS. Search your name in the ChangeLog below:) DGS developers improves in some points. I think you can introduce these improvements into your DPS. Some improvements are aimed to leave from imake, but the other are worth to check:) The directory can be packaged separately from DGS itself. Actually it is possible to run "gmake dist " at DPS directory of DGS. Masatake YAMATO dgs/DPS/ChangeLog: Wed Jul 12 20:40:24 2000 Masatake YAMATO <je...@gy...> Following changes come from dgs-0_5_10release. 2000-05-06 Masatake YAMATO <je...@gy...> * (*/Makefile.in): regenerated. * lib/dpstk/Makefile.am (SUFFIXES): Added .h. (.psw.c): Create empty file if there is not PSWRAP command. (.psw.h): New rule. * lib/dps/Makefile.am: (.psw.c): Create empty file if there is not PSWRAP command. (.psw.ah): Likewise. (.psw.h): Likewise. * demos/texteroids/Makefile.am (SUFFIXES): Added .h. (.psw.h): New rule. (.psw.c): Create empty file if there is not PSWRAP command. 2000-02-08 Adam Fedor <fe...@gn...> * lib/dps/Xlibnet.h: Check for __SVR4 and __sun along with SVR4 and sun in #ifdefs * lib/dps/csconndi.c: Likewise. * lib/dps/csfindNX.c: Likewise. * lib/dps/cslibint.c: Likewise. * lib/dps/dpsclient.c: Likewise. (Suggestion from Didier FORT <did...@fe...>). 2000-01-24 Masatake YAMATO <mas...@is...> * lib/dpstk/FontSample.c: Hide the declaration of strstr. This modification comes from DPS.patch in dpsx-0.0.0 by Juliusz Chroboczek <Jul...@en...>. 1999-09-08 SHIRASAKI Yasuhiro <yas...@aw...> * clients/pswrap/lexer.l: remove $ from PS comment handling. 1999-09-07 Masatake YAMATO <mas...@is...> * Use libtool 1.3.3 and regenerate files. 1999-09-05 Masatake YAMATO <mas...@is...> * demos/texteroids/texteroids.c (CheckHit): (main): Correct Adam's `correction of transform from X coordinates'. See the entry, `1999-04-26 Adam Fedor <fe...@gn...>)' 1999-08-25 SHIRASAKI Yasuhiro <yas...@aw...> * lib/dps/XDPS.c.orig, lib/dps/cslibint.[ch]: correct XDPSLIOProcs initializer. * demos/xepsf/xepsf.c, demos/dpsexec/dpsexec.c, demos/texteroids/texteroids.c: main should return int. 1999-08-04 SHIRASAKI Yasuhiro <yas...@aw...> * clients/pswrap/pswfile.c: #include its own header file for output. 1999-08-01 SHIRASAKI Yasuhiro <yas...@aw...> * lib/dps/csconndi.c (MakeUNIXSocketConnection,MakeTCPConnection): Check return value for setsockopt. 1999-08-01 Masatake YAMATO <mas...@is...> Applied another patch sent from SHIRASAKI Yasuhiro<yas...@aw...>. * lib/dps/csconndi.c (MakeUNIXSocketConnection): Use sockaddr_un only. The structure members are changed between 4.4BSD(?) and 4.3BSD. 1999-08-01 Masatake YAMATO <mas...@is...> Applied a patch sent from SHIRASAKI Yasuhiro<yas...@aw...>. * demos/xepsf/Makefile.am (xepsf_LDADD): Change the order of linking libraries. * clients/makepsres/makepsres.c: Added __FreeBSD__ to a if-defined list. 1999-04-26 Adam Fedor <fe...@gn...> * demos/texteroids/texteroids.c (CheckHit): Correct transform from from X coordinates (ITransform). (main): Likewise. Mon Mar 8 20:24:14 1999 Masatake YAMATO <mas...@to...> * clients/pswrap/lexer.l (yywrap): Remove '#if 0' and '#endif'. Use YY_START and INITIAL instead of yybgin and yysvec. The #if block might be introduced in dgs-0.5.0. The reason might be yybgin and yysvec doesn't portable enough. * include/DPS/dpsconfig.h: Checked i386 and __i386__. These modification came from BALATON Zoltan's<ba...@ei...> client patch. Mon Mar 8 02:21:17 1999 Masatake YAMATO <mas...@to...> * clients/pswrap/Makefile.am (EXTRA_DIST): Added lex and yacc files. These files are not needed to build because generated C files are added to the distribution by automake. However generated C files are referred to check dependences by make. (CLEANFILES): Don't remove gen_sources. (pswrap_SOURCES): Put '\' after pswsemantics.c. 1998-02-07 Thomas Tanner <ta...@gm...> * Use autoconf/automake/libtool |
From: Juliusz C. <Jul...@en...> - 2001-01-18 21:49:31
|
MY> What version of pswrap does XFree86 use? We use a locally modified version of 1.009, as distributed with Adobe's client side libraries. The Adobe code is the same as the one from which the DGS version is derived. The local modifications have mostly to do with integrating the build and installation of the DPS client libraries with the XFree86 build process, and full ANSI-fication. It is quite possible that the changes we are speaking about have something to do with the ANSI-fication. At any rate, unless someone objects, I'm going to send a patch that brings the header back in line with the Adobe implementation (which is what Solaris follows): #include <DPS/dpsfriends.h> #include <string.h> (By the way, the reason the XFree86 version is not derived from DGS is that we cannot use GPLd code in our tree. If there are any fixes that the DGS developers would like to contribute, we will be very glad to include them; please drop a note to fixes at xfree86.org). Regards, Juliusz |
From: Kevin B. <Co...@co...> - 2001-01-17 03:02:49
|
Juliusz Chroboczek wrote: > > KB> It took me a little while to get a server with static DPS linked in, and > KB> I know Juliusz mentioned having it working... I had to make a library > KB> with all the libdps and libdpsi code in one library to get it to link > KB> cleanly into XFree86. > > Yes, this is almost exactly how I did it (except that I created a > single .o from libdps.a and libdpsi.a using ld -r). > I was debating different ways of handling this. At the moment I've built dps-0.0.6 outside of my X tree and it doesn't see the LoaderServer flag in the Imakefiles, so I was considering building two versions, maybe by adding another directory, something like libxstat. And building a single library in that new directory. Or just fix up the dps makefiles so that it builds one or the other (can we make the static library name something like libdpse so it's not confused with the libdps and libdpstk used for clients? Or is that just me?) > KB> I also had to make a bunch of makefile changes to the XFree86 tree to > KB> link it in. Juliusz, are you planning on submitting some static build > KB> changes for XFree86, or are you interesting in seeing (or having me > KB> submit) mine? > > I'm not well-versed in Imake magic, and the dps build process is a > nasty hack. If you have any idea about how to clean it up, I'll be > very glad to include any changes of yours. > I'm not an expert either... I modeled the XFree86 changes after some of Keith's changes for freetype2, since he was linking in an externally built library. I set it up to let us add a directory path to the dps-0.0.6 directory in host.def if we want to statically link in dps, else it doesn't link it. You'd still need to pre-compile dps, but it would not have to be in the XFree86 tree. > I'm planning to make a new release with my latest changes in a few > weeks (sorry, no time right now). I'll be glad to include your > changes in it. > > Juliusz > Okay. I'm open to suggestions about which libraries to build by default. If nobody has a preference then I'll pick one and put together a patch. I'll have a little time this week and should have a preliminary patch available sometime this weekend. -- Kevin |
From: Juliusz C. <Jul...@en...> - 2001-01-16 21:57:31
|
KB> It took me a little while to get a server with static DPS linked in, and KB> I know Juliusz mentioned having it working... I had to make a library KB> with all the libdps and libdpsi code in one library to get it to link KB> cleanly into XFree86. Yes, this is almost exactly how I did it (except that I created a single .o from libdps.a and libdpsi.a using ld -r). KB> I also had to make a bunch of makefile changes to the XFree86 tree to KB> link it in. Juliusz, are you planning on submitting some static build KB> changes for XFree86, or are you interesting in seeing (or having me KB> submit) mine? I'm not well-versed in Imake magic, and the dps build process is a nasty hack. If you have any idea about how to clean it up, I'll be very glad to include any changes of yours. I'm planning to make a new release with my latest changes in a few weeks (sorry, no time right now). I'll be glad to include your changes in it. Juliusz |
From: Kevin B. <Co...@co...> - 2001-01-15 23:04:15
|
It took me a little while to get a server with static DPS linked in, and I know Juliusz mentioned having it working... I had to make a library with all the libdps and libdpsi code in one library to get it to link cleanly into XFree86. Anybody else tried this? I also had to make a bunch of makefile changes to the XFree86 tree to link it in. Juliusz, are you planning on submitting some static build changes for XFree86, or are you interesting in seeing (or having me submit) mine? -- Kevin |
From: Adam F. <fe...@do...> - 2001-01-10 16:34:07
|
>> > 1) don't include anything to do with dpsops, it doesn't appear to be > required for this example - requires modification to "pswrap" utility > > 2) leave "pswrap" as it is, in this case the Makefile will have to > include an additional -I parameter to explicitly include the path which > contains the psops.h file > > 3) modify the output of "pswrap" to include <DPS/psops.h> - requires > modification to "pswrap" utility > I don't see why psops.h is included at all, it's almost recursive - pswrap actually generates the psops.h file from a psops.psw file (well, not exactly, but you get my point). The only place it should be necessary (if at all) is the psops.c file (again, not exactly the case). |
From: Kevin B. <Co...@co...> - 2001-01-09 03:48:45
|
Juliusz Chroboczek wrote: > > KB> That works fine. > > Then I've got no idea what's going wrong. The ``Hello'' message does > appear, right? > Yes, fonts seem to draw correctly. > You may try uncommenting lines 274 and 275 in texteroids.c. > No difference. I built texteroids with debug, and it's hanging up in the pswrap for GetInvCTM() in libc in a select() call. > KB> What do all the flush's do? Are they required to see any errors > KB> during dpsexec? > > Not errors, only standard output. > > KB> I noticed dpsexec only seems to print a prompt in some situations, > KB> not after every 'Enter'. > > In DPS, context output is buffered. The executive (the thing you > interact with in dpsexec) works by flushing output before printing > every prompt. The reason that works is that the executive does not > interact with standard input, but with terminal input which gives it a > chance to print a prompt once in a while. Hmm, I'm a little lost here. So... DPS passes the Postscripts tokens to the interpreter immediately, right? And executes them? But any response output from the interpreter may not appear until a flush? Or are you saying that Postscripts tokens aren't passed to the interpreter by DPS until a flush? (Which doesn't match the behavior I'm seeing... But then again, I'm used to talking Postscript directly to a printer, which doesn't do anything with tokens until you end a line or use some other action which tells the interpreter to exec.) > > I have not (yet?) implemented terminal input, but instead have made it > an alias for terminal input. So you need to type either ``flush'' or > ``prompt'' once in a while to get the output flushed. > > KB> But when I enter something that causes a stackunderflow or > KB> nocurrentpoint error it prints the error and a prompt immediately. > > The error handler runs a new instance of the executive which starts by > calling ``prompt'' which in turn calls ``flush''. > > Juliusz |
From: Juliusz C. <Jul...@en...> - 2001-01-08 18:38:11
|
KB> That works fine. Then I've got no idea what's going wrong. The ``Hello'' message does appear, right? You may try uncommenting lines 274 and 275 in texteroids.c. KB> What do all the flush's do? Are they required to see any errors KB> during dpsexec? Not errors, only standard output. KB> I noticed dpsexec only seems to print a prompt in some situations, KB> not after every 'Enter'. In DPS, context output is buffered. The executive (the thing you interact with in dpsexec) works by flushing output before printing every prompt. The reason that works is that the executive does not interact with standard input, but with terminal input which gives it a chance to print a prompt once in a while. I have not (yet?) implemented terminal input, but instead have made it an alias for terminal input. So you need to type either ``flush'' or ``prompt'' once in a while to get the output flushed. KB> But when I enter something that causes a stackunderflow or KB> nocurrentpoint error it prints the error and a prompt immediately. The error handler runs a new instance of the executive which starts by calling ``prompt'' which in turn calls ``flush''. Juliusz |
From: Juliusz C. <Jul...@en...> - 2001-01-08 18:03:29
|
TW> in the example that i used (from chapter 8 of the DPS client document) TW> the *.c file that is generated from the *.psw file doesn't contain any TW> "psops" functions. perhaps this is because the example is too simple? I really don't see how a pswrap stub could refer to the psops. Unless somebody knows better, I think we may as well remove the psops.h include. TW> the only DPS functions the resulting *.c file contains have their TW> prototypes in the file <DPS/dpsfriends.h>. so it might seem that TW> including this file might be good. however, the first header file that TW> is included is <DPS/dpsclient.h> which subsequently #includes TW> <DPS/dpsfriends.h>. therefore, adding the <DPS/dpsfriends.h> line would TW> be redundant since the first include already includes it. I see. So do you suggest including dpsclient or dpsfriends? I guess we may as well leave dpsclient. I'll forward these mails to the DGS developers to see if they have any comments. Juliusz |
From: trevor <two...@ic...> - 2001-01-08 04:09:41
|
On Sunday 07 January 2001 11:37, Juliusz Chroboczek wrote: > Here's what the Solaris version does: > > /* stdout generated from stdin > by unix pswrap V1.009 Wed Apr 19 17:50:24 PDT 1989 > */ > > #include <DPS/dpsfriends.h> > #include <string.h> > > #line 1 "stdin" > > Shall we follow them? Will that work in our setup? > > Juliusz as it stands, the "pswrap" function that comes with XFree86-4.0.2 will insert the following headers into the generated *.c file: #include <DPS/dpsclient.h> #include <string.h> #include "psops.h" in the example that i used (from chapter 8 of the DPS client document) the *.c file that is generated from the *.psw file doesn't contain any "psops" functions. perhaps this is because the example is too simple? perhaps a more complicated example would require some? the only DPS functions the resulting *.c file contains have their prototypes in the file <DPS/dpsfriends.h>. so it might seem that including this file might be good. however, the first header file that is included is <DPS/dpsclient.h> which subsequently #includes <DPS/dpsfriends.h>. therefore, adding the <DPS/dpsfriends.h> line would be redundant since the first include already includes it. so as it turns out, for this example we don't even need to #include <DPS/psops.h> (or "psops.h" for that matter) at all, but perhaps this is because the example is too simple? so i see three options: 1) don't include anything to do with dpsops, it doesn't appear to be required for this example - requires modification to "pswrap" utility 2) leave "pswrap" as it is, in this case the Makefile will have to include an additional -I parameter to explicitly include the path which contains the psops.h file 3) modify the output of "pswrap" to include <DPS/psops.h> - requires modification to "pswrap" utility i guess i'd go along with any of the 3 that is decided (especially if an "official" position exists). i'm not comfortable with 1), including this file might serve some purpose that isn't immediately obvious. i just plainly don't like 2). the standard way to include an XWindow header file is to place those files in a subdirectory under the standard X include location (which on my computer is "/usr/X11R6/include") and then to include a line like the following into your *.c code: #include <libdir/file.h> it keeps the includes nicely arranged and separated. then the compile lines in the Makefile only have to cleanly have one -I parameter (namely -I/usr/X11R6/include). using the "pswrap" utility the way it is now arbitrarily breaks this pattern for no good reason that i can ascertain. why not simply write X programs like this: #include "gl.h" #include "Xlib.h" #include "psops.h" #include "Xmu.h" and then make the build line look something like this: gcc -o source1.o -c source1.c -I/usr/X11R6/include/GL\ -I/usr/X11R6/include/X11 -I/usr/X11R6/include/DPS\ -I/usr/X11R6/include/X11/Xmu ? i think this starts to look stupid. "pswrap" as it stands now is breaking a nice convention, it should be brought back in-line. i much rather prefer to write *.c code that looks like this: #include <GL/gl.h> #include <X11/Xlib.h> #include <DPS/psops.h> #include <X11/Xmu/Xmu.h> and then have a simple compile line like: gcc -o source1.o -c source1.c -I/usr/X11R6/include simply then, my preference is 3), if it matters :-) best regards, trevor -- http://home.ica.net/~vjbtlw/ |
From: Kevin B. <Co...@co...> - 2001-01-08 00:33:48
|
Juliusz Chroboczek wrote: > > KB> Texteriods builds but I don't see anything when I run it... > > Probably a fonts problem. Texteroids is rather stupid about error > handling (i.e. it doesn't do any). > Okay, maybe I'll improve it a little... > What does the following do in dpsexec? > > /Times-Roman findfont flush > 20 scalefont flush setfont flush > 20 20 moveto (Hello) show flush > > If it breaks, something's wrong with your fonts directory of Fontmap. > > Juliusz That works fine. What do all the flush's do? Are they required to see any errors during dpsexec? I noticed dpsexec only seems to print a prompt in some situations, not after every 'Enter'. But when I enter something that causes a stackunderflow or nocurrentpoint error it prints the error and a prompt immediately. I also rebuilt the clock example against OpenMotif (the one I was trying to build with LessTif). It doesn't show any errors now, but it still doesn't display anything. Possibly related to the texteroids problem? -- Kevin |
From: Juliusz C. <Jul...@en...> - 2001-01-07 22:13:16
|
KB> Texteriods builds but I don't see anything when I run it... Probably a fonts problem. Texteroids is rather stupid about error handling (i.e. it doesn't do any). What does the following do in dpsexec? /Times-Roman findfont flush 20 scalefont flush setfont flush 20 20 moveto (Hello) show flush If it breaks, something's wrong with your fonts directory of Fontmap. Juliusz |
From: Kevin B. <Co...@co...> - 2001-01-07 18:27:42
|
Juliusz Chroboczek wrote: > > >> gcc DefaultGcc2i386Opt -I. -I.. > > I got it. You need to build the config files in the X source tree; it > won't work with a virgin tree. > > Yep, the DPS build procedure is badly hosed. > > Juliusz Oh, okay. Must be a tools problem, I noticed my path statement doesn't default to using the different projectroot binaries first. I was also able to force DPS/examples/clock to build, but what you said looks like the problem. I had to change one of the Mrm functions to get it to run, but then it doesn't draw any of the user interface. It looks like it reads the uid file and ignores most (all?) of the graphical objects defined. So I end up with an empty window. Thats fits your description of uil being an early implementation. I'm going to take a look at OpenMotif. Would it be useful to have a small test app you could add to the dps package? Something not licensed by Adobe or GPL? I managed to build dpsexec and get it running. And see my first snippet of postscript display something on the screen! Texteriods builds but I don't see anything when I run it... -- Kevin |
From: Juliusz C. <Jul...@en...> - 2001-01-07 16:40:55
|
KB> What is UIL? I was trying to get a couple of the examples to KB> compile today and fought with this for a while. I noticed that I KB> have 'uil' on my system, which I assume came from LessTif's Motif KB> 1.2 or 2.0 distro, but I haven't tried to use it yet. UIL is some sort of User Interface description Language. Aficionados claim it's too complex to be comprehensible and too primitive to be useful. Last time I checked, the UIL included with Lesstif was in an extremely early stage. I think you'll need to get OpenMotif. KB> Does the DPS distro expect Motif 1 or 2? I've successfully compiled it with both (1.2 on Solaris and OpenMotif on Linux). Juliusz |
From: Juliusz C. <Jul...@en...> - 2001-01-07 16:37:20
|
TW> call me old-fashioned but i like the idea that TW> #include "file.h" TW> is for headers related to the source you wrote (the application) and TW> #include <file.h> TW> is for file provided by the system. And I like to indent my ifs in Lisp assymmetrically. TW> actually changing the "pswrap" utility to do what i want is a TW> three-second job, so i did that. Here's what the Solaris version does: /* stdout generated from stdin by unix pswrap V1.009 Wed Apr 19 17:50:24 PDT 1989 */ #include <DPS/dpsfriends.h> #include <string.h> #line 1 "stdin" Shall we follow them? Will that work in our setup? Juliusz |
From: Juliusz C. <Jul...@en...> - 2001-01-07 16:34:27
|
>> gcc DefaultGcc2i386Opt -I. -I.. I got it. You need to build the config files in the X source tree; it won't work with a virgin tree. Yep, the DPS build procedure is badly hosed. Juliusz |
From: trevor <two...@ic...> - 2001-01-07 08:19:22
|
On Saturday 06 January 2001 21:07, Kevin Brosius wrote: > Juliusz Chroboczek wrote: > (snip) > > > TW> i would also like to find the source to "pswrap" and try to > > figure TW> out why i wants to insert the line: > > > > TW> #include "psops.h" > > > > TW> instead of: > > > > TW> #include <DPS/psops.h> > > > > TW> into the generated *.c file. > > I noticed this also, but added the DPS include path rather than mess > with pswrap. Are you looking for the pswrap source in XFree86 or in > the DPS distribution? It's in both... In XFree86, check > xc/config/pswrap. someone else also wrote me to point out that i could add an "-I/..." line to the compile. call me old-fashioned but i like the idea that #include "file.h" is for headers related to the source you wrote (the application) and #include <file.h> is for file provided by the system. actually changing the "pswrap" utility to do what i want is a three-second job, so i did that. in the directory <XFree86-4.0.2 sources>/source/xc/config/pswrap edit the file "pswfile.c" it is very short. find the line that looks like: printf("#include \"%spsops.h\"\n\n", dpsops ? "d" : ""); and change to printf("#include <DPS/%spsops.h>\n\n", dpsops ? "d" : ""); then in that same directory do a "make" the copy the resulting "pswrap" executable to "/usr/X11R6/bin" or wherever the current "pswrap" is located (you could try "whereis pswrap") best regards, trevor -- http://home.ica.net/~vjbtlw/ |
From: Kevin B. <Co...@co...> - 2001-01-07 02:05:55
|
Juliusz Chroboczek wrote: > > (snip) > > TW> i would also like to find the source to "pswrap" and try to figure > TW> out why i wants to insert the line: > > TW> #include "psops.h" > > TW> instead of: > > TW> #include <DPS/psops.h> > > TW> into the generated *.c file. > I noticed this also, but added the DPS include path rather than mess with pswrap. Are you looking for the pswrap source in XFree86 or in the DPS distribution? It's in both... In XFree86, check xc/config/pswrap. (snip) > > You'll find the original sources in the DPS anonymous FTP directory, > although you'll need to hack them somewhat in order to get them to > build on an XFree86 system. Oh, yeah, many of them require Motif and > UIL (and therefore won't work with Lesstif). > What is UIL? I was trying to get a couple of the examples to compile today and fought with this for a while. I noticed that I have 'uil' on my system, which I assume came from LessTif's Motif 1.2 or 2.0 distro, but I haven't tried to use it yet. Does the DPS distro expect Motif 1 or 2? (...) > > As far as I know, I am the only person working on the DPS extension. > I've been very busy over the last four months, I'm hoping to have more > time in March, hopefully even in February. > > I guess I really ought to find the courage to publish my current > version. For various reasons, though, I don't want to put my CVS tree > on SourceForge. > > Regards, > > Juliusz > -- Kevin |
From: Juliusz C. <jc...@pp...> - 2001-01-07 00:44:02
|
KB> Hmm, this seems to be a problem without default ProjectRoot. A KB> second machine with default X install builds fine... I'm using a non-default install of 4.0.1f, and everything works fine. I'll check with 4.0.2 when I've got some time. Still, I am aware that DPS has some build problems, especially with monolitic servers. Some of these have been fixed in my private tree, but I still cannot build a monolitic server with DPS without some manual intervention (ld -r in order to resolve mutual recursion between the two archives). >> Also, has anyone started using gs 6.50? Not me. I'm not too keen on merging it into DPS for licensing reasons (6.01 will become GPL'd earlier than 6.50). Regards, Juliusz |
From: Juliusz C. <jc...@pp...> - 2001-01-07 00:43:58
|
TW> when i typed in the example program from chapter 8 of the "Client TW> Library Referenc Manual" i didn't of course, enter it EXACTLY as in the TW> book. TW> as i played around with it, i couldn't help notice that it was TW> necessary to negate the "height" value that is returned from the TW> PSitransform() function. but in the example program they don't do TW> likewise. how do we know which to follow? As far as I can tell, the example program is buggy. Juliusz |