bug report
Moderators: MtnViewJohn, chris, mtnviewmark
bug report
I report this bug, it may depend on conflicts in my pc, because in past I don't think I ever had it.
system is Windows Vista 64bit, I have updated (and reinstalled too) .Net4
Context Free V.2.2 still works correctly, V.3 not anymore.
All Versions 3 I have installed now give me this problem: when the design needs to expand to temporary file (writing temporary file 1) the program slows down a lot and dont' do anything anymore. Also all the PC slows down so that sometimes is impossible to kill CF process.
The impression I had is that CF doesn't manage to write that temporary file but continues to try to do it.
tnx for attention!
Anyway I had a lot of fun in this days animating fractals and wires.
system is Windows Vista 64bit, I have updated (and reinstalled too) .Net4
Context Free V.2.2 still works correctly, V.3 not anymore.
All Versions 3 I have installed now give me this problem: when the design needs to expand to temporary file (writing temporary file 1) the program slows down a lot and dont' do anything anymore. Also all the PC slows down so that sometimes is impossible to kill CF process.
The impression I had is that CF doesn't manage to write that temporary file but continues to try to do it.
tnx for attention!
Anyway I had a lot of fun in this days animating fractals and wires.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
I think that what is happening is that the spilling of shapes and expansions is very computationally expensive. With v2.2 we spilled often and in small chunks, so the computational expense was less noticeable. With v3 we allow the data structures to grow larger before spilling: 2 million shapes or expansions for 32-bit and 10 million shapes or expansions for 64-bit. So the file I/O and the resorting of the data structures now takes a long time. This isn't a bug per se, but it is very user unfriendly behavior. Context Free should tell you what it is doing that is taking so long, update the progress bar so that you can see how far along it is, and allow for the spill process to be interrupted by the Stop button or by closing the window. I will put out a release that has these user experience improvements.
Re: bug report
To me the mac version seems to work very nice. but anyway my mac is still a 32 bit intel.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
I have uploaded a test version of CF 3.0.4 here that should improve things. It's only a little faster, but it lets you know the how long the file I/O will take and you can cancel or quit Context Free during temporary file I/O.
Re: bug report
The progress bar now animates more, but still I wasn't able to stop it (I terminated it with task manager).
All the system slows down very much.
I was able to check the activity monitor and i noticed that RAM was filled by CF and processor was going max 1%.
I disabled virtual memory and CF throw an error and quit when it should start to expand to file. (maybe I dont' have enough RAM?)
Also on my PC I have a problem with the Command line version that draws incomplete images for 16 bit designs.
Is there a command line version for Mac OS too?
tnx again.
All the system slows down very much.
I was able to check the activity monitor and i noticed that RAM was filled by CF and processor was going max 1%.
I disabled virtual memory and CF throw an error and quit when it should start to expand to file. (maybe I dont' have enough RAM?)
Also on my PC I have a problem with the Command line version that draws incomplete images for 16 bit designs.
Is there a command line version for Mac OS too?
tnx again.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
You can build cfdg from the source tarball on a Mac if you have the XCode command-line tools installed.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
I see the problem. When you stop Context Free and it has 10 million shape objects in memory, it insists on deleting all of them, and it does this in the user interface thread. This locks up the user interface and blocks you from exiting normally. So I'm going to push object deletion into a separate worker thread and also have it give up on deleting objects if the program is trying to exit.
I haven't looked at the 16bit issue yet.
I haven't looked at the 16bit issue yet.
Re: bug report
I post this other thing...
My opinion, if possible, is that it would be more useful not to have this limitation in scope of parameters inside IF control structure.
I am also getting a lot of this errors in my 3D designs in the gallery:
Maybe I didn't understand something about parameters. I use parameters as variables and maybe this is not correct.
Thank you again.
Code: Select all
startshape behavior(0,1)
shape behavior(number aa, number bb){
if (aa==0)
{
aa=1 // scope of aa is only inside this if control structure
CIRCLE[ b 1 s (aa/2) sat 1 h 120]
}
if (aa==0) // !!!!!
{
bb=0 // scope of bb is only inside this if control structure
CIRCLE[x 1]
CIRCLE[x 2]
CIRCLE[x 4]
} // end if
if (bb==1) // !!!!!
{
CIRCLE[x 3 b 1 sat 1]
}
if (bb==1) cc=0 else cc=1
/*
// this give error
if (cc==1) // !!!!!
{
CIRCLE[x -2 b 1 sat 1]
}
*/
}
I am also getting a lot of this errors in my 3D designs in the gallery:
And the code still works.Error - Scope of name overlaps variable/parameter with same name
Error - previous variable/parameter declared here
Maybe I didn't understand something about parameters. I use parameters as variables and maybe this is not correct.
Thank you again.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
You're right. I should still block overlap at the same scope level but allow variables in an inner scope to overlap those in an outer scope. You can eliminate the restriction altogether with
Code: Select all
CF::AllowOverlap = 1
Re: bug report
Hi,
I post here so the forum doesn't become cluttered with "bug"-titled post.
This program:
is rejected as erroneous with a parse error at line 3.
If I substitute the product with a division the error remains but if I instead use a
sum or a difference the error goes away.
Bye.
P.S. I'm using cfdg version 3.0.2 on linux OS.
I post here so the forum doesn't become cluttered with "bug"-titled post.
This program:
Code: Select all
1. startshape test
2. shape test {
3. SQUARE [ b 1 * 4 ]
4. }
If I substitute the product with a division the error remains but if I instead use a
sum or a difference the error goes away.
Bye.
P.S. I'm using cfdg version 3.0.2 on linux OS.
Re: bug report
I think that "b 1 + 4" is possibly parsed as "b 1 +4", which is interpreted as the 2-argument version of "b".
Yes, I just checked and if you cfdg this:
[code]
startshape A
shape A{
SQUARE [b .2 x -1]
SQUARE [b .5 + .4 ]
SQUARE [b (.5 + .4) x 1]
}
[/code]
You'll see that the middle square is brightened by .2, which is .5 of the way towards .4, starting from 0.
Yes, I just checked and if you cfdg this:
[code]
startshape A
shape A{
SQUARE [b .2 x -1]
SQUARE [b .5 + .4 ]
SQUARE [b (.5 + .4) x 1]
}
[/code]
You'll see that the middle square is brightened by .2, which is .5 of the way towards .4, starting from 0.
- MtnViewJohn
- Site Admin
- Posts: 882
- Joined: Fri May 06, 2005 2:26 pm
- Location: Mountain View, California
- Contact:
Re: bug report
Yes, kipling is right. Context Free has two classes of expressions: simple and ordinary. The arguments for shape adjustments are simple expressions. Simple expressions do not support +-*/, only ordinary expressions allow these operators.
Why do we have two types of expressions? The arguments for shape adjustments are space delimited but the syntax ignores spaces. Thus the parser does not know whether to treat b 1 - 4 as b (1 - 4) or b (1) (-4). We solve this dilema by not allowing the + - * and / operators in shape adjustments, hence simple expressions. Another solution that some languages use is the not have space delimited expressions, but it was too late to do this for Context Free. A third solution is to make the parser aware of spaces and have rules governing spaces around unary and binary minus operators. We chose the simple expression option instead of the space-aware parser option.
Why do we have two types of expressions? The arguments for shape adjustments are space delimited but the syntax ignores spaces. Thus the parser does not know whether to treat b 1 - 4 as b (1 - 4) or b (1) (-4). We solve this dilema by not allowing the + - * and / operators in shape adjustments, hence simple expressions. Another solution that some languages use is the not have space delimited expressions, but it was too late to do this for Context Free. A third solution is to make the parser aware of spaces and have rules governing spaces around unary and binary minus operators. We chose the simple expression option instead of the space-aware parser option.
Re: bug report
Thank now I see how it works.
Sorry for the noise.
Sorry for the noise.