Why compile Pelles C so slow?

[linnar]

@CommonTater

Wise words!

I will do as you write and like any other type.

I know I get impatient when I do not get it to work. I've been through it before. I think really give PellesC a Change.
An intermediate step is to use PellesC editor to LccWin32 for the program I'm doing now and then move on when I start the new program.

I will come back and write how it goes.

[CommonTater]

Ok, if you're going to use LCC under POIDE you may find my Quick Flags addin to be useful along with Timo's multi-compiler tool.  QF lets you manually edit the command line flags for the toolchain... Useful since LCC and POCC flags are different.

Best of luck with it...

[linnar]

I have worked a few days in PellesC with my big program. I have to change very much code for it to work. It still does not work, has much to do.

I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
   LPSTR charDateFBS;

   //Get the date
   charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");

Use PellesC with LCC-Win32's lib.

It did not work!

Timo's little program "Select Compiler" I understand me not to. I have entered all of LccWin32. Nothing happens when I click on the button. A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?

[CommonTater]

I have worked a few days in PellesC with my big program. I have to change very much code for it to work. It still does not work, has much to do.

I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
   LPSTR charDateFBS;

   //Get the date
   charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");

I take it the ac_ClockGetLocalTime_1 is a self-written procedure... which is going to need debugging.

Take a look at the Help File -> time.h header...  There are several time functions there you may be able to use to advantage.

The most likely problem you're running into is that LCC is not a standards driven compiler where Pelles C is... many of LCC's library functions may be differently named or simply not present on Pelles...  This is the big problem with non-standard code, you end up with a mess that does take some time to clear up.  BUT, once you're over that hump now, moving to the "next better tool" will be far easier...

[TimoVJL]

I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.

Use Define compatibility names (-Go)

Timo's little program "Select Compiler" I understand me not to ...

Have you copied SelCompiler.dll to PellesC\bin\AddIns-folder ?

A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?

Are you running that SelCompilerDlgTest.exe ? It for testing those dialogs only.

[linnar]

I have worked a few days in PellesC with my big program. I have to change very much code for it to work. It still does not work, has much to do.

I have been running the program! I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.
When I work in my program compiled with Pelle-C gets it wrong every time I get date time, the program dies with the error message from Windows:
   LPSTR charDateFBS;

   //Get the date
   charDateFBS=ac_ClockGetLocalTime_1("YY_MM_DD", "-");

I take it the ac_ClockGetLocalTime_1 is a self-written procedure... which is going to need debugging.

Take a look at the Help File -> time.h header...  There are several time functions there you may be able to use to advantage.

The most likely problem you're running into is that LCC is not a standards driven compiler where Pelles C is... many of LCC's library functions may be differently named or simply not present on Pelles...  This is the big problem with non-standard code, you end up with a mess that does take some time to clear up.  BUT, once you're over that hump now, moving to the "next better tool" will be far easier...

ac_ClockGetLocalTime_1 I have written. It is a feature of about 830 functions I wrote to speed up the work. I started developing my function libraries with Symantec C (/ C + +) which is the predecessor to Digital Mars. When I went over to LccWin32 so did all the features of my library without any problems. If I should continue with Pelle's C-I have to write about a lot of code.

I intend to continue to debug all the code in the Pelle-C from time to time to ensure that the code works in most compilers, but I do develop in LccWin32.

Pelle-C is the most slow tool I've tested in recent days. I simply do not have time to sit and wait up to one hour per night on it to compile. If I compile 30 times in one night, it takes a total of 1 minute and 30 seconds in LccWin32. With Pelle-C, it takes 60 minutes. With the others I tested, it takes between 10 minutes and 20 minutes.

[CommonTater]

Well, I will give you that Pelles is a bit slowish compiling, but in my case that's far less of a concern than the end result... I just  grab a coffee or go pee (two events that may be connected) while it's chunking away. 

I do understand that conversion between libraries and compilers is a bit of a burn out... but I wouldn't write Pelles of for any new projects you're starting... Thing is, for what I do (mostly small to medium projects and one-offs) it's never been anything but 100% reliable... which is more than I can say for VC++ or MinGW.

I wish you luck on this... It's kind of a shame the conversion didn't go as planned.

[linnar]

Well, I will give you that Pelles is a bit slowish compiling, but in my case that's far less of a concern than the end result... I just  grab a coffee or go pee (two events that may be connected) while it's chunking away. 

I do understand that conversion between libraries and compilers is a bit of a burn out... but I wouldn't write Pelles of for any new projects you're starting... Thing is, for what I do (mostly small to medium projects and one-offs) it's never been anything but 100% reliable... which is more than I can say for VC++ or MinGW.

I wish you luck on this... It's kind of a shame the conversion didn't go as planned.

Do not worry, Pelle-C is the best of the tools I tested. I am not leaving! Have already begun to explore why it is slow. I run a couple of other programs in the background while working, so early, it looks as if it's editor who takes very good time to get started. Then the compiler very much power from the CPU. My CPU goes up to the ceiling and stay there long. All other programs will slow down the speed while compiling. In addition, the final binary file smaller than I've seen with any other compiler. If the compiler does not optimize the code so effective, it would instead compile faster, much faster, I think. The editor should be speeded up. I think it does more than to be an editor.

[linnar]

I received a return drew sever where "eof" did not work. Changed to "_eof" and it worked.

Use Define compatibility names (-Go)

OK! Thanks for the tip!

Timo's little program "Select Compiler" I understand me not to ...

Have you copied SelCompiler.dll to PellesC\bin\AddIns-folder ?

Uups, I had missed that small detail!

A small window "Wait for the Testing" is open and doing nothing. Does anyone know how to do?

Are you running that SelCompilerDlgTest.exe ? It for testing those dialogs only.

Hmmm, I chose it because it was already entered data for the compilers that I have. Believed that the "test" still worked.

I'll get what you have described and returns when it works. It would be great if I could use Pelle's editor to LccWin32!

[CommonTater]

Ok... maybe some simple direction on setting up an add in would help...

Addins are DLL files that get parked in the bin\addins directory for Pelles C ...  usually at

C:\program files\Pelles C\Bin\Addins

There are two flavours... If you are running the 64 bit version of POIDE use the 64bit DLL... otherwise use the 32 bit one.  So exit POIDE and drop the DLL into the folder then restart POIDE...

Now go to Tools -> Customize -> Addins and check the box beside the addin to enable it and OK your way back to the main window.

Next go to Tools-> Options -> Addins and click the addin... then the options buttons....

It's Timo's addin so I'll feel more comfortable if he takes you through the setup...

[linnar]

I have tested "SelCompilerDlgTest.exe" named "SelCompilerWS-1.2"!
- It worked fine with adding it to the Pelle-C
- Click on the menu for SelCompiler
- It opened a small window with the "PellesC" and "Options ..."
- It also opened a dialog box that says "Wait for the Testing".
- I clicked on the button
- Click "Options ..."
- A window was opened
- Click the "New"
- I entered all the data for LccWin32
- Click the "Save"
- Closed down SelCompiler
- Opened SelCompiler again and there were no new button with the name I wrote in and everything I typed was gone.

Which version should be used?
I've found:
SelCompiler_WS-3.zip
SelCompiler_WS_9.zip
SelCompiler.zip
SelCompiler-1.1.zip
SelCompilerWS-1.2.zip

EDIT:
OK!
I have it!
It must click "New" before clicking "Save".
It gets a little illogical at first look but then I understand what is meant by "New".

Now I do other things, will return in a few hours when I have time to test!

[CommonTater]

The "selcompilerdlgtest.exe" file is only a test platform for the dialog itself.  It is NOT an active addin...

Follow the steps I outlined...
If you have further questions, I'm sure Timo will help...

http://forum.pellesc.de/index.php?topic=3250.msg14561#msg14561

[TimoVJL]

It must click "New" before clicking "Save".
It gets a little illogical at first look but then I understand what is meant by "New".

OK. changed to save too.

[linnar]

The "selcompilerdlgtest.exe" file is only a test platform for the dialog itself.  It is NOT an active addin...

Follow the steps I outlined...
If you have further questions, I'm sure Timo will help...

http://forum.pellesc.de/index.php?topic=3250.msg14561#msg14561

Everyone has the word "test" in the name.
There is a variant that has the word "test" but it has none .exe-file so I imagine that it can not be used.

[CommonTater]

linnar... are you reading the instructions Timo and I have given you?

*There is no executable file*... it is a DLL file that is placed in a special folder so that it is loaded by POIDE (Pelles C editor) and works from inside the editor... hense the name "Addin"...

Go take a look at my QuickFlags addin... there's no exe file there, either.