Pelles C forum
Pelles C => Announcements => Topic started by: Pelle on October 08, 2010, 03:50:54 PM
-
Pelles C version 6.50, Release Candidate #1, is now available for download:
http://www.smorgasbordet.com/pellesc/download.htm (http://www.smorgasbordet.com/pellesc/download.htm)
Changes:
http://www.smorgasbordet.com/pellesc/changes_600_650.htm (http://www.smorgasbordet.com/pellesc/changes_600_650.htm)
The German translation will come later.
Pelle
-
Hello Pelle,
It's very good to hear from you - thank you for 6.5 RC1.
-FYI-
Compiling BCX with Pelles C 6.00 (30,671 lines of code) -> compile time 0 minutes 45 seconds
Compiling BCX with Pelles C 6.5 RC1 (30,671 lines of code) -> compile time 4 minutes 50 seconds
Memory usage during Pelles C compile peaks at about 500MB with 50% CPU utilization.
Development laptop is an Intel dual core Windows 7 Ultimate 32-bit 4GB 2.1GHZ
-
Hi Pelle, Welcome back!
-
Hi Pelle,
I am happy, that you are back!
I will take a look at your new baby. ;)
-
Bug reported at http://forum.pellesc.de/index.php?topic=3324 (http://forum.pellesc.de/index.php?topic=3324)
I would suggest to report bugs with the RC here, so Pelle only needs to monitor one thread.
-
Hi Pelle,
Thanks for the announcement.
-
Thank you all!
MrBCX: could you please post the actual C code? I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?
AlexN: I will look at the bug...
-
AlexN: myassert.h, winvi.h and page.h are missing. At least one of them must be important. Can you make sure I have *all* the needed files to compile search.c ...?
-
AlexN: myassert.h, winvi.h and page.h are missing. At least one of them must be important. Can you make sure I have *all* the needed files to compile search.c ...?
Sorry, but I thought only the half way.
At this link http://forum.pellesc.de/index.php?topic=2647.0 (http://forum.pellesc.de/index.php?topic=2647.0), I posted the complete project some time before. But be careful it is posted in two parts (with the same name).
-
Thanks for new version to test!
Even with this version i can't get Add-In function/macro AddIn_GetProjectShells to work ?
With TestGetProjectShells Add-In i get these results:
C:\code\PellesC\test_6.5\output\TestGetProjectShells.obj
nLen=30, 00 28 43 43
(CC) $(CCFLAGS) "$!" -Fo"$@"
C:\code\PellesC\test_6.5\TestGetProjectShells.dll
nLen=35, 00 28 4C 49
(LINK) $(LINKFLAGS) -out:"$@" $**
In PPj-file those lines are:
$(CC) $(CCFLAGS) "$!" -Fo"$@"
$(LINK) $(LINKFLAGS) -out:"$@" $**
-
MrBCX: could you please post the actual C code?
Sure -- The attached zip contains 'Bc.c' and 'PC.Bat', the batch file I use to compile and link BCX using the Pelles C system.
There are actually 40,275 lines, including comments.
I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?
I have 4gb but Windows 7 (32-bit) uses just under 3gb of that.
This HP laptop has a Intel T4300 dual core running @ 2.1ghz and is less than 6 months old.
-
First of all, thank you for the new version!
The bug with non-trivial switch stamements (http://forum.pellesc.de/index.php?topic=3288.0) seems to be fixed now.
UAC popup under Windows 7 is not fixed yet.
Found two new annoying bugs:
1) clicking on .ppj file opens it in POIDE's hex editor instead of opening the project
2) it is impossible to select non-TTF fonts in Options->Source->Font->Name selectbox
this is important because many fonts specifically designed for programmers are not TTF (e.g. my favourite Dina)
the only way to get them usable in 6.50 is to have them selected with 6.00 (like in my case), and do not clean the registry after 6.00 deinstallation.
EDIT: also, the font on help pages is smaller and harder to read now :(
-
Thank you all!
MrBCX: could you please post the actual C code? I havn't seen any problems like that on my machine. It sounds like it may be a matter of disk swapping. The compilation speed is either the same or faster here - but then again, I have plenty of RAM. How much RAM do you have installed in your machine?
In July 2007 I reported a similar problem to the Visual C++ Team at
Microsoft. The Borland compiler was compiling an optimized (-Ox flag)
BCX in less than 2 seconds while the Microsoft compiler was taking 324
seconds for an equivalently flagged compile.
Their final reply was, in part,
"Thanks for your feedback. The Visual C++ team has evaluated the bug and
determined it does not meet the guidelines necessary to warrant a fix.
To understand these guidelines please refer to
http://blogs.msdn.com/vcblog/articles/621116.aspx.
In particular, function that takes longest to compile is
RunTimeFunctions, which is a pretty big function. Compiler is not aware
that vast majority of the instructions are the printf calls, so it tries
to optimize the code the best possible. Also, there is a lot of control
flow which is based on global variables, so we can't really optimize
those--yet we spend a lot of time trying. We will consider changing our
optimizer technology in the future to add more analysis up-front, which
will enable us to wind down optimization in a function like this. In the
meantime, an easy workaround is to put #pragma optimize("g",off) around
this function."
I have unsuccessfully attempted to use the suggestion to turn off
#pragma optimize for the RunTimeFunctions sub while compiling BCX
with Pelle's C 6.5 RC1. If anyone can get this to work I
would appreciate knowing the specific details.
At that time, 2007, the Borland compiler produced a BCX.exe that ran faster
than that produced with any other compiler but I think that now the
Pelle's C 6.5 beta -Ot compiled BCX.exe has beat that time by about 10%.
Robert Wishlaw
-
AlexN: the problem should now be fixed. In the future, it would be helpful if you could reduce the problem to a smaller test case (the problematic function was indicated in the error message). Now I had to spend an hour creating a smaller case, and ten minutes to fix the problem. There are more of you than me, so I need all the help I can get.
MrBCX: Thank you for the code. Yes, more information is better. The biggest problem here is that the program contains a large number of literal strings. The compiler will always attempt to pool strings (fold indentical copies into a single copy, to reduce space). I have now increased the number of hash buckets for literal strings, to reduce the chain of strings hashed to the same bucket. On my machine this reduces the compilation time from 125 seconds down to 38 seconds. This is a few seconds slower than 6.0, but 6.50 does more work so this is expected. There are other problems here (like the ones in Robert's post), but I can't do much about that for the moment...
timovjl: Yes, AddIn_GetProjectShells() seems totally broken. The last recorded change was in 2007 when it was split into ANSI and Unicode versions. Maybe something happend then. Anyway, it should be fixed now.
-
UAC popup under Windows 7 is not fixed yet.
Which UAC popup?! You need to be admin to run the IDE, if that's what you mean. This is by design.
1) clicking on .ppj file opens it in POIDE's hex editor instead of opening the project
I will look at it.
2) it is impossible to select non-TTF fonts in Options->Source->Font->Name selectbox
Not really. What I want to do is to remove 80% of the fonts on my machine - installed by Windows, or more likely some other application - for languages I don't understand, with characters I can't read. If I don't do this, the list of fonts is annoyingly long here. You can play with the attached program to see which condition is filtering out your favorite font...
EDIT: also, the font on help pages is smaller and harder to read now :(
There is a new button in the help window specifically for changing the font size. I suggest you use it!!
-
AlexN: the problem should now be fixed. In the future, it would be helpful if you could reduce the problem to a smaller test case (the problematic function was indicated in the error message). Now I had to spend an hour creating a smaller case, and ten minutes to fix the problem. There are more of you than me, so I need all the help I can get.
Thank you for the fix and sorry that I don't reduce the problem (but at last time I had problems with this program and Pelles C, I tried some evnings to reduce the problem without sucess, so I forgot it this time - sorry again).
-
Thank you for the fix and sorry that I don't reduce the problem (but at last time I had problems with this program and Pelles C, I tried some evnings to reduce the problem without sucess, so I forgot it this time - sorry again).
No problem - it was just a note to you and other people reading this thread.
(I will wait a few days before uploading Relase Candidate #2 - in case there is something else to be fixed).
-
If i open new .asm file for compiling it build or compile buttons/menus are not active in this version.
-
Is it a new feature or a bug? ???
When I create a new source or open a short short file, the area for the line numbers and folding information is not coloured untilo the bottom of the window. It is only coloured as far as the source is.
If it is a feature, I liked the old colouring more. :(
PS: This happens under Vista and XP.
-
This problem exists in this version too:
http://forum.pellesc.de/index.php?topic=3140.0 (http://forum.pellesc.de/index.php?topic=3140.0)
-
Which UAC popup?! You need to be admin to run the IDE, if that's what you mean. This is by design.
Ah, didn't know that it's by design.
2) it is impossible to select non-TTF fonts in Options->Source->Font->Name selectbox
Not really. What I want to do is to remove 80% of the fonts on my machine - installed by Windows, or more likely some other application - for languages I don't understand, with characters I can't read. If I don't do this, the list of fonts is annoyingly long here. You can play with the attached program to see which condition is filtering out your favorite font...
Found the problem.
Windows SDK documentation says this about EnumFontFaceProc:
pntm - Pointer to a structure that contains information about the physical attributes of a font.
The function uses the NEWTEXTMETRICEX structure for TrueType fonts; and the TEXTMETRIC structure for other fonts.
Thus attempting to use fields of NEWTEXTMETRICEX *pntm lead to invalid results.
A check for whether the font is TTF is needed:
if (dwFontType == TRUETYPE_FONTTYPE)
{
/* The font must have at least one of the supported locales */
if ((pntm->ntmFontSig.fsCsb[0] & pls->lsCsbSupported[0]) == 0 &&
(pntm->ntmFontSig.fsCsb[1] & pls->lsCsbSupported[1]) == 0)
return 1;
}The attached file contains the fixed source (and 64-bit .exe) and test output from my machine.
1.txt is what you're trying to avoid, 2.txt is what IDE currently does, 3.txt is the same plus non-TTF fonts.
EDIT: also, the font on help pages is smaller and harder to read now :(
There is a new button in the help window specifically for changing the font size. I suggest you use it!!
I see the button, and it's really useful.
However, it doesn't fix the problem. The font is too bold and contrasty because of antialiasing. Font lines are always at least 2 pixels wide. They were thinner in v6.0. Perhaps the old version didn't use anti-aliasing.
(I don't know if it has to do something with the added DPI awareness. I have 22" 16:10 1680x1050 monitor with default Windows DPI settings)
If it is possible to tune anti-aliasing of fonts in the Help, or optionally turn it off - that would be nice. If it's hard to do - nevermind.
-
Which UAC popup?! You need to be admin to run the IDE, if that's what you mean. This is by design.
Ah, didn't know that it's by design.
It's not realy by design. I installed Pelles C 6.50 RC1 on an USB-stick to my portable applikations and start it with an command line like this:
poide /n /x /xml my65.xml
... and no UAC pops up. :)
I used it with Vista and XP.
-
Should there be a portable zip version of these rc versions ?
-
Should there be a portable zip version of these rc versions ?
If you copy your installed Pelles C directory on an USB-stick and copy the sysdefs.tag from the %APPDATA%\Pelles C directory in the bin directory on the USB-stick and start your poide with the option /xml (like in my previous message) all works fine. :)
-
Absolutely excellent... Thank you Pelle!
-
Wow, such a good news! Thank you, Pelle!
-
If i open new .asm file for compiling it build or compile buttons/menus are not active in this version.
I can't remember right now if it used to work, but I will look at it...
-
Is it a new feature or a bug? ???
When I create a new source or open a short short file, the area for the line numbers and folding information is not coloured untilo the bottom of the window. It is only coloured as far as the source is.
It's a new feature. It makes it a little clearer where the file actually ends. It took me a few days to get used to it, but I like this better now...
-
This problem exists in this version too:
http://forum.pellesc.de/index.php?topic=3140.0 (http://forum.pellesc.de/index.php?topic=3140.0)
Not sure what is correct or not right now. I will look at it...
EDIT: I guess most sane programmers avoid octal escape sequences. I know I do. Should be fixed...
-
Found the problem.
Windows SDK documentation says this about EnumFontFaceProc:
pntm - Pointer to a structure that contains information about the physical attributes of a font.
The function uses the NEWTEXTMETRICEX structure for TrueType fonts; and the TEXTMETRIC structure for other fonts.
Thus attempting to use fields of NEWTEXTMETRICEX *pntm lead to invalid results.
A check for whether the font is TTF is needed:
The attached file contains the fixed source (and 64-bit .exe) and test output from my machine.
1.txt is what you're trying to avoid, 2.txt is what IDE currently does, 3.txt is the same plus non-TTF fonts.
Ah, OK. Missed that one. Thanks...!
I see the button, and it's really useful.
However, it doesn't fix the problem. The font is too bold and contrasty because of antialiasing. Font lines are always at least 2 pixels wide. They were thinner in v6.0. Perhaps the old version didn't use anti-aliasing.
(I don't know if it has to do something with the added DPI awareness. I have 22" 16:10 1680x1050 monitor with default Windows DPI settings)
If it is possible to tune anti-aliasing of fonts in the Help, or optionally turn it off - that would be nice. If it's hard to do - nevermind.
Displaying the help file *should* be completely out of my control (it's done by the HTMLHelp engine). Since version 6.0 I really only flipped on a checkbox in the help generator program (for the new button), and recompiled. I can't see how that can affect anything. Also, I don't see any difference on my machine.
EDIT: of course, the font is choosen from a family of fonts which depends on the Windows version the help is displayed on. You may get "Segoe UI" which needs "ClearType" to be actived on a LCD screen (I have this enabled). Is this "off" on your computer?
-
Is it a new feature or a bug? ???
When I create a new source or open a short short file, the area for the line numbers and folding information is not coloured untilo the bottom of the window. It is only coloured as far as the source is.
It's a new feature. It makes it a little clearer where the file actually ends. It took me a few days to get used to it, but I like this better now...
Would it be possible to add a line or some else at the end of text :), so that the text background not only flow out. I would like more (but it is not really necessary).
-
On Windows XP SP3 32 bit any attempt to reach any declaration file results in error.
(http://img440.imageshack.us/img440/7544/errdef.png)
I have reinstalled and rebuilt system definitions database several times with no success.
Also since version 5 if any optimization type is chosen in project options, compilation fails with fatal error: Internal error: get_rule(). Only if I choose no optimization the project is compiled normally. Unfortunately I cannot reproduce it on small project, but anyone can download the source http://downloads.sourceforge.net/pnotes/PNotesSource_6_5_110.zip (http://downloads.sourceforge.net/pnotes/PNotesSource_6_5_110.zip) and try to compile it with optimization.
-
Pelle,
this is the shortes fragment from lamer Pnotes that generates the error.
And is also the only code lines that prevent compilation of module "controlpanel.c" in Pnotes project.
Same error occourse to some other modules, when I'll have time I'll try to isoled code fragments.
#include <windows.h>
#include <commctrl.h>
///** List View columns sorting ********************************************************/
typedef struct _LVSORT_TYPE {
int iSortName;
int iSortPriority;
int iSortCompleted;
int iSortProtected;
int iSortDate;
int iSortSchedule;
int iSortTags;
int iSortGroup;
int iSortBackOrigin;
int iSortBackDate;
}LVSORT_TYPE;
/** Module variables ********************************************************/
static LVSORT_TYPE m_LVSortBack = {LVS_SORTASCENDING, LVS_SORTASCENDING};
BOOL CALLBACK Tst (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
if(m_LVSortBack.iSortName == LVS_SORTASCENDING)
m_LVSortBack.iSortName = LVS_SORTDESCENDING;
else
m_LVSortBack.iSortName = LVS_SORTASCENDING;
return FALSE;
}
-
lamer I compiled your program making the following modifications.
In module "controlpanel.c" I replaced all occourrence of code like that described in my previous post with the following construct:
m_LVSortBack.iSortName = (m_LVSortBack.iSortName == LVS_SORTASCENDING ?
LVS_SORTDESCENDING : LVS_SORTASCENDING
);
In module "main.c" replace
if(m_NewDLLVersion)
m_nData.cbSize = sizeof(NOTIFYICONDATAW);
else
m_nData.cbSize = NOTIFYICONDATAW_V1_SIZE;
with:
m_nData.cbSize = m_NewDLLVersion ? sizeof(NOTIFYICONDATAW) : NOTIFYICONDATAW_V1_SIZE;
Then you should be able to compile with optimization.
-
frankie,
thank you very much! ;D Actually this is the same code, so why does it behave different?
Any suggestion about definitions error? It is inconvenient to work without.
Ah, one more thing. The following fragment
case LVN_BEGINDRAG:{
...
RECT rc;
LVITEMW lvi;
NMLISTVIEW *plv = (NMLISTVIEW *)lParam;
...
rc.left = LVIR_BOUNDS;
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
...
raises a warning:
warning #2130: Result of comparison is constant.
on line
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
This warning did not appear in previous versions. I don't see any comparison here.
-
raises a warning:
warning #2130: Result of comparison is constant.
on line
ListView_GetItemRect(m_hListMain, plv->iItem, &rc, LVIR_BOUNDS);
This warning did not appear in previous versions. I don't see any comparison here.
In macro: ListView_GetItemRect()
#define ListView_GetItemRect(hwnd,i,prc,code) (BOOL)SNDMSG((hwnd),LVM_GETITEMRECT,(WPARAM)(int)(i),((prc)?(((RECT*)(prc))->left = (code),(LPARAM)(RECT*)(prc)):(LPARAM)(RECT*)NULL))
-
In macro: ListView_GetItemRect()
#define ListView_GetItemRect(hwnd,i,prc,code) (BOOL)SNDMSG((hwnd),LVM_GETITEMRECT,(WPARAM)(int)(i),((prc)?(((RECT*)(prc))->left = (code),(LPARAM)(RECT*)(prc)):(LPARAM)(RECT*)NULL))
Thank you!
-
lamer,
yes the code is the same but the compiler cannot get a reduction rule for it. It is an internal issue of the compiler.
Only Pelle can answer, I immagine that the get_rule() is a routine to retrieve the code optimization strategy, that for this case is missing.
-
Thx Pelle for the hard work... :)
-
get_rule() is part of the general instruction selection, and it's just where the bug gets visible. It has nothing to do with the real problem here.
The problem boils down to m_LVSortBack being a struct, and the expression is using the first member (of type int). Usually all struct/array/etc members, except the first one, will be associated with an internally generated symbol which is <base + field-offset>, with the type being that of the field (and not the struct). The first member is special, since base + 0 is too silly to be generated. Unless I'm really careful, I might try to assign an int to struct (like in this case). The code generator (obviously) don't know how to handle this...
Finding a better solution may take a while...
-
I see the button, and it's really useful.
However, it doesn't fix the problem. The font is too bold and contrasty because of antialiasing. Font lines are always at least 2 pixels wide. They were thinner in v6.0. Perhaps the old version didn't use anti-aliasing.
(I don't know if it has to do something with the added DPI awareness. I have 22" 16:10 1680x1050 monitor with default Windows DPI settings)
If it is possible to tune anti-aliasing of fonts in the Help, or optionally turn it off - that would be nice. If it's hard to do - nevermind.
Displaying the help file *should* be completely out of my control (it's done by the HTMLHelp engine). Since version 6.0 I really only flipped on a checkbox in the help generator program (for the new button), and recompiled. I can't see how that can affect anything. Also, I don't see any difference on my machine.
EDIT: of course, the font is choosen from a family of fonts which depends on the Windows version the help is displayed on. You may get "Segoe UI" which needs "ClearType" to be actived on a LCD screen (I have this enabled). Is this "off" on your computer?
I tuned Windows anti-aliasing settings and got much better fonts now.
-
I tuned Windows anti-aliasing settings and got much better fonts now.
If you're on Win-7, in the Control Panel->System->Advanced->Advanced tab there is a checkbox to turn font smoothing entirely off. The screen is soooo much easier to read without it.... Also, since Help uses IE, if you go into your browser settings and select Arial as your bas font I think you'll find it's a lot easier to read than whatever the default is.
Hope this helps...