dps-devel Mailing List for DPS (Page 6)
Status: Inactive
Brought to you by:
jch
Menu
▾
▴
dps-devel
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: Juliusz C. <Jul...@en...> - 2000-05-29 17:14:33
|
Peter Deutsch:
PD> Is this everything you need, or do you also need the ability to
PD> create a fresh context with a specified global VM and either a
PD> specified or a new local VM (corresponding to localfork and fork
PD> respectively, but with a pristine state rather than a copied one)?
I think this deserves some background.
The DPS documentation calls ``space'' a couple global VM/local VM.
Leaving aside for now the issue of ``safe'' spaces, all spaces share
the same global VM. The DPS protocol specifies two ways of creating a
space:
1. explicitly creating a space;
2. creating a context with no explicit space argument.
In both cases, a new local VM is created.
Ways of creating contexts are as follows:
1. create a context with no explicit space argument: this creates a
new space (and a new local VM);
2. create a context with a space argument: this creates the new
context in an existing space, and thus creates no new local VM;
3. call ``fork''; this creates the new context in the forked
context's space.
The current implementation is as follows. When the interpreter is
initialised, a main instance and a ``main'' context are created.
Creation of a space is a dummy: it only creates a data structure
holding an empty list of contexts. Whenever a new context is created
in a virgin space S, the main context is localforked, and the new
context is put on the list held by S. Explicitly creating a context in
a non-virgin space is not currently supported.
There is no problem with fork: when a context C in space S forks a new
context C', you only need to put C' on S's list of contexts.
In order to support explicitly creating new contexts in a given space,
I was thinking of generalising the above: in every space, there is a
``main'' context which is only used for forking. Whenever a new
context is created in that space, we fork the space's main context.
Now, the cost of this is one extra context per space and some overhead
when creating new spaces. This is reasonable if we manage to bring
the memory cost of contexts down. There is typically one single space
per client.
Sincerely,
J.
|
|
From: Juliusz C. <Jul...@en...> - 2000-05-29 16:48:12
|
The following code is supposed to do nothing, but it hangs
GhostScript.
64 64 8 [64 0 0 64 0 0] () false 3 colorimage
It occurs in GNUstep (why?). I'm appending a (preliminary pending
review by L. Peter Deutsch) patch that fixes the problem.
J.
Index: zimage.c
===================================================================
RCS file: /usr/local/cvsroot/dps/dps/dpsi/zimage.c,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -c -r1.1.1.1 -r1.2
*** zimage.c 2000/05/28 02:48:54 1.1.1.1
--- zimage.c 2000/05/29 01:16:04 1.2
***************
*** 469,474 ****
--- 469,475 ----
if (code == e_RemapColor)
return code;
+ stop_now:
if (code) { /* Stop now. */
esp -= NUM_PUSH(num_sources);
image_cleanup(i_ctx_p);
***************
*** 480,485 ****
--- 481,491 ----
sources[px].data = psrc->value.bytes;
sources[px].size = r_size(psrc);
+ if(sources[px].size == 0) {
+ /* empty source */
+ code = 1;
+ goto stop_now;
+ }
}
}
}
|
|
From: Juliusz C. <Jul...@en...> - 2000-05-26 16:45:33
|
I've put a few simple screenshots of DPS clients running with the free extension on http://dps.sourceforge.net/screenshots/ Contributions welcome. J. |
|
From: L. P. D. <gh...@al...> - 2000-05-24 22:43:39
|
> PD> I suggest that the DPS project consider approaching Linux vendors > PD> or other sources of funding. > > While I would be glad to help, we are currently in no position to do > so. We will not have any credibility with Linux vendors until > (a) the extension is free software, and (b) it is used, or at least > considered, by the dominant desktop environments. Concerning (b), > someone should go and do some advertising with KDE and Gnome. > > Heck, currently not even GNUstep uses DPS as its dominant backend! It turns out that the Multiple Master fonts I knew about have licensing restrictions that explicitly exclude Open Source redistribution, so acquiring those licensing rights wouldn't be of any value anyway. -- L. Peter Deutsch | Aladdin Enterprises gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave. +1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025 The future of software is at http://www.opensource.org |
|
From: Juliusz C. <Jul...@en...> - 2000-05-24 21:48:10
|
PD> I suggest that the DPS project consider approaching Linux vendors
PD> or other sources of funding.
While I would be glad to help, we are currently in no position to do
so. We will not have any credibility with Linux vendors until
(a) the extension is free software, and (b) it is used, or at least
considered, by the dominant desktop environments. Concerning (b),
someone should go and do some advertising with KDE and Gnome.
Heck, currently not even GNUstep uses DPS as its dominant backend!
J.
|
|
From: L. P. D. <gh...@al...> - 2000-05-24 19:55:18
|
> PD> The approach I had in mind was to provide a general framework for > PD> implementing IODevices (%xxxx%) entirely in PostScript. > > Do you mean that this should be in addition to the current > implementation, or replace it altogether? In addition to. The graphics library also needs access to the IODevice machinery. > PD> Does the DPS project have free Multiple Master fonts? > > No; everything we have comes from three sources: XFree86, GhostScript, > and the Adobe/Digital DPS client libraries. I have a possible lead on Multiple Master fonts that might become freely (enough) redistributable after a one-time payment somewhere in the $10K-$100K range. If this lead turns out to be real, I suggest that the DPS project consider approaching Linux vendors or other sources of funding. -- L. Peter Deutsch | Aladdin Enterprises gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave. +1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025 The future of software is at http://www.opensource.org |
|
From: Juliusz C. <Jul...@en...> - 2000-05-24 19:31:41
|
>> I haven't looked at the implementation of the ``%font%'' pseudo-device
>> yet.
PD> When you do look for it, you will find that it isn't implemented yet.
Okay, at least that makes the situation clear.
PD> The approach I had in mind was to provide a general framework for
PD> implementing IODevices (%xxxx%) entirely in PostScript.
Do you mean that this should be in addition to the current
implementation, or replace it altogether?
PD> There would only be global IODevices, no local ones; the
PD> dictionary keeping track of them would be stored in global VM.
Fair enough.
PD> Does the DPS project have free Multiple Master fonts?
No; everything we have comes from three sources: XFree86, GhostScript,
and the Adobe/Digital DPS client libraries.
(Coolness does not necessarily imply usefulness.)
J.
|
|
From: L. P. D. <gh...@al...> - 2000-05-24 18:31:53
|
> I have found out why the Adobe DPS font selection widget doesn't work.
>
> Essentially, what the font selection widget does in order to find the
> list of fonts is looping over all the fonts using
>
> (%font%*) {...} ... filenameforall
>
> Under the Adobe implementation, this reliably gives the list of all
> fonts. Under GS, it does nothing.
That's a bug: it should give an error (see below).
> I haven't looked at the implementation of the ``%font%'' pseudo-device
> yet.
When you do look for it, you will find that it isn't implemented yet. :-(
It is on the short "missing odds and ends planned for implementation in gs
7" list.
The approach I had in mind was to provide a general framework for
implementing IODevices (%xxxx%) entirely in PostScript. I would do it in an
"object oriented" manner very similiar to the way Resource categories are
implemented: an IODevice would be implemented as a dictionary with keys
/File
/DeleteFile
/RenameFile
/Status
/FileNameForAll
/GetDevParams
/PutDevParams
There would only be global IODevices, no local ones; the dictionary keeping
track of them would be stored in global VM.
The only drawback to this approach is that such IODevices couldn't be
accessed from the C library code, so (for example) they couldn't be used as
the OutputFile of a printer or raster file driver. For the IODevices for
which this approach is likely to be used, this wouldn't be a problem.
If someone from the DPS project was willing to do this (and assign the
copyright to Aladdin, so we could distribute it with all Ghostscript
versions), I'd be very grateful.
> It would be cool to get the Adobe font selection widget to work. We
> could then claim to have the first useful implementation of Multiple
> Master fonts for free Unix-like systems.
Does the DPS project have free Multiple Master fonts?? I didn't know there
were any. I'd love to distribute them with Ghostscript if that's possible.
--
L. Peter Deutsch | Aladdin Enterprises
gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave.
+1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025
The future of software is at http://www.opensource.org
|
|
From: Juliusz C. <Jul...@en...> - 2000-05-24 17:36:35
|
I have found out why the Adobe DPS font selection widget doesn't work.
Essentially, what the font selection widget does in order to find the
list of fonts is looping over all the fonts using
(%font%*) {...} ... filenameforall
Under the Adobe implementation, this reliably gives the list of all
fonts. Under GS, it does nothing. I haven't looked at the
implementation of the ``%font%'' pseudo-device yet.
It would be cool to get the Adobe font selection widget to work. We
could then claim to have the first useful implementation of Multiple
Master fonts for free Unix-like systems.
J.
|
|
From: L. P. D. <gh...@al...> - 2000-05-24 15:27:17
|
>PD> Yes, local collection should work even in a multi-context system. > > I can confirm that it used to work. But then, I changed something, > and now it segfaults. It's clearly my bug. The Ghostscript garbage collector is unfortunately very fragile, because it depends on 100% accurate and complete structure descriptors for *every* structure allocated by an allocator it knows about. I really, really wish I could find a (more) automatic way to generate those descriptors. This particular area has had a very long bug tail, and I still occasionally make mistakes when adding new structures. I've found -Z@? to be the best way to catch problems early enough to track them down (almost always to an incorrect descriptor). > [re global collection] Making global collection work shouldn't be horrendously difficult, but I think it will require having each global VM keep track of all the local VMs that reference it, not just the number of contexts referencing it. -- L. Peter Deutsch | Aladdin Enterprises gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave. +1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025 The future of software is at http://www.opensource.org |
|
From: Juliusz C. <Jul...@en...> - 2000-05-24 00:52:01
|
PD> Yes, local collection should work even in a multi-context system.
I can confirm that it used to work. But then, I changed something,
and now it segfaults. It's clearly my bug.
PD> Global collection definitely will not work, because the GC
PD> currently has no logic to collect, as a unit, a global VM plus
PD> *all* the local VMs that reference it.
Unfortunately.
J.
|
|
From: L. P. D. <gh...@al...> - 2000-05-24 00:39:43
|
> 2. I've had to disable the garbage collector. I haven't had time to debug > the problems it has, but at least local VM collection should work. Yes, local collection should work even in a multi-context system. Global collection definitely will not work, because the GC currently has no logic to collect, as a unit, a global VM plus *all* the local VMs that reference it. I assume you know about using -Z? and -Z@ to help find memory problems. > 3. Usernames are leaked into nature. This will be fixed when I go over your code and get it to interact with the allocator properly. -- L. Peter Deutsch | Aladdin Enterprises gh...@al... | http://www.aladdin.com | 203 Santa Margarita Ave. +1-650-322-0103 (9-12 M-F) | fax +1-650-322-1734 | Menlo Park, CA 94025 The future of software is at http://www.opensource.org |
|
From: Juliusz C. <Jul...@en...> - 2000-05-23 21:54:16
|
The major problems with DPS-0.0.3 are the following:
1. Timeslicing still doesn't work. I've got no idea why.
2. I've had to disable the garbage collector. I haven't had time to
debug the problems it has, but at least local VM collection should work.
3. Usernames are leaked into nature.
4. Only normal contexts are implemented: forked contexts aren't
implemented yet, and I have no idea how to implement safe contexts.
Sincerely,
J.
|
|
From: Juliusz C. <Jul...@en...> - 2000-04-21 15:01:04
|
The attached patch fixes the error reporting when the init file is not
found. It also includes yesterday's patch, and eliminates a useless
gs_closedevice in zdpsx.c (the device is already closed at this point).
J.
diff -cr dps/dpsi.old/gconfig.h dps/dpsi/gconfig.h
*** dps/dpsi.old/gconfig.h Fri Apr 21 16:45:06 2000
--- dps/dpsi/gconfig.h Fri Apr 21 16:39:55 2000
***************
*** 243,249 ****
image_class_(gs_image_class_3_mono)
image_class_(gs_image_class_4_color)
#endif
- #define GS_LIB_DEFAULT "/usr/X11R6/lib/X11/ghostscript/6.0/lib:/usr/local/share/ghostscript/fonts"
#define SEARCH_HERE_FIRST 0
#define GS_INIT "gs_init.ps"
#define GS_REVISION 600
--- 243,248 ----
diff -cr dps/dpsi.old/gdevdps.c dps/dpsi/gdevdps.c
*** dps/dpsi.old/gdevdps.c Fri Apr 21 16:45:06 2000
--- dps/dpsi/gdevdps.c Fri Apr 21 16:32:56 2000
***************
*** 42,48 ****
dps_open(gx_device *dev)
{
int code;
-
code = dps_device_set_color_info(dev);
return code;
}
--- 42,47 ----
diff -cr dps/dpsi.old/gsmisc.c dps/dpsi/gsmisc.c
*** dps/dpsi.old/gsmisc.c Fri Apr 21 16:41:46 2000
--- dps/dpsi/gsmisc.c Fri Apr 21 16:36:32 2000
***************
*** 96,104 ****
long revision_number)
{
if (program_name) {
! fputs(program_name, f);
if (revision_number)
! ErrorF(' ');
}
if (revision_number) {
int fpart = revision_number % 100;
--- 96,104 ----
long revision_number)
{
if (program_name) {
! ErrorF("%s", program_name);
if (revision_number)
! ErrorF(" ");
}
if (revision_number) {
int fpart = revision_number % 100;
diff -cr dps/dpsi.old/zdpsx.c dps/dpsi/zdpsx.c
*** dps/dpsi.old/zdpsx.c Fri Apr 21 16:45:06 2000
--- dps/dpsi/zdpsx.c Fri Apr 21 16:27:43 2000
***************
*** 100,108 ****
return e_invalidid;
}
- /* We need to close and reopen the device so that all cached data
- are invalidated. */
- gs_closedevice((gx_device*)dps_dev);
gx_device_decache_colors((gx_device*)dps_dev);
gs_opendevice((gx_device*)dps_dev);
code = gs_setdevice_no_erase(igs, (gx_device*)dps_dev);
--- 100,105 ----
|
|
From: Juliusz C. <Jul...@en...> - 2000-04-20 21:18:44
|
Dear all,
A few people have reported that as soon as they try to run a DPS
client, the X server dies with
A null handle is passed to xf86fputs
This bug has been identified (thanks to Mark Vojkovich), and happens
when the PS interpreter is unable to find its init file. It will be
fixed as soon as possible. For now, if you get this error, please
check the location of the init file.
There is also another bug (also identified by Mark): the value of
GS_LIB_DEFAULT in ``dpsi/Imakefile'' is overriden by the value in
``dpsi/gconfig.h''. I'm attaching Mark's patch.
Sincerely,
Juliusz Chroboczek
*** gconfig.h.old Thu Apr 20 10:34:48 2000
--- gconfig.h Thu Apr 20 10:34:49 2000
***************
*** 243,249 ****
image_class_(gs_image_class_3_mono)
image_class_(gs_image_class_4_color)
#endif
- #define GS_LIB_DEFAULT "/usr/X11R6/lib/X11/ghostscript/6.0/lib:/usr/local/share/ghostscript/fonts"
#define SEARCH_HERE_FIRST 0
#define GS_INIT "gs_init.ps"
#define GS_REVISION 600
--- 243,248 ----
|
|
From: Mark V. <mvo...@va...> - 2000-04-01 18:28:17
|
On Sat, 1 Apr 2000, Juliusz Chroboczek wrote: > MV> (II) Loading /usr/X11R6/lib/modules/extensions/libdps.a > MV> (EE) LoadModule: Module dps does not have a dpsModuleData data object. > MV> (II) Unloading /usr/X11R6/lib/modules/extensions/libdps.a > MV> (EE) Failed to load module "dps" (invalid module, 0) > > I cannot reproduce this; it works fine for me. I'm using stock 4.0. > Does nm indicate that dpsmodule.o exports this symbol? Has > dpsmodule.o been included in libdps.a? Hmmm. It looks like dpsmodule.o didn't get built because DoLoadableServer doesn't seem to be defined. I'll have to look into why it isn't. Perhaps this is why the modules didn't get loaded either. Mark. |
|
From: Juliusz C. <Jul...@en...> - 2000-04-01 16:46:34
|
MV> (II) Loading /usr/X11R6/lib/modules/extensions/libdps.a
MV> (EE) LoadModule: Module dps does not have a dpsModuleData data object.
MV> (II) Unloading /usr/X11R6/lib/modules/extensions/libdps.a
MV> (EE) Failed to load module "dps" (invalid module, 0)
I cannot reproduce this; it works fine for me. I'm using stock 4.0.
Does nm indicate that dpsmodule.o exports this symbol? Has
dpsmodule.o been included in libdps.a?
MV> 1) Add -DXFree86LOADER or else some stuff doesn't get included
MV> correctly.
Right. This needs fixed.
MV> 2) You mention gs_init.patch in the README which really should
MV> be gs_lib.patch.
Noted.
MV> 3) Also, "make install" didn't install the modules. I'm not
MV> sure why. It might just be a configuration part on my side.
I can't reproduce this. I'm using more or less the stock
configuration (give or take a few options).
There's another known bug you might hit: the refcount of a drawable
held by a PS graphic state is not updated correctly, which may lead to
crashes. I know where to fix it (in open_device and close_device in
gdevdps.c), but haven't gotten around to doing it yet.
Thanks a lot,
J.
|
|
From: Masatake Y. <mas...@is...> - 2000-02-06 08:30:31
|
I've forwared patches to dgs-dev. Thank you. Masatake |
|
From: Adam F. <fe...@do...> - 2000-02-05 20:52:52
|
On Sat, 5 Feb 2000, Juliusz Chroboczek wrote: > There should be a way to cause the GNUstep code to call > > XSynchronize(dpy, True); > > just after opening the display. With Xt, this is done by passing > `-sync' on the command line. > I see now. To do this in GNUstep, add the argument '--GNU-Debug=XSynchronize' (without quotes) when running the program. This happens close to when the display is open, but not quite. If you need that I can change it. |
|
From: Juliusz C. <Jul...@en...> - 2000-02-05 16:29:05
|
>> Thanks. That works with Sun's server, but unfortunately doesn't with
>> my extension. Is there any way to run the tests synchronously?
AF> I'm not sure what you mean by that.
There should be a way to cause the GNUstep code to call
XSynchronize(dpy, True);
just after opening the display. With Xt, this is done by passing
`-sync' on the command line.
It causes the client to wait for the server to finish executing each
request before sending the next one, and is extremely helpful for
debugging.
J.
|
|
From: Juliusz C. <Jul...@en...> - 2000-02-05 16:13:27
|
The attached patch implements a nasty hack that allows GhostScript to
read from selected filters without lookahead. The one-character
lookahead that happens without this patch would cause deadlocks in DPS
code.
Thanks to Mr. Deutsch for his help with this.
With this patch and the previous one applied, the following clients
run fine:
* texteroids;
* gtkDPS demos except fontpanel and sample2;
* a large number of GNUstep demos with the xdps backend (the text
object doesn't take input, for some reason).
The clients that I got to fail were either trying to create multiple
contexts, needed the NeXT compositing extensions, or were trying to
read from standard input directly.
Sincerely,
Juliusz Chroboczek
----------------------------------------------------------------------
*** /usr/local/src/gs5.94/src/stream.h Wed Sep 29 07:30:35 1999
--- stream.h Sat Feb 5 14:09:50 2000
***************
*** 20,25 ****
--- 20,29 ----
/* Definitions for Ghostscript stream package */
/* Requires stdio.h */
+ /* This file modified for DPS/X.
+ Juliusz Chroboczek, <Jul...@en...>,
+ 5 February 2000 */
+
#ifndef stream_INCLUDED
# define stream_INCLUDED
***************
*** 270,278 ****
--- 274,287 ----
* 0 for files.
*/
#define max_min_left 1
+ #if 0
#define sbuf_min_left(s)\
(s->strm == 0 ? (s->end_status != CALLC ? 0 : 1) :\
s->end_status == EOFC || s->end_status == ERRC ? 0 : 1)
+ #else
+ /* See stream.c for explanation */
+ extern int sbuf_min_left(stream *s);
+ #endif
/* The following are for very high-performance clients of read streams, */
/* who unpack the stream state into local variables. */
*** /usr/local/src/gs5.94/src/stream.c Wed Sep 29 08:16:28 1999
--- stream.c Sat Feb 5 14:10:48 2000
***************
*** 16,21 ****
--- 16,25 ----
all copies.
*/
+ /* This file modified for DPS/X.
+ Juliusz Chroboczek, <Jul...@en...>,
+ 5 February 2000 */
+
/*$Id: stream.c $ */
/* Stream package for Ghostscript interpreter */
#include "stdio_.h" /* includes std.h */
***************
*** 1116,1118 ****
--- 1120,1159 ----
}
return 0;
}
+
+ /* The following is peculiar to DPS/X, and violates GhostScript's
+ structuring. It will go away in a later version. */
+ /* This is needed in order to make the filter we use for context input
+ have no lookahead, which avoids deadlocks. */
+ #include "sfilter.h"
+ #include "iref.h"
+ #include "imemory.h"
+ #include "ifilter.h"
+
+ extern int zneedinput(i_ctx_t*);
+ extern int s_proc_read_process();
+ #define s_is_proc(s) (s->procs.process == s_proc_read_process)
+
+ int
+ sbuf_min_left(stream *s)
+ {
+ #define PROC (((const stream_proc_state *)s->state)->proc)
+
+ if(s->procs.process == s_SFD_template.process &&
+ ((const stream_SFD_state *)s->state)->eod.size == 0)
+ return 0;
+ else if(s_is_proc(s) && r_size(&PROC) == 1 && r_has_type(&PROC, t_array) &&
+ r_has_type(PROC.value.refs, t_operator) &&
+ PROC.value.refs->value.opproc == zneedinput)
+ return 0;
+ else if(s->strm == 0)
+ return (s->end_status == CALLC);
+ else if(s->end_status == EOFC || s->end_status == ERRC)
+ return 0;
+ else
+ return 1;
+ #undef PROC
+ }
+
+
+
*** /usr/local/src/gs5.94/src/zfproc.c Fri Sep 10 10:39:14 1999
--- zfproc.c Sat Feb 5 13:59:33 2000
***************
*** 16,21 ****
--- 16,23 ----
all copies.
*/
+ /* This file modified for DPS/X */
+
/*$Id: zfproc.c $ */
/* Procedure-based filter stream support */
#include "memory_.h"
***************
*** 129,135 ****
/* ---------------- Read streams ---------------- */
/* Forward references */
! private stream_proc_process(s_proc_read_process);
private int s_proc_read_continue(P1(i_ctx_t *));
/* Stream templates */
--- 131,137 ----
/* ---------------- Read streams ---------------- */
/* Forward references */
! /*private*/ stream_proc_process(s_proc_read_process);
private int s_proc_read_continue(P1(i_ctx_t *));
/* Stream templates */
***************
*** 158,164 ****
}
/* Handle an input request. */
! private int
s_proc_read_process(stream_state * st, stream_cursor_read * ignore_pr,
stream_cursor_write * pw, bool last)
{
--- 160,166 ----
}
/* Handle an input request. */
! /*private*/ int
s_proc_read_process(stream_state * st, stream_cursor_read * ignore_pr,
stream_cursor_write * pw, bool last)
{
*** /usr/local/src/gs5.94/src/zcontrol.c Fri Aug 13 01:58:12 1999
--- zcontrol.c Sat Feb 5 13:26:54 2000
***************
*** 722,728 ****
}
/* - .needinput - */
! private int
zneedinput(i_ctx_t *i_ctx_p)
{
return e_NeedInput; /* interpreter will exit to caller */
--- 722,728 ----
}
/* - .needinput - */
! /*private*/ int
zneedinput(i_ctx_t *i_ctx_p)
{
return e_NeedInput; /* interpreter will exit to caller */
|
|
From: Juliusz C. <Jul...@en...> - 2000-02-05 16:06:20
|
The following patch, courtesy of Peter Deutsch, fixes a minor bug in
the binary object sequence scanner in GhostScript. The bug involved
situations in which a BOS is split accross two GiveInput events, which
happens when running clients synchronously.
J.
----------------------------------------------------------------------
*** master/600/gs6.0/src/iscanbin.c Fri Dec 3 12:57:44 1999
--- src/iscanbin.c Thu Feb 3 21:19:05 2000
***************
*** 1,3 ****
! /* Copyright (C) 1989, 1992, 1993, 1994, 1998, 1999 Aladdin Enterprises. All rights reserved.
This file is part of Aladdin Ghostscript.
--- 1,3 ----
! /* Copyright (C) 1989, 2000 Aladdin Enterprises. All rights reserved.
This file is part of Aladdin Ghostscript.
***************
*** 215,219 ****
refset_null(pbs->bin_array.value.refs + index,
r_size(&pbs->bin_array) - index);
- pbs->cont = scan_bos_continue;
}
return code;
--- 215,218 ----
***************
*** 429,432 ****
--- 428,432 ----
int code;
+ pbs->cont = scan_bos_continue; /* in case of premature return */
s_begin_inline(s, p, rlimit);
for (; index < max_array_index; p += SIZEOF_BIN_SEQ_OBJ, index++) {
***************
*** 563,566 ****
--- 563,567 ----
/* Shorten the objects to remove the space that turned out */
/* to be used for strings. */
+ pbs->index = max_array_index;
iresize_ref_array(&pbs->bin_array, max_array_index,
"binary object sequence(objects)");
|
|
From: Masatake Y. <mas...@is...> - 2000-01-25 00:02:31
|
I've designed a logo. http://www.gyve.org/~jet/dps.gif Masatake |
|
From: Juliusz C. <Jul...@en...> - 2000-01-24 16:54:30
|
AF> These acronyms are confusing...
I think it might be a good habit to take to always use a noun with the
acronym:
the DPS client library;
the DGS agent;
the DPS extension;
the xdps backend.
J.
|
|
From: Adam F. <fe...@do...> - 2000-01-24 15:24:50
|
Juliusz Chroboczek wrote: > > AF> The simplest way is to configure/make/install the core libraries with > AF> the xdps backend; > > AF> configure --with-library-combo=gnu-gnu-gnu-xdps > AF> make > AF> make install > > Thanks. That works with Sun's server, but unfortunately doesn't with > my extension. Is there any way to run the tests synchronously? > I'm not sure what you mean by that. > AF> The xdps DPS code leaves much to be desired, however. > > Sure. What do you expect from what is basically a one-person effort > that is two months old? > Sorry for the confusion, I meant MY dps code in the xdps backend of GNUstep. These acronyms are confusing... -- Adam Fedor, Digital Optics | Fudd's law of opposition: Push fe...@do... | something hard enough, and it will fe...@gn... (GNUstep!) | fall over. |
804 messages has been excluded from this view by a project administrator.