Re: [fpc-devel] convert comment help to fpcdoc
On 2011/07/18 12:00 PM, Marco van de Voort wrote: No, it is more wiki like tags in an XML format. But that is out of source docs, what is currently most prefered by the documentation author. (and I like it more to) Are you aware of NaturalDocs (www.naturaldocs.org)? I use it because it doesn't clutter up the source code with unreadable javadoc tags. The comments are naturally formatted. They seem to be just normal comments if you are not aware that NaturalDocs is being used. I think the current version is written in some scripting language that can easily be modified to provide different output from the current html. Unfortunately it doesn't 'know' pascal as good as pasdoc does, but the clear syntax makes up for it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Const optimization is a serious bug
Based on this promise, the compiler may decide to do some optimization. It will also warn you if it detects inside the code that you break your promise. Based on my new knowledge of const strings I revisited the bug I mentioned previously. I still have no idea where exactly I made the error. And I never got a warning about the promise being broken. For me the advantages of using const strings are completely dwarfed by the time required to ensure I keep my side of the promise and still have the risk that some small change in the future will break it without causing compiler warnings. As soon as you understand this subtle difference, the problem disappears. My suggestion is that the gist of the documentation be changed from Use const strings, it is good for you to Const strings are powerful. They are also dangerous. Don't use it unless you really really understand them ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Did you have a look at AVR? They use GCC, although commercial compilers are also available should you need it. I have used GCC-AVR for years without problems. Marco van de Voort wrote: In our previous episode, Michael Schnell said: Which is that then? Afaik the microchip own, and the Hitech compilers can do so perfectly? CCS Same had been the cheapest option for a C compiler to try out the PICs. Well, the microchip one academic option is free. So CCS gives money with their tools ? :-) I never switched to something else, as I am abandoning the 8 bit PICs for the 16 Bit ones that are supported by a decent gcc that can be tested in a non-payed public version and now the commercially supported version. I already switched to 16-bit (33FJA128MC510 and -804) long ago, and am very happy with them. But I still use the PIC18F60j60 part since there is no 16-bit integrated ethernet part, and as spare replacement for legacy parts. The PIC32 look interesting, but there is no motorcontrol (quadrature decoder) in that family yet, something that I require. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Circular references and forward declarations
Marco van de Voort wrote: Yes, but from what I remember it was canceled because the amount of periphery on the chip is poor. I also looked at ARM, but while there is more choice there, it is fragmented over multiple vendors, with multiple toolchains (if a free one exists at all) What was canceled? The AVR devices is certainly not and neither are the GCC toolchains (one for 8b and one for 32b). PIC32 is only interesting because it is slightly faster and has more mem. But that would be more a future proofing thing, since we don't really lack it atm. I don't want to start a AVR/PIC fight because it always ends up in a religous war and this is the wrong list anyway. However, some of my reasons for moving from PIC to AVR are: - AVR is faster, - has usually more memory, which programs faster - has higher code density, - has cheaper tools (programmers etc) - has free toolchains for all devices The down side is that Microchip has never to my knowledge obsoleted a device, whereas Atmel quite often do obsolete parts which then requires recompiling the program for the replacement part. But motorcontrol parts (integrated quadrature encoder, preferably several) is absolutely mandatory. I have never used motor control but there are parts intended for this ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Possible memory leak in cthread.
Hi everybody,
The program:
program memleak;
{$mode objfpc}{$H+}
uses
cthreads;
begin
end.
If I run the program using valgrind I get the following output:
==1944==Invalid free() / delete /
delete[]
==1944==at 0x4025DFA: free
(vg_replace_malloc.c:323)
==1944==by 0x4171664: (within /lib/tls/i686/cmov/libc-2.9.so)
==1944==by 0x4020422: _vgnU_freeres (vg_preloaded.c:60)
==1944==by 0x40E5B23: _Exit (in /lib/tls/i686/cmov/libc-2.9.so)
==1944==by 0x405C77C: (below main) (in /lib/tls/i686/cmov/libc-2.9.so)
==1944== Address 0x is not stack'd, malloc'd or (recently) free'd
==1944== LEAK SUMMARY:
==1944==definitely lost: 0 bytes in 0 blocks.
==1944== possibly lost: 0 bytes in 0 blocks.
==1944==still reachable: 1,094 bytes in 5 blocks.
==1944== suppressed: 0 bytes in 0 blocks.
I use Kubuntu 9.04, fpc 2.2.4
Can I log this as a bug?
Regards
Wimpie
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Possible memory leak in cthread.
OK it is logged.
Jonas Maebe wrote:
On 05 Aug 2009, at 13:55, Wimpie Nortje wrote:
program memleak;
{$mode objfpc}{$H+}
uses
cthreads;
begin
end.
If I run the program using valgrind I get the following output:
==1944==Invalid free() / delete /
delete[]
==1944==at 0x4025DFA: free (vg_replace_malloc.c:323)
==1944==by 0x4171664: (within /lib/tls/i686/cmov/libc-2.9.so)
==1944==by 0x4020422: _vgnU_freeres (vg_preloaded.c:60)
==1944==by 0x40E5B23: _Exit (in /lib/tls/i686/cmov/libc-2.9.so)
==1944==by 0x405C77C: (below main) (in
/lib/tls/i686/cmov/libc-2.9.so)
==1944== Address 0x is not stack'd, malloc'd or (recently)
free'd
This invalid free is probably the reason for the memory leak.
It even happens for this program:
{$linklib c}
begin
end.
There is probably some error in FPC's startup code (the code in
fpc/rtl/linux/i386/cprt0.as) which doesn't initialise some libc
pointer. You should indeed report a bug about this.
To Graeme and Michael: heaptrc is useless/irrelevant to analyse memory
leaks reported inside libc. Such errors can always be due to wrong
usage of the C library from within FPC code.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
