|
|
Post by barryk on Feb 3, 2013 23:54:07 GMT 1
Big problem!
I have compiled BaCon many times on my Mele A1000, which has an ARM Cortex-A8 CPU, 512MB RAM.
I use the previously-compiled 'bacon' binary executable to compile the latest 'bacon.bac'.
I compiled 1.0.28 ok, no problem at all, in fact, I compiled it on my USB Flash drive, without any swap partition.
However, compiling 1.0.29 is incredibly slow, and I had to abort it.
At first I did it as before, on the Flash drive, then I noticed that the conversion to C count was incredibly slow, like it reached "900" after a few hours.
So, I plugged in my USB hard drive, did a swapon of the swap partition, set the temporary working dir to the hard drive also.
That was early-evening, I left it running, next morning I got up and found that it had only reached "2053" ...less than half way.
So, I aborted it.
The thing is, I have even compiled SeaMonkey on this Mele. Something is making 1.0.29 compile extraordinarily slow.
I just checked on my x86 laptop, yep, compiling is just a few seconds!
So, my ARM build of Puppy has to stay at 1.0.28!
Regards,
Barry Kauler
|
|
|
|
Post by barryk on Feb 4, 2013 0:58:24 GMT 1
Don't have any time right now, have to do other stuff, but did a quick test...
Used bacon binary 1.0.25 to compile bacon.bac 1.0.29 on the Mele -- very fast!
Only took a few minutes.
The extreme slowness was using binary 1.0.28 to compile.
I think that the time before that, I used 1.0.27 (or was it 1.0.26) to compile 1.0.28
-- I will have to confirm that later.
|
|
|
|
Post by barryk on Feb 4, 2013 1:06:14 GMT 1
Binary 1.0.26 compiles bacon.bac 1.0.29 fast.
So the culprit is either 1.0.27 or 1.0.28.
Gotta go.
|
|
2lss
Full Member
Posts: 140
|
Post by 2lss on Feb 4, 2013 2:39:40 GMT 1
Barry,
I've ran into this before. I think that building the bacon binary with a different version is not really a good practice. I could be wrong, maybe Peter can elaborate further.
I usually use the bacon.ksh shell script to build the bacon binary of the same version. Using mksh its not that much slower than the binary.
|
|
|
|
Post by barryk on Feb 4, 2013 9:33:56 GMT 1
2lss,
That's what I have always done, right from the very first bacon binary that I compiled with bash.
I have done some more testing, and bacon 1.0.26 is the last version that works on ARM.
I compiled each of these, then ran "bacon -v":
BaCon "bacon -v"
1.0.25 ok
1.0.26 ok
1.0.27 segmentation fault
1.0.28 ok
1.0.29 segmentation fault
These are the binary bacon versions used to compile:
BaCon Compiled with
1.0.26 1.0.25
1.0.27 1.0.26
1.0.28 1.0.26
1.0.29 1.0.26
...used 1.0.26 as .27 doesn't work, and 1.0.28 is incredibly slow (as reported first post).
The 1.0.26 binary bacon compiles fast.
Anyway, I will download bacon.sh 1.0.29 and try that.
|
|
|
|
Post by Pjot on Feb 4, 2013 9:39:00 GMT 1
Folks
Generally it is not a good idea to use the former binary version to compile the new version. Because older binary versions generate older C code, and this is code which most likely has changed in newer versions - it might even be that newer versions require the new C code.
Therefore best practice is always to first use a Shell version to compile the BaCon binary. This ensures that current C code is used for the BaCon binary.
BR,
Peter
|
|
|
|
Post by barryk on Feb 4, 2013 10:02:06 GMT 1
I have just compiled bacon.bac 1.0.29 using bacon binary 1.0.26 on my x86 laptop. No problem. works fine, and fast.
So, it is an ARM problem.
I have just tried to compile bacon.bac 1.0.29 using bacon.bash 1.0.29 on my Mele, but no-go, get an error:
"ERROR: variable in LOCAL statement at line 52 in file 'bacon.bac' was defined previously!"
That is running on Ubuntu, bash 4.1.5.
So, the situation is I cannot use any later than 1.0.26 on the Mele, and I presume any other ARM system.
|
|
|
|
Post by Pjot on Feb 4, 2013 10:07:33 GMT 1
Hi Barry,
You can only get that error if there are old .c or .h files in your directory.
So, before starting the conversion process, cleanup your current directory by removing old generated files (rm *.c and rm *.h). Then try again.
BR,
Peter
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Feb 4, 2013 10:13:32 GMT 1
FYI - I cleaned everything out of my build directory except bacon.bac (current release) and my updated bacon_nocat.bac source files. I then used the current bacon.bash to compile each one. The diff program says they are different but no errors reported converting or compiling.
|
|
|
|
Post by barryk on Feb 4, 2013 10:16:53 GMT 1
Running the same thing, that is bacon.bash 1.0.29, compile bacon.bac 1.0.29, on my x86 laptop, it gets further:
bash ./bacon.bash -d /tmp bacon.bac
Converting 'bacon.bac'... 487
ERROR: variable in LOCAL statement at line 487 in file 'bacon.bac' was defined previously!
Using Wary Puppy, bash 4.1.0.
|
|
|
|
Post by Pjot on Feb 4, 2013 10:24:24 GMT 1
Barry, did you clean the /tmp directory before converting?
|
|
|
|
Post by barryk on Feb 4, 2013 10:36:06 GMT 1
On both Mele and my x86 laptop, I ran
rm -f /tmp/*c
rm -f /tmp/*.h
bash ./bacon.bash -d /tmp bacon.bac
And still got exactly the same errors.
However, I did another test, created a new clean empty dir /tmp/temp1, then:
On my laptop:
bash ./bacon.bash -d /tmp/temp1 bacon.bac
...looking good!
yep, compiled OK.
I just noticed, bacon compiler also creates .tmp file(s), probably these need to be deleted also.
So, on the Mele:
rm -f /tmp/*c
rm -f /tmp/*.h
rm -f /tmp/*.tmp
bash ./bacon.bash -d /tmp bacon.bac
...looking good!
Reporting this in real time, so have to wait awhile, the Mele has a very slow CPU...
Note: those left-over temporary files from a previous failed compile, messing up current compile, is not a good situation. it is going to cause confusion for many people I think.
Something should be done to avoid this situation.
Perhaps each compile can create the temp files with unique file names, using the date, or whatever.
Meanwhile, the Mele is still chugging along, still compiling...
|
|
|
|
Post by Pjot on Feb 4, 2013 10:44:32 GMT 1
You are right - if these .tmp files still exist in your directory it means you have an incomplete build, like it was interrupted during the conversion process.
Note that these issues only can occur in case of the shell script versions of BaCon. All temporary files are deleted automatically when the conversion process is finished successfully. If an error occurs, the temporary files remain on disk for troubleshooting. This was one of the first change requests on BaCon.
And it is always tricky to remove existing files in a directory....
BR,
Peter
|
|
|
|
Post by barryk on Feb 4, 2013 11:04:22 GMT 1
Yes!
On the Mele, after compiling bacon.bac, using bacon.bash, I renamed the binary as "bacon29", then ran:
./bacon29 -d /tmp bacon.bac
...off she went, fast!
Note, I always use the bacon binary, the speed difference compared to bacon.bash is enormous.
Now for the big moment:
./bacon -v
...good, reports the version.
What is interesting though, is using the older bacon binaries on my x86 laptop, to compile bacon.bac 1.0.29, works. But not on ARM.
Thanks for the feedback, I am pleased that I am now able to upgrade to 1.0.29 on the ARM puppies!
|
|
|
|
Post by Pjot on Feb 4, 2013 11:45:21 GMT 1
Thanks for letting know!  I will add a question to the shell versions in case they find older temporary files, something like "Old files were found, delete them (y/n)?". BR, Peter |
|
