[Fink-users] octave 2.1.72: plot and help problems
i'm upgrading from an old g3 imac to a mac book pro (intel, 10.4.8) and can't get octave to work. everything is obviously current and octave does number crunching fine, but i can't get plot or help to work in octave. both lead to panic: segmentation fault, etc. though at least help will print the help before dying. i have rebuilt and installed twice (both from the terminal and fink commander). is there anything obviously going wrong? i haven't noticed anything untoward during compliation... thanks for any help, matt. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] gpsbabel-1.3.2-1000
On Nov 6, 2006, at 2:27 PM, Alexander Hansen wrote: It shouldn't be installing -anything- in /usr/local/bin--that's more fundamental than an extra slash. :-) Yes, sorry... I was looking for other changes, and totally missed the fact that the autoconf code was reworked. Of course, my testing failed to notice anything wrong (run gpsbabel from the command line; look at 'fink validate'). New version (1.3.2-1001) works with --build-as-nobody. -- Charles Lepple [EMAIL PROTECTED] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] gpsbabel-1.3.2-1000
successfully built and installed! thank you! Charles Lepple wrote: On Nov 6, 2006, at 2:27 PM, Alexander Hansen wrote: It shouldn't be installing -anything- in /usr/local/bin--that's more fundamental than an extra slash. :-) Yes, sorry... I was looking for other changes, and totally missed the fact that the autoconf code was reworked. Of course, my testing failed to notice anything wrong (run gpsbabel from the command line; look at 'fink validate'). New version (1.3.2-1001) works with --build-as-nobody. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
[Fink-users] gforth-0.6.2-2
On macos 10.4.8 with fink 0.25.1 the new gforth fails with: config.status: executing stamp-h commands echo timestamp stamp-h gcc -I/sw -I/sw/include -I./../arch/power -I. -Wall -O2 -no-cpp-precomp -DHAVE_CONFIG_H -DDEFAULTPATH='.:/sw/lib/gforth/site-forth:/sw/share/gforth/site-forth:/sw/lib/gforth/0.6.2:/sw/share/gforth/0.6.2' -fno-gcse -fno-strict-aliasing -fno-crossjumping -fno-defer-pop -fcaller-saves -fno-inline -DGFORTH_DEBUGGING -o engine.o -c ./engine.c In file included from ./engine.c:32: ./threaded.h:216:2: warning: #warning direct threading scheme 5: long latency, cfa live In file included from ./engine.c:337: ./prim: In function 'engine': ./prim:1089: warning: pointer targets in assignment differ in signedness ./prim:1538: warning: pointer targets in passing argument 1 of '_sync_cache_range' differ in signedness ./prim:1562: warning: pointer targets in assignment differ in signedness ./prim:1563: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ./prim:1639: warning: pointer targets in assignment differ in signedness ./prim:1640: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ./prim:1644: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness ./prim:1813: warning: pointer targets in assignment differ in signedness ./prim:2309: error: aggregate value used where an integer was expected ./prim:2328: error: aggregate value used where an integer was expected ./prim:2360: error: incompatible types in assignment ./prim:2369: warning: pointer targets in assignment differ in signedness ./prim:2393: error: incompatible types in assignment ./prim:2396: warning: pointer targets in assignment differ in signedness ./prim:2417: error: incompatible types in assignment ./prim:2417: warning: value computed is not used make[2]: *** [engine.o] Error 1 make[1]: *** [engines] Error 2 make: *** [kernel/version.fs] Error 2 ### execution of make failed, exit code 2 Complete output is available here: http://reg066.reg.utexas.edu/~rgrtw-05/fink/gforth-0.6.2-2.txt - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] ghostscript paper sizes
Dear Jens,
Thanks a lot !
You're a wonderful maintainer !
[would suggest you send this as bug-report to gs
_ or to gs and dvips, and let them discuss the issue
between themselves...]
On 07 Nov 2006, at 05:43, Jens Noeckel wrote:
On Nov 6, 2006, at 8:59 AM, Jean-François Mertens wrote:
Hi,
Sorry if this is not fink-specific _ but I'd like to check first if
other users can reproduce the problem...
Given my (dvips) config.ps, a typical .ps file here specifies twice
A4 paper :
%%DocumentPaperSizes: a4
(in the initial comments) , and
%%PaperSize: A4
(in the final Setup)
Yet when using ps2pdf (or ps2pdf14) on that file, the resulting .pdf
contains
for each page :
/Type/Page/MediaBox [0 0 612 792]
ie, specifies letter paper
I canfix this by un-commenting the line
/DEFAULTPAPERSIZE (a4) def
in /sw/share/ghostscript/8.54/lib/gs_init.ps, but this should NOT be
necessary:
the ghostscript documentation ( file:///sw/share/ghostscript/8.54/
doc/
Use.htm#Paper_size ) specifies :
Individual documents can (and often do) specify a paper size, which
takes precedence over the default size.
JF Mertens
Hi JF,
I can confirm this with a ps file generated from a minimal latex
[a4paper]{article} using dvips. But for me the same behavior
results when I use pstopdf (Apple's built-in converter) instead of
ps2pdf. Moreover, this does _not_ happen if I produce a minimal ps
file using Adobe Illustrator, or by printing to a file from Camino
(after choosing A4 as the Page format).
So I think it must be blamed squarely on dvips. I can make dvips
behave correctly by giving it the explicit command line option -t
a4. Here is the diff between the ps files produced without and
with that flag:
%DVIPSCommandLine: dvips -o new2.ps newfile1
---
%DVIPSCommandLine: dvips -o new1.ps -t a4 newfile1
273c273,275
%%PaperSize: A4
---
%%BeginPaperSize: a4
a4
%%EndPaperSize
The file new1.ps has the correct dimensions in Preview (i.e.,
after PDF conversion), the file new2.ps doesn't. The reason for
this discrepancy is probably due to the fact that dvips thinks it's
sending stuff to a printer, and different printers expect different
syntax.
Here is a page I found on this:
http://www.tug.org/texinfohtml/dvips.html
(or `pinfo dvips` ...)
What it boils down to is that we want dvips to write a ps file that
obeys the right syntax - Quoting:
Virtually all of the PostScript commands you use here are device-
dependent and degrade the portability of the file; that is why the
default first paper size entry should not send any PostScript
commands down (although a structured comment or two would be okay).
Also, some printers want `BeginPaperSize' comments and paper size
setting commands; others (such as the NeXT) want `PaperSize'
comments and they will handle setting the paper size. There is no
solution I could find that works for both (except maybe specifying
both).
For purposes of processing by ps2pdf, we apparently want the syntax
with BeginPaperSize: a4, not the other one. So we have to tell
dvips to do that. I guess it could be put into the configuration
file (e.g., ~/.dvipsrc)
or config.ps _ just put the 'a4' entry on top ( or a line with just a
@ right above it).
using the commands in section 4.2. of the above reference,
Configuration file paper size command.
Not sure I agree with your conclusion; a bit further the same info
page is even more explicit :
Executing the `letter' or `a4' or other PostScript operators cause
the document to be nonconforming and can cause it not to print on
certain printers, so the default paper size should not execute such an
operator if at all possible.
dvips is very careful to write conforming PS (and the other examples
you mention are probably less so,
maybe because they are designed to work in a more specific environment).
And, for gs, even without the above quote from their doc, you would
expect it to respect
the PaperSize comments in the source... (and not only non-conforming
PS code like a4 or letter).
Jean-Francois
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] debfoster missing some necessary fink packages?
On Nov 5, 2006, at 9:31 AM, Shug Boabby wrote: So are you *sure* it's ok to remove these programs? Are you still on the 10.4-transitional tree, by chance? That's the one way I can think of that an up-to-date fink installation could still consider those packages to be essential... -- Dave - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-users mailing list Fink-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] ghostscript paper sizes
On Nov 7, 2006, at 9:33 AM, Jean-François Mertens wrote:
Dear Jens,
Thanks a lot !
You're a wonderful maintainer !
[would suggest you send this as bug-report to gs
_ or to gs and dvips, and let them discuss the issue
between themselves...]
On 07 Nov 2006, at 05:43, Jens Noeckel wrote:
On Nov 6, 2006, at 8:59 AM, Jean-François Mertens wrote:
Hi,
Sorry if this is not fink-specific _ but I'd like to check first if
other users can reproduce the problem...
Given my (dvips) config.ps, a typical .ps file here specifies twice
A4 paper :
%%DocumentPaperSizes: a4
(in the initial comments) , and
%%PaperSize: A4
(in the final Setup)
Yet when using ps2pdf (or ps2pdf14) on that file, the resulting .pdf
contains
for each page :
/Type/Page/MediaBox [0 0 612 792]
ie, specifies letter paper
I canfix this by un-commenting the line
/DEFAULTPAPERSIZE (a4) def
in /sw/share/ghostscript/8.54/lib/gs_init.ps, but this should NOT be
necessary:
the ghostscript documentation ( file:///sw/share/ghostscript/8.54/
doc/
Use.htm#Paper_size ) specifies :
Individual documents can (and often do) specify a paper size, which
takes precedence over the default size.
JF Mertens
Hi JF,
I can confirm this with a ps file generated from a minimal latex
[a4paper]{article} using dvips. But for me the same behavior
results when I use pstopdf (Apple's built-in converter) instead of
ps2pdf. Moreover, this does _not_ happen if I produce a minimal ps
file using Adobe Illustrator, or by printing to a file from Camino
(after choosing A4 as the Page format).
So I think it must be blamed squarely on dvips. I can make dvips
behave correctly by giving it the explicit command line option -t
a4. Here is the diff between the ps files produced without and
with that flag:
%DVIPSCommandLine: dvips -o new2.ps newfile1
---
%DVIPSCommandLine: dvips -o new1.ps -t a4 newfile1
273c273,275
%%PaperSize: A4
---
%%BeginPaperSize: a4
a4
%%EndPaperSize
The file new1.ps has the correct dimensions in Preview (i.e.,
after PDF conversion), the file new2.ps doesn't. The reason for
this discrepancy is probably due to the fact that dvips thinks it's
sending stuff to a printer, and different printers expect different
syntax.
Here is a page I found on this:
http://www.tug.org/texinfohtml/dvips.html
(or `pinfo dvips` ...)
What it boils down to is that we want dvips to write a ps file that
obeys the right syntax - Quoting:
Virtually all of the PostScript commands you use here are device-
dependent and degrade the portability of the file; that is why the
default first paper size entry should not send any PostScript
commands down (although a structured comment or two would be okay).
Also, some printers want `BeginPaperSize' comments and paper size
setting commands; others (such as the NeXT) want `PaperSize'
comments and they will handle setting the paper size. There is no
solution I could find that works for both (except maybe specifying
both).
For purposes of processing by ps2pdf, we apparently want the syntax
with BeginPaperSize: a4, not the other one. So we have to tell
dvips to do that. I guess it could be put into the configuration
file (e.g., ~/.dvipsrc)
or config.ps _ just put the 'a4' entry on top ( or a line with just a
@ right above it).
using the commands in section 4.2. of the above reference,
Configuration file paper size command.
Not sure I agree with your conclusion; a bit further the same info
page is even more explicit :
Executing the `letter' or `a4' or other PostScript operators cause
the document to be nonconforming and can cause it not to print on
certain printers, so the default paper size should not execute such an
operator if at all possible.
dvips is very careful to write conforming PS (and the other examples
you mention are probably less so,
maybe because they are designed to work in a more specific
environment).
And, for gs, even without the above quote from their doc, you would
expect it to respect
the PaperSize comments in the source... (and not only non-conforming
PS code like a4 or letter).
Jean-Francois
Jean-Francois,
you're right, this should be a bug report. But I'm sticking with my
claim that it's a dvips bug. Looking at the Postscript specifications
on Adobe's website, it's quite clear that _both_ of the ways dvips
tries to specify paper sizes are incorrect. The correct way since
1992 (!) is given in Appendix A of the document PostScript Language
Document Structuring Conventions Specification at
http://partners.adobe.com/public/developer/en/ps/5001.DSC_Spec.pdf
Discontinued Comments For Version 3.0
%%BeginPaperSize:
%%EndPaperSize
The comments %%BeginFeature: and %%EndFeature should be substituted.
So dvips is way behind in its implementation of the proper DSC
comments for page size information. I've sent an email about this to
the [EMAIL PROTECTED] mailing list.
Regards,
Jens
