headers
Jacob (=Jouk) Jansen | 3 Feb 2003 09:16
Picon
Picon

Re: [gs-code-review] patches needed on OpenVMS

dan.coby <at> artifex.com wrote on 31-JAN-2003 10:22:57.26 to
CODE-REVIEW <at> ghostscript.com

>Is this the same problem that you had if November?
>
>I have seen similar problems on AIX with a bad compiler setting.  The
>result was that the compiler thought that the filed sizes in a structure
>differed between caller and callee.
>
>On Nov. 22, I sent:
>
>  >It looks like that during the call of gdev_psdf_put_params everything get
>  >changed. BUT WHY?????????
Yes, I'm stuggling with it since this summer (when the colour indices changed)

>  A possible cause for this problem is that sizes of fields in the structure
>  have a different definition between the two source modules.  This causes
>  the compiler to create different offsets to what should be the same field.
>
>  The most likely cause would be the size of a gx_color_index.  In general
>  we have changed the size of a gx_color_index to 64 bits where possible.
>  I do not know what the situation is on VMS.  (This has caused problems
>  with other builds on other systems.)

 without looking at the source : The type long on OpenVMS is 32 bits due to
backwards comapatibilty with "Old" Vax systems, while on most systems it is
64 bit. Is it possible that this is a cause for the problems I see.

>  Try printing &gs_pdfwrite_device.params.NeverEmbed.size and see if it
>  changes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Giles | 4 Feb 2003 16:05
Favicon

quota limits on the wisc ghostscript site

John,

I recently ran into quota limits uploading a new release to the 
mirror.cs.wisc.edu ghostscript ftp site. It was a little confusing 
because the scp upload was cut off with a quota warning, but 'quota' 
itself returns no limit when run on one of the tux workstations. Is 
this another artifact of the afs system?

Anyway, I mostly wanted to inquire about whether this quota could be 
raised. Of course we're very grateful for the hosting you've provided 
over the years, and we certainly have plenty of room for our current 
releases. However, for completeness I like to keep the older versions 
around as well. They're sometimes useful for reference and it's nice to 
have a single location to go to.

We're using about 1 GB currently. This makes us the largest of the 
'small' projects, but still much less than the ximian and iso mirrors. 
At current disk prices (even scsi) it's hard to imagine that increasing 
this to a few GB would be unreasonable. I know we've discussed this in 
the past, but wondered if perhaps the situation had changed.

Sincerely,
  -r
Permalink | Reply | 2 comments |
headers
John Perkins | 4 Feb 2003 17:54
Picon
Favicon

Re: quota limits on the wisc ghostscript site

On Tue, 4 Feb 2003 15:05:22 +0000
Ralph Giles <ralph.giles <at> artifex.com> wrote:

> I recently ran into quota limits uploading a new release to the 
> mirror.cs.wisc.edu ghostscript ftp site. It was a little confusing 
> because the scp upload was cut off with a quota warning, but 'quota' 
> itself returns no limit when run on one of the tux workstations. Is 
> this another artifact of the afs system?

To check quotas here, use "fs listquota <path>" (which can be shorted to 
"fs lq" if desired).

We do try to keep volume sizes down lower for administrative reasons--
historically easier to get good backups.  I've just created another 1GB
volume for all AFPL files; here is the current distribution of disk 
space:

Volume Name                   Quota      Used %Used   Partition
p.ftp.mirrors.ghost         1000000    580196   58%         70%  
p.ftp.mirrors.ghost.af      1000000    416266   42%         70% 

If you need additional space for the project, let me know how much and
where you need it, and we'll see what we can do...
============================================================================
   John Perkins			  |   University of Wisconsin-Madison
   Associate Researcher		  |   Department of Computer Science
   john <at> cs.wisc.edu		  |   1210 W. Dayton St.
   608-262-0438/608-262-9997 FAX  |   Madison, WI  53706-1685
============================================================================
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralph Giles | 4 Feb 2003 18:22
Favicon

Re: quota limits on the wisc ghostscript site

On Tuesday, February 4, 2003, at 04:54  pm, John Perkins wrote:

> We do try to keep volume sizes down lower for administrative reasons--
> historically easier to get good backups.  I've just created another 1GB
> volume for all AFPL files;

Thanks John. That should do nicely for the time being.

Cheers,
  -r
Permalink | Reply | 0 comments |
headers
Ralph Giles | 4 Feb 2003 20:25
Favicon

switching to COMPILE_INITS=1 in the default build

Ghostscript developers,

It's come up in the discussions of how to implement a resource 
directory (SF bug 677415) that enabling COMPILE_INITS in the default 
build would be advantageous. This has come up a couple of times before, 
mostly in terms of reducing user confusion surrounding version skew 
with the files in lib, but this case is for me a deciding point.

A twin pair of problems relate to the addition of a resource directory 
tree to the ghostscript  distribution: how to maintain support for 
COMPILE_INITS=1, since we're adding new files that have to be available 
to the executable, and how to handle the dichotomy between shared 
(and/or user-installed) resources and versioned ones we want to upgrade 
with and be specific to each release.

Switching on compile_inits in the default build seems a handy way 
forward with this. We have to visit the issue and code involved in any 
case, and this will smooth testing. More importantly, I also propose 
that we use 'what gets compiled in' as a distinction between versioned 
and shared resources. This will help with both user and developer 
confusion and provide impetus so sort out what's actually important 
among the multitudinous entries in lib.

I wanted to bring this up for discussion here since it's a major change 
in the build on all platform. If there are no serious objections, I'd 
like proceed in this direction as part of the resolution of 677415.

Cheers,
  -r
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ralph Giles | 4 Feb 2003 20:54
Favicon

Re: switching to COMPILE_INITS=1 in the default build

On Tuesday, February 4, 2003, at 07:43  pm, Stefan Kemper wrote:

> How will this affect debugging?  Seems like for the debug build we are
> currently needing this off in the language switch build.

You mean so you can play with the .ps files? Certainly you'd still want 
to be able to turn off COMPILE_INITS for when you're working on the 
postscript code. Making this the default for the debug build is 
reasonable, but you could also just ./configure --disable-compile-inits.

  -r
Permalink | Reply | 0 comments |
headers
Stefan Kemper | 4 Feb 2003 20:43
Favicon

Re: switching to COMPILE_INITS=1 in the default build

How will this affect debugging?  Seems like for the debug build we are
currently needing this off in the language switch build.  

-Stefan

On Tue, 2003-02-04 at 12:25, Ralph Giles wrote:
> Ghostscript developers,
> 
> It's come up in the discussions of how to implement a resource 
> directory (SF bug 677415) that enabling COMPILE_INITS in the default 
> build would be advantageous. This has come up a couple of times before, 
> mostly in terms of reducing user confusion surrounding version skew 
> with the files in lib, but this case is for me a deciding point.
> 
> A twin pair of problems relate to the addition of a resource directory 
> tree to the ghostscript  distribution: how to maintain support for 
> COMPILE_INITS=1, since we're adding new files that have to be available 
> to the executable, and how to handle the dichotomy between shared 
> (and/or user-installed) resources and versioned ones we want to upgrade 
> with and be specific to each release.
> 
> Switching on compile_inits in the default build seems a handy way 
> forward with this. We have to visit the issue and code involved in any 
> case, and this will smooth testing. More importantly, I also propose 
> that we use 'what gets compiled in' as a distinction between versioned 
> and shared resources. This will help with both user and developer 
> confusion and provide impetus so sort out what's actually important 
> among the multitudinous entries in lib.
> 
> I wanted to bring this up for discussion here since it's a major change
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dan Coby | 6 Feb 2003 07:30
Favicon

RE: bug status report - 02-06-2003


Jack,

A couple of corrections for this weeks report:

[ 673108 ] /invalidaccess in --setfileposition--
This was incorrectly marked as 'pending' instead of 'closed' on
2-3-2003.  This has been corrected (2-5-2003)

#655829 - dancoby - /typecheck in --setcolor-- with 7.04
The fix for this problem was sent Wed 12/18/2002 6:22 PM.
The problem was closed at that time.

Dan

-----Original Message-----
From: Jack Moffitt [mailto:jack <at> artifex.com]
Sent: Wednesday, February 05, 2003 9:32 PM
To: gs-devel <at> ghostscript.com
Cc: tech <at> artifex.com; miles <at> artifex.com
Subject: bug status report - 02-06-2003

SUMMARY
-------
Total sourceforge bugs	:	111
New sourceforge bugs	:	03
Closed sourceforge bugs	:	04
New potential bugs	:	00
Open potential bugs	:	01
Fixed potential bugs	:	00
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jack Moffitt | 6 Feb 2003 06:31
Favicon

bug status report - 02-06-2003

SUMMARY
-------
Total sourceforge bugs	:	111
New sourceforge bugs	:	03
Closed sourceforge bugs	:	04
New potential bugs	:	00
Open potential bugs	:	01
Fixed potential bugs	:	00
New customer bugs	:	02
Open customer bugs	:	32
Fixed customer bugs	:	00
New top-ten bugs	:	00
Open top-ten bugs	:	11
Fixed top-ten bugs	:	00

Closers 		:	igorm (3), giles (1)

NEW BUGS
--------

#680301 - CUSTOMER - pdfwrite font problems
customer: #411
assign: igorm?

File "15960.15960_PIX I.1A.CMYK.PS" runs fine in pdfwrite, but
produces mixed up fonts and unreadable text compared with the original
Postscript.

#680741 - INTERNAL - Slow rendering of emulated CID font
reported by: igorm
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fernando | 6 Feb 2003 20:02
Picon

I switch to change directories. Help please.

Hi:

Any of you have successfully used the -I switch in order to change the 
directory where Ghostscript will look for ps files?
I need to make Gs to look for a directory called "lib", that is in the 
dll's directory.

This code doesnt work:

gsargv[7] = "-I./lib;";

Thanks.

Fernando Lagos
flagos <at> agea.com.ar
http://flagos.8k.com
Permalink | Reply | 1 comment |

Gmane