The routine Compiler:-Tools:-gccversion() issues the folowwing call, and then parses the result to extract the version number.

Compiler:-Build:-ssystem("gcc --version");

The result of that can be in several forms (due to there being so many gcc variants, I suppose) so it then tries to parse the result using a variety of patterns -- namely Compiler:-Tools:-gccversion_patterns.

Maybe you can try to force that routine call to return an acceptable string, by replacing it with your own routine. For example,

> restart:
> kernelopts(opaquemodules=false):
> unprotect(Compiler):
> Compiler:-Tools:-gccversion := proc() "4.3.0"; end proc:
> protect(Compiler):

> y := proc( x :: float ) 2.3 * x end proc:
> cy := Compiler:-Compile(y):

The Compiler may indeed save that gccversion result somewhere. If I try to alter it once again, after running Compiler:-Compile for the first time, then any further use of Compiler:-Compile results in the error message about not finding a valid installed gcc. In other words, maybe the failure to find a valid gcc version string is itself all that's preventing the Compiler to work for you. Let's hope.

By the way, when the Compiler runs for the first time it initializes all its flags and values. For cflags and ldflags, etc, that initialization has to happen before any values are overridden. Otherwise the initialization clobbers the custom values. But once it is initialized, those flags may be overridden. In the past, I have had some success using these following two commands to get and set the flags. They are internal, and not intended for general use, so kernelopts(opaquemodules=false) needs to be issued before they are accessible.

Compiler:-Build:-GetBuildVariable()
Compiler:-Build:-SetBuildVariable()

acer

It's an attempt at being thorough, without having to visually scan the code.

The help-pages describe the levels of userinfo "intended" for the end-user. But the mechanism works just the same for levels greater than 5. By setting it to some "huge" value one can get some assurance that one is also covering any userinfo messages put in for debugging purposes (and perhaps not otherwise intended for the end-user).

acer

It's an attempt at being thorough, without having to visually scan the code.

The help-pages describe the levels of userinfo "intended" for the end-user. But the mechanism works just the same for levels greater than 5. By setting it to some "huge" value one can get some assurance that one is also covering any userinfo messages put in for debugging purposes (and perhaps not otherwise intended for the end-user).

acer

I'm not sure exactly what you're after. Does this get close at all?

restart:
printlevel := 1;
with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
                                                                                
assume (Q::real,Q<>0);
                                                                                
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)):
                                                                                
interface(showassumed=2);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x);
                                                                                
simplify(%);

acer

I'm not sure exactly what you're after. Does this get close at all?

restart:
printlevel := 1;
with(PDEtools):
with(codegen,fortran):
with(CodeGeneration,Fortran):
                                                                                
assume (Q::real,Q<>0);
                                                                                
alias(Q = Q(x, y, t), H = H(x, y, t), S = S(x,y,t) , B = B(x, y, t)):
declare(Q(x, y, t), H(x, y, t), S(x,y,t), B(x, y,t)):
                                                                                
interface(showassumed=2);
qs:=aa/(1-p)*abs(Q)^mm/(H-B)^mm*abs(1,Q);
diff(H, t) = -(diff(Q, x))-diff(qs,x);
                                                                                
simplify(%);

acer

I see. Sorry, I missed that. As you suggested, it's likely the assumption on Q that interferes with the effectiveness of the subsequent declare() command on Q. I tried a few other ways, but no joy so far. Maybe someone else will see it...

acer

I see. Sorry, I missed that. As you suggested, it's likely the assumption on Q that interferes with the effectiveness of the subsequent declare() command on Q. I tried a few other ways, but no joy so far. Maybe someone else will see it...

acer

My earlier post mentioned "similar" treatment for properties. I was thinking  of  something like extended_real. The difficulties are that adding it to the property lattice would likely not be nearly enough. Other parts of Maple (`is/internal`, coulditbe, `convert/PropertyRelation`, convert/relation, etc) might also need to be taught explicitly how to use it. Some code logic might have to be expanded. That would involve work -- how much being hard to estimate in advance. And suprising things might break. Even after covering all the detectable cases (from running a test suite) there could well still be important broken situations as yet not discovered.

It could be a lot of work, to fix a few examples (which not everyone might agree are utterly wrong?!).

acer

Suppose one is working inside the IntTutor. Eg,

> Student[Calculus1][IntTutor](exp(x)*sin(x));

Now, if one hits the All Steps (or Next Step) button then the problem is solved by parts. But Maple does not show which choices it made in applying the Parts rule. One would have to figure it out, working backwards from the line resulting from its application. Setting infolevel[Calculus]=1000 didn't make the choices get shown in either the tutor or the parent worksheet.

Also, once the tutor is exited, the particular by-parts choices made during the solving of the problem is not shown after executing the command,

> Student[Calculus1][Show](all);

That's true even if one sets,

> infolevel[Calculus1]:=1000:

before invoking the tutor.

I don't see how to get Student:-Calculus1 to solve this example showing all the steps and including some printed display of the by-parts choice. (I think this is in agreement with Tim's point.)

acer

Suppose one is working inside the IntTutor. Eg,

> Student[Calculus1][IntTutor](exp(x)*sin(x));

Now, if one hits the All Steps (or Next Step) button then the problem is solved by parts. But Maple does not show which choices it made in applying the Parts rule. One would have to figure it out, working backwards from the line resulting from its application. Setting infolevel[Calculus]=1000 didn't make the choices get shown in either the tutor or the parent worksheet.

Also, once the tutor is exited, the particular by-parts choices made during the solving of the problem is not shown after executing the command,

> Student[Calculus1][Show](all);

That's true even if one sets,

> infolevel[Calculus1]:=1000:

before invoking the tutor.

I don't see how to get Student:-Calculus1 to solve this example showing all the steps and including some printed display of the by-parts choice. (I think this is in agreement with Tim's point.)

acer

I's pretty sure that you realize that setting trace() is an awkward solution to this.  :)

It would be much nicer if it were shown at some level of infolevel[IntegrationTools].

acer

I's pretty sure that you realize that setting trace() is an awkward solution to this.  :)

It would be much nicer if it were shown at some level of infolevel[IntegrationTools].

acer

Yes, that's why I mentioned the 'numeric' versus 'extended_numeric' types above. But it's hard to tell whether that is the way to go, and how it might (best) be implemented without breaking all sorts of things in surprising ways.

acer

Ok, sorry. I thought that it was hard, to separate the coding errors from the math, because it's so unclear what was wanted. Maybe the (-1)^(n+1) for n odd is indeed what was wanted, and any simplification to that is expected. It's not clear.

As for the tricks to generate the odd (or even) integers in the formula, it's hard to tell whether that too is part of the assignment or is just incidental. And it's unclear because a new user might well expect Maple's `sum` or `add` functions to handle those directly with a special syntax (instead of the standard "trick").

I was also wondering whether the original poster meant to sum from 1 to N, using n as the index of summation. It's not clear.

acer

Ok, sorry. I thought that it was hard, to separate the coding errors from the math, because it's so unclear what was wanted. Maybe the (-1)^(n+1) for n odd is indeed what was wanted, and any simplification to that is expected. It's not clear.

As for the tricks to generate the odd (or even) integers in the formula, it's hard to tell whether that too is part of the assignment or is just incidental. And it's unclear because a new user might well expect Maple's `sum` or `add` functions to handle those directly with a special syntax (instead of the standard "trick").

I was also wondering whether the original poster meant to sum from 1 to N, using n as the index of summation. It's not clear.

acer