[Maxima-bugs] [ maxima-Bugs-1197336 ] mgnuplot script not executable (permission bit turned off)

[SourceForge.net <noreply@so...>]

Bugs item #1197336, was opened at 2005-05-07 16:37
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1197336&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core - Plotting
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 2
Private: No
Submitted By: Robert Dodier (robert_dodier)
Assigned to: Nobody/Anonymous (nobody)
Summary: mgnuplot script not executable (permission bit turned off)

Initial Comment:
The mgnuplot script (plotting/mgnuplot) isn't
executable -- the x permission bit is turned off. So
attempting a plot fails after set_plot_option
([plot_format,mgnuplot]) .

chmod a+x plotting/mgnuplot, then trying again yields
success.

Will CVS preserve permission bits? I wonder. 


Maxima version: 5.9.1.1cvs
Maxima build date: 6:59 5/5/2005
host type: i686-redhat-linux-gnu
lisp-implementation-type: CLISP
lisp-implementation-version: 2.33.2 (2004-06-02)

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:33

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-09-11 22:17

Message:
As indicated in the last posting this seems not to be a bug for a Maxima
user.
I can run mgnuplot without any problems on a Linux system with a built
from the CVS code.
Setting the status to pending and the resolution to "works for me".
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2006-08-12 15:15

Message:
Logged In: YES 
user_id=501686

Since mgnuplot is a generated file, it's not a cvs problem.
When mgnuplot is generated by make from mgnuplot.in, the x
bit should be set. mgnuplot is indeed marked executable by
make install, so the lack of x bit is only a problem in
developer sandboxes. Not sure if we should bother to fix this.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=1197336&group_id=4933

[Maxima-bugs] [ maxima-Bugs-2779656 ] not "read_xpm"

[SourceForge.net <noreply@so...>]

Bugs item #2779656, was opened at 2009-04-23 16:07
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2779656&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core - Plotting
Group: None
>Status: Closed
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: not "read_xpm"

Initial Comment:
command read_xpm not work
How read image files (*.bmp, *.jpg, *.xpm, *.png) from command line?
>From menu this work fine.

Maxima version: 5.18.1
Maxima build date: 20:57 4/19/2009
host type: i686-pc-mingw32
lisp-implementation-type: GNU Common Lisp (GCL)
lisp-implementation-version: GCL 2.6.8

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:32

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-09-05 20:30

Message:
It is not really clear from this bug report, what the problem is. There is
no example.
There is no answer to the last posting.
Setting the status to pending and the resolution to "out of date".
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Mario Rodriguez Riotorto (riotorto)
Date: 2009-04-23 18:53

Message:
Does your xpm file contain transparent regions? If I recall correctly, this
was one of the weak aspects of function read_xpm.

In general, package 'picture' needs extra work; it contains a minimal
image processing support to help package 'draw' in rendering images. Don't
expect much of it, at least in its present state.

No Maxima package contains routines for reading bmp, jpg and png images.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2779656&group_id=4933

[Maxima-bugs] [ maxima-Bugs-2068007 ] Working directory for plot output is not defined

[SourceForge.net <noreply@so...>]

Bugs item #2068007, was opened at 2008-08-22 18:15
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core - Plotting
Group: Includes proposed fix
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Dr. Schorsch (xorx)
Assigned to: Nobody/Anonymous (nobody)
Summary: Working directory for plot output is not defined

Initial Comment:
Problem
=======

Using WXMaxima on Windows XP the working directory for gnuplot file output is badly defined or undefined.

> plot2d (sin(x), [x, -5, 5],
  [gnuplot_term,ps],
  [gnuplot_out_file,"test.ps"]);

Does write its output to somewhere or even to nowhere. At least I could not find it. The documentation gives no information about this.

One could assume that this file is written to the directory where the maxima-file resides or otherwise to the users temp-directory.


Work-Around
============

The following command does write the file to the expected location, but it is very unconvenient to specify an absolute path:
> plot2d (sin(x), [x, -5, 5],
  [gnuplot_term,ps],
  [gnuplot_out_file,"C:/mytemp/test.ps"]);


Proposed Improvement
====================

Make path names for plot output relative to the documents path. This would allow to specify files as follows:

  [gnuplot_out_file,"../MyPlots/test.ps"]);



Software used
=============
Maxima version: 5.15.0
Maxima build date: 17:36 4/20/2008
host type: i686-pc-mingw32
lisp-implementation-type: GNU Common Lisp (GCL)
lisp-implementation-version: GCL 2.6.8

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:32

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-09-05 12:01

Message:
A comment has been added in Input.texi revision 1.79 about the behavior of
Maxima to use the current working directory to store a file. It might be a
feature request to change the current behavior of Maxima.

Setting the status to pending and the resolution to "works for me".
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-09-05 11:26

Message:
When a filename is passed to functions like PLOT2D, SAVE, or WRITEFILE and
the filename is not a complete pathname, Maxima stores the file in the
current working directory. The current working directory depends on the
system like Windows or Linux and on the installation.

When I start a Maxima console from an installed icon which starts
maxima.bat, the current working directory on my system is 'c:/Dokumente und
Einstellungen/Dieter/'. This is a default choice for a current working
directory on Windows. When I start wxMaxima the current working directory
is 'd:/Programme/Maxima-5.22.1/wxMaxima/'. This is the path I have
installed Maxima 5.22. The current working directory can be configured in
the property menu of the icon, which starts the program.

On a Linux system I always start at first a terminal, change to a suitable
directory and then I start Maxima from the terminal. The last directory
becomes the current working directory.

Here are some examples to get these informations. At first the plot of the
example:

(%i1)
plot2d(sin(x),[x,-5,5],[gnuplot_term,ps],[gnuplot_out_file,'mytest.ps']);
(%o1) 

The Maxima function FILE_SEARCH can locate the file. But it does not
return a full pathame. This indicates that the file is stored in the
current working directory, otherwise FILE_SEARCH will return a full
pathname:

(%i2) file_search('mytest.ps');
(%o2)                              mytest.ps

We can use the Lisp function TRUENAME to get in addition the full
pathname.

(%i3) ?truename(file_search('test.ps'));
(%o3)                /home/dieter/workspace/maxima/test.ps

The file is stored in the current working directory
'/home/dieter/workspace/', that is the directory I have started Maxima on
my Linux system. We can extract the directory the following way:

(%i4) pathname_directory(?truename(file_search('test.ps')));
(%o4)                   /home/dieter/workspace/maxima/

We have an undocumented function DIRECTORY which shows the current working
directory on a Linux system when called with an empty string. On a Windows
system with GCL the function shows a list of files and directories of the
current working directory:

(%i5) directory('');
(%o5)                  [/home/dieter/workspace/maxima/]

We have two global Lisp variables *maxima-tempdir* and *maxima-userdir*.
When we do not pass a filename to the function PLOT2D, the output of
gnuplot is stored in the directroy named by *maxima-tempdir*.


I would tend to say that the current behavior to store files in the
current working directory might be not what a user expects, but this
behavior is not a bug.

We might improve the documentation on this point. Another point might be
to improve FILE_SEARCH and other file input/output functions to return
always a full pathname.


Further remarks:

Because, the undocumented function DIRECTORY behaves different on Linux
and Windows I hesitated to document it. Perhaps, we should do an
implementation which is more independent from the underlying system and
Lisp or cut it out.

Furthermore, we have the function LOAD_SEARCH_DIR. This function prints
the value of the global Lisp variable *default-pathname-defaults*. On SBCL
this global Lisp variable is set to the current working directory, but not
on other Lisp's like CLISP and GCL. On the latter Lisp's the variable
*default-pathname-defaults* is NIL. I think this function should be cut out
too.

Dieter Kaiser

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=2068007&group_id=4933

[Maxima-bugs] [ maxima-Bugs-3037617 ] wxMaxima won't connect to Maxima on Win XP

[SourceForge.net <noreply@so...>]

Bugs item #3037617, was opened at 2010-07-31 18:00
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3037617&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Out of Date
Priority: 7
Private: No
Submitted By: Rad Radish (radradish)
Assigned to: Nobody/Anonymous (nobody)
Summary: wxMaxima won't connect to Maxima on Win XP

Initial Comment:
After starting wxMaxima it displays "Maxima started. Waiting for connection..." indefinitely in the status bar area.  When trying to evaluate cells then "Not connected to Maxima!" error is displayed. After trying to restart wxMaxima several times, there are also several cmd.exe processes left which have to be killed manually.

I've tried disabling ZoneAlarm and Windows Firewall, choosing proper settings or even disabling DEP feature as described on
http://maxima-project.org/wiki/index.php?title=Maxima_FAQ
however no luck with that.

System info:
OS: Windows XP SP3
firewall: ZoneAlarm Free 9.2.057.000
Maxima version: 5.21.1

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:26

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-08-22 18:38

Message:
I think this bug report is out of date. There is no response from the
user.
Setting the status to pending and the resolution to "out of date".
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Andrej Vodopivec (andrejv)
Date: 2010-08-09 15:20

Message:
Do you have any non-ascii characters in your username?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3037617&group_id=4933

[Maxima-bugs] [ maxima-Bugs-3029996 ] maxima failed to start if installed in a custom folder

[SourceForge.net <noreply@so...>]

Bugs item #3029996, was opened at 2010-07-15 13:00
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3029996&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Closed
Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: maxima failed to start if installed in a custom folder

Initial Comment:
I chose ./configure --prefix=/home/user/soft/maxima
Compilation and installation have passed smoothly, but maxima failed to start.
Seems like paths are not resolved.
OS: Fedora 12-64
If installed in the systems directory (configure without parameters), it works normally.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:26

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-08-21 18:27

Message:
I think this bug report is out of date. There is no response from the user.
The last posting shows that the installation in a custom folder can work.
Setting the status to pending and the resolution to "out of date".
Dieter Kaiser

----------------------------------------------------------------------

Comment By: Robert Dodier (robert_dodier)
Date: 2010-07-18 18:31

Message:
When you say "maxima failed to start", what command did you enter, and what
was the result? Please cut and paste from your command prompt so we can see
exactly what it is.

What does "which maxima" display? If it doesn't show something in
/home/users/soft, then you need to put the Maxima bin directory
(/home/users/soft/maxima/bin or something like that) in your PATH shell
environment variable.

I just tried installing to ~/soft/maxima and the installation succeeded. I
can execute Maxima as ~/soft/maxima/bin/maxima.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3029996&group_id=4933

[Maxima-bugs] [ maxima-Bugs-3038467 ] fpprec bug or bad command use?

[SourceForge.net <noreply@so...>]

Bugs item #3038467, was opened at 2010-08-02 20:07
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3038467&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: fpprec bug or bad command use?

Initial Comment:
Why when in wxMaxima (v. 5.21.1)  i set for example fpprec : 1000, the result of 250! is printed as
323285626090910773232081455202[433 digits]000000000000000000000000000000 and not with all digits?

Using command line "version" the result is correctly printed with all digits.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:26

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-08-21 18:44

Message:
I think it is a feature of wxMaxima to abbreviate very long numbers for
display. This is not a bug and it is not related to the option variable
fpprec. In a terminal Maxima has not this feature. 
Perhaps it is a feature request to add the possibility to show very long
numbers with all digits in wxMaxima too.
Setting the status to pending and the resolution "works for me".
Dieter Kaiser

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3038467&group_id=4933

[Maxima-bugs] [ maxima-Bugs-3020243 ] defint(exp(cos(x))*cos(sin(x)), x, 0, 2*%pi) wrong result 0

[SourceForge.net <noreply@so...>]

Bugs item #3020243, was opened at 2010-06-23 15:53
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Lisp Core - Integration
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: defint(exp(cos(x))*cos(sin(x)),x,0,2*%pi) wrong result 0

Initial Comment:
The correct result is 2*%pi. This is a new bug appearing in version 5.21.1. Previous
versions (<= 5.20.1 )  return just the integral expression unevaluated, which is fair enough, but 
most importantly is not a wrong result.

Maxima version: 5.21.1
Maxima build date: 8:13 4/26/2010
Host type: i686-pc-mingw32 also on linux system (fedora11)
Lisp implementation type: GNU Common Lisp (GCL) also with cmucl
Lisp implementation version: GCL 2.6.8 also with cmucl 19f 

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-09-29 19:21

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Dan Gildea (dgildea)
Date: 2010-08-10 23:14

Message:
Fixed in defint.lisp rev 1.81: give up when we see %gamma_incomplete
in limit-subs, due to discontinuities.  This integral now returns a noun
form.  Ideally the code would identify the discontinuities and handle
them.


----------------------------------------------------------------------

Comment By: Raymond Toy (rtoy)
Date: 2010-06-24 19:57

Message:
Expanding does produce a better answer.  The derivative does equal the
integrand.

Plotting realpart(%o3 )shows a discontinuity near %pi.  (Perhaps it's a
bug, but plot2d(%o3,[x,0,%pi]) produces a warning that a non-numeric value
occurs somewhere.  It seems as if it occurs everywhere except at 0.)

----------------------------------------------------------------------

Comment By: Dieter Kaiser (crategus)
Date: 2010-06-24 18:42

Message:
We get a more simple result when expanding the function gamma_incomplete:

(%i3) integrate(exp(cos(x))*cos(sin(x)),x),gamma_expand:true;
(%o3) -(%i*expintegral_ei(%e^(%i*x))-%i*expintegral_ei(%e^-(%i*x)))/2

I think this result is correct, as a reference I have compared the result
with wolfram alpha.

But nevertheless, the definite integral is wrong and I am wondering why
the conjugate function is introduced in the unsimplified result.

Dieter Kaiser

----------------------------------------------------------------------

Comment By: Raymond Toy (rtoy)
Date: 2010-06-24 18:18

Message:
This particular integral is evaluated by computing the antiderivative. 
Perhaps in earlier versions, maxima could not, but maxima can now.  So
integrate(exp(cos(x))*cos(sin(x)),x) returns:

-(%i*conjugate(gamma_incomplete(0,-%e^(%i*x)))
 -%i*conjugate(gamma_incomplete(0,-%e^-(%i*x)))
 -%i*gamma_incomplete(0,-%e^(%i*x))+%i*gamma_incomplete(0,-%e^-(%i*x)))
 /4

Somehow this doesn't look right.  Don't know if this is the correct
antiderivative or not, but that's how maxima gets zero for the answer.  At
x=0, the result is zero, and by periodicity x=2*%pi is also zero.  The
wrong branch cut is taken, assuming the antiderivative is correct.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104933&aid=3020243&group_id=4933