Vincent Snijders wrote on do, 12 mrt 2009:
I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as developer. Maybe you disagree with that trade off.
No, it's simply an unimplemented
On 11 Mar 2009, at 15:12, Jonas Maebe wrote:
It may even be quite challenging to generate debug information for
something like that with Stabs. For DWARF, it seems there is some
code that generates debug information in some cases, but only for
var a: type absolute b;-style expressions
On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:
And in fact, the same can be done to generate for properties that
directly
map to variables/fields. Just one question: what should the debug
information point the debugger to in case of
a) a property without a read specifier, but with a
On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:
writing a property directly in the field is a hack
No, it's guaranteeing future compatibility, because by using a
property you ensure that you can later on replace the setter with a
procedure if necessary, without breaking existing
On 14 Mar 2009, at 09:46, dmitry boyarintsev wrote:
No, it's guaranteeing future compatibility, because by using a
property you
ensure that you can later on replace the setter with a procedure if
necessary, without breaking existing source code (at least in FPC
2.3.1; FPC
2.2.x misses
On 14 Mar 2009, at 10:42, Florian Klaempfl wrote:
Jonas Maebe schrieb:
It turned out that DWARF2 was enough, so the implementation should
already work with currently released GDB versions (see
http://bugs.freepascal.org/view.php?id=13313 for some caveats).
And in fact, the same can be done
On 14 Mar 2009, at 11:32, Luca Olivetti wrote:
El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl flor...@freepascal.org escribió:
a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or that field?
Nothing. This property is not readable.
On 14 Mar 2009, at 11:52, Michael Van Canneyt wrote:
The watches window shows 'Cannot read a write-only property'.
Ok, thanks. Support for DWARF2 debug info for properties with an
accessor that does not pass via a function is committed.
Jonas
On 14 Mar 2009, at 15:00, Paul Ishenin wrote:
Jonas Maebe wrote:
Ok, thanks. Support for DWARF2 debug info for properties with an
accessor that does not pass via a function is committed.
I'm glad to check it but how (fpc r12883)?
c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl
On 14 Mar 2009, at 15:42, Paul Ishenin wrote:
Tomas Hajny wrote:
Keeping -gl instead of -gw?
Sorry, leave out was not in my head dictionary :)
c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp
(gdb) break test.pp:8
invalid dwarf2 offset 4243567
No luck :(
Strange, that error
On 14 Mar 2009, at 15:27, Paul Ishenin wrote:
Jonas Maebe wrote:
It's the DWARF version of the lineinfo unit. It's only required to
get line numbers in backtraces when a program crashes. Apparently,
it hasn't been ported to Win32 yet, but it's not required to debug.
Just leave out
On 14 Mar 2009, at 15:59, Paul Ishenin wrote:
Jonas Maebe wrote:
Strange, that error looks very much like the one that should have
been fixed by http://bugs.freepascal.org/view.php?id=12872
Yes.
I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386
On 14 Mar 2009, at 15:59, Paul Ishenin wrote:
Jonas Maebe wrote:
Strange, that error looks very much like the one that should have
been fixed by http://bugs.freepascal.org/view.php?id=12872
Yes.
I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386
Michael Schnell wrote on di, 17 mrt 2009:
I still did not yet get any discussion rolling on the issue of pure
read functions (that have no side-effect).
I did discuss it in my first mail to this thread. It first requires
the following two problems to be solved, and none is particularly
On 17 Mar 2009, at 22:51, Léo Willian Kölln wrote:
No problems so far, but when i want to implement my functions using
the RTL, i just see arguments, parameters and returns of String.
As far i´ve read, they are aways Ansistrings, i´m right? Or i need
inform the compiler of this? (Q1)
It
On 14 Mar 2009, at 15:42, Paul Ishenin wrote:
Tomas Hajny wrote:
Keeping -gl instead of -gw?
Sorry, leave out was not in my head dictionary :)
c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp
(gdb) break test.pp:8
invalid dwarf2 offset 4243567
In the mean time, we got basic
Marc Weustink wrote on do, 19 mrt 2009:
Marc Weustink wrote:
If we cannot solve this, in case of DWARF2 i think we can leave
those attributes out.
I've tested this (by editing the .s file) and gdb still seems to work
and doesn't complain anymore.
Can you test the attached patch? I
Paul Ishenin wrote on do, 19 mrt 2009:
Jonas Maebe wrote:
I've tested this (by editing the .s file) and gdb still seems to work
and doesn't complain anymore.
Can you test the attached patch? I tried to send it to Paul, but mail.ru
I have tested. No more warnings!
But, it uses external
On 20 Mar 2009, at 16:46, dmitry boyarintsev wrote:
i have a question: i'm using fpc trunk, so copmiled i386 units are not
located at /usr/local/lib/fpc/2.3.1/units/i386-darwin. Is there any
way to reconfigure the building script, so compiled units are taken
from the proper directory?
The
On 20 Mar 2009, at 17:52, Paul Ishenin wrote:
Paul Ishenin wrote:
Thanks to Jonas. We don't need to write so big debug paths anymore.
He successfully fixed an issue with path in the stabs in r12812.
Jonas, can you look futher. I pasted one example here (executed -
On 21 Mar 2009, at 10:38, dmitry boyarintsev wrote:
hat do you think about using another fpc.cfg file (i.e. fpcxcode.cfg)
for iPhone compilation, rather than passing compiler configuration
through the command line?
i guess that the ideally, there would be no additional .cfg files, and
compiler
On 21 Mar 2009, at 13:58, Jonas Maebe wrote:
On 21 Mar 2009, at 10:38, dmitry boyarintsev wrote:
Also, i'm not experienced in compiling fp-cross-compilers, but is it
possile to build ppcarm (for darwin) from svn trunk?
1) copy /Developer/FreePascalCompiler/iPhoneSnapshot-2.3.1-r12531
On 20 Mar 2009, at 19:54, Paul Ishenin wrote:
Jonas Maebe wrote:
In trunk/r12933 you can now force the compiler to always store
absolute path for include files using -gostabsabsincludes. See the
svn comment for why it's not the default (gcc also never does this,
you can't even force
On 21 Mar 2009, at 15:07, Paul Ishenin wrote:
Jonas Maebe wrote:
Sorry, for me it is somehow strange that this works different:
{file=C:/programming/fpc/rtl/i386/i386.inc,fullname=C:/
programming/fpc/rtl/i386/i386.inc} and
{file=./include/messagedialogs.inc}
main unit file is located in
C
On 25 Mar 2009, at 14:01, Paul Ishenin wrote:
Ok, tried info signals and found that gdb handles SIGFPE. I
changed behavior:
(gdb) handle SIGFPE noprint
SignalStop Print Pass to program Description
SIGFPENoNo Yes Arithmetic exception
(gdb)
On 25 Mar 2009, at 14:14, Paul Ishenin wrote:
Jonas Maebe wrote:
File a bug against gdb, it should work (it works under Mac OS X and
Linux). The gdb bug repository is at http://sourceware.org/gdb/bugs/
First I need to be sure that this is a gdb bug. Maybe fpc doing a
bit different
On 25 Mar 2009, at 15:25, Paul Ishenin wrote:
Jonas Maebe wrote:
Just make sure you include a compiled program so that the gdb
maintainers don't have to install FPC to test.
Sorry for annoyance.
There was no annoyance from you, just from some things I have to do at
work currently
On 27 Mar 2009, at 19:44, Paul Ishenin wrote:
and evaluate Ord('a'):
[gdb log]
-data-evaluate-expression Ord('a')
No symbol \Ord\ in current context.\n
^error,msg=No symbol \Ord\ in current context.
[/gdb log]
Ord() is not a regular function, it's implemented using compiler magic
(just
On 01 Apr 2009, at 04:39, Chas. Owens wrote:
Is it possible to cross compile a Pascal program from Intel OS X to
Intel Linux using fpc?
Yes, but you first need
a) cross-compiled GNU binutils for targeting Linux
b) compile the FPC units for the Linux target
From a previous mail (to
On 09 Apr 2009, at 14:35, Martin Friebe wrote:
Just a question. Can smart linking detect and remove unused virtual
methods?
http://lists.freepascal.org/lists/fpc-pascal/2009-April/020638.html
Jonas
___
fpc-devel maillist -
On 09 Apr 2009, at 15:46, martin wrote:
Jonas Maebe wrote:
On 09 Apr 2009, at 14:35, Martin Friebe wrote:
Just a question. Can smart linking detect and remove unused
virtual methods?
http://lists.freepascal.org/lists/fpc-pascal/2009-April/020638.html
Thanks for the quick reply. I am
On 13 Apr 2009, at 20:36, domini...@savagesoftware.com.au domini...@savagesoftware.com.au
wrote:
I'm using FreePascal 2.2.2, from 12th April 2009
snapshot to compile my app on a PowerPC iMac running Mac OS X 10.3.9.
All my units compile fine, but it fails during the linking phase
with
On 29 Apr 2009, at 14:38, Bogusław Brandys wrote:
Can someone assign those bugreports :
http://bugs.freepascal.org/view.php?id=13499
and http://bugs.freepascal.org/view.php?id=13518
to proper person ?
In general, in FPC bug reports are not assigned to someone, but every
developer for
On 29 Apr 2009, at 14:46, Jonas Maebe wrote:
On 29 Apr 2009, at 14:38, Bogusław Brandys wrote:
Can someone assign those bugreports :
http://bugs.freepascal.org/view.php?id=13499
and http://bugs.freepascal.org/view.php?id=13518
to proper person ?
In general, in FPC bug reports
On 02 May 2009, at 14:32, Michael V. Denisenko wrote:
Здравствуйте, Jonas.
I've got a problem trying to move fpc_shortstr_compare parameters to
the registers EAX and EDX.
The command 'getintregister', as I understood, returns some register
which just satisfies a size-condition.
How to get a
On 03 May 2009, at 04:28, Alexander Klenin wrote:
While fixing http://bugs.freepascal.org/view.php?id=13619,
Jonas did not apply neither code cleanup not comment fix parts of it.
It's mainly because I saw the patch only after I already looked up the
Delphi declaration and fixed the code
On 03 May 2009, at 13:08, Michael Van Canneyt wrote:
On Sun, 3 May 2009, Jonas Maebe wrote:
I don't see what the problem is with stabilising/releasing 2.4 as
it is. If
generics and Delphi 2009-style ansistrings are not going to get
finished any
time soon, why not release 2.4 without them
On 03 May 2009, at 12:44, Marco van de Voort wrote:
Well, Lazarus is currently amassing large handcoded UTF8 ansistring
codebases, something I don't think that is healthy. If unicode is
postponed
to the next major release, it will be long, very long before this is
cleaned
up.
Waiting
On 03 May 2009, at 13:54, Marco van de Voort wrote:
(I thought btw, generics in 2.2.4 had improved to being more or less
usable?)
A number of important bugs were indeed fixed. But as far as I know,
several more are left.
Jonas
___
fpc-devel
On 03 May 2009, at 14:58, Alexander Klenin wrote:
BTW, is generics good enough to be used in e.g. math.pp?
Afaik, generics have only been implemented for classes until now.
Plain generic functions are not (yet) supported.
Jonas
___
fpc-devel
On 04 May 2009, at 20:48, Dariusz Mazur wrote:
I have problem with this small program below. I've compiled if on
Linux/i386 FPC 2.2.2
Every time of run program halt with runtime. I've test it with short
and ansistring. Result the same.
But when I uncomment line with test2 everything goes
On 08 May 2009, at 01:56, Sooky Boo wrote:
Is it possible to generate a symbol file for WinDbg?
According to http://en.wikipedia.org/wiki/WinDbg it requires debug
information in the PDB format, and according to http://en.wikipedia.org/wiki/Program_database
this format is undocumented and
On 08 May 2009, at 14:33, Sooky Boo wrote:
Does FPC currently generate any alternative symbol file format(s)?
FPC can generate Stabs and DWARF debug information,
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 09 May 2009, at 04:57, Mehmet Erol Sanliturk wrote:
[make, ld]
(1)
Supply these programs as recompiled to display information about
themselves .
These programs are GNU make, GNU ld, etc (i.e., we don't write these
tools nor define how they behave). These behave according to their own
On 21 Apr 2009, at 16:47, Stefan Kisdaroczi wrote:
FindFirst from fpc 2.2.4 returns zero (file found) and an empty Name
if I search for files in a empty directory.
With fpc 2.2.2 FindFirst returns -1 as expected.
Im using Debian Lenny (i386) and installed the 2.2.4 *.deb's from
the
On 16 May 2009, at 22:22, Joost van der Sluis wrote:
I've finally succeeded in buildin gdb-archer on windows using mingw.
Which branch did you build? archer? If you built master instead:
that's just regular gdb cvs imported in git (used for keeping all the
different branches in sync with
On 16 May 2009, at 23:35, Joost van der Sluis wrote:
It could indeed be the case that the actual dwarf-3 tests were with
master. I'll re-try tomorrow using the fedora-branch. (Or could you
suggest another one? I though this branche would be somewhat stable
and
include most things from other
On 19 May 2009, at 14:04, Joost van der Sluis wrote:
But another issue is that it always complains while compiling:
/usr/bin/ld: warning: link.res contains output sections; did you
forget -T?
This is a new warning that was added to ld.
What does it mean? Does fpc something special with
On 19 May 2009, at 14:06, Michael Van Canneyt wrote:
I'm afraid I have seriously bad experiences with interfaces in FPC
How so? I'm not aware of any outstanding bugs with interfaces in FPC.
Even the compiler uses them now (only for whole-program optimization
though, so usually you won't
On 19 May 2009, at 14:53, Michael Van Canneyt wrote:
On Tue, 19 May 2009, Jonas Maebe wrote:
On 19 May 2009, at 14:06, Michael Van Canneyt wrote:
I'm afraid I have seriously bad experiences with interfaces in FPC
How so? I'm not aware of any outstanding bugs with interfaces in
FPC
On 19 May 2009, at 15:45, Peter Vreman wrote:
The linker scripts without the full SECTIONS details are only used
to reduce the length and
complexity of the commandline.
This is about the linker scripts /with/ SECTIONS details. That's what
the warning is about: there are SECTIONS details
On 22 May 2009, at 23:00, Dariusz Mazur wrote:
How to tell compiler where are *.res files.
You can't. As you noticed, they are always searched relative to the
directory of the main source file (unless the resource file is
specified using an absolute path)
Jonas
On 23 May 2009, at 11:05, Vincent Snijders wrote:
Can't the searching be extended to the unit directory. It would make
the file C:\fpc\2.2.4\units\i386-win32\fcl-base\fclel.res really
useful, now have to copy it to my program dir to be able to use
deamonapp unit.
WDDD? (What Does
On 24 May 2009, at 04:32, ABorka wrote:
In FPC/Lazarus:
procedure TForm1.IdHTTP1Redirect(Sender: TObject; var dest: String;
var NumRedirect: Integer; var Handled: Boolean; var VMethod:
IdHTTPMethod);
begin
ShowMessage('Redirected to:' + dest);
end;
However, it seems that the parameter
On 24 May 2009, at 23:22, ABorka wrote:
If you are only using Pascal code in the real program, this should
all be handled transparently for you.
I agree, so why it doesn't?
I don't know. The problem is not that ansistring var parameters are
completely broken, since there is a lot of
On 29 May 2009, at 01:44, ABorka wrote:
fillchar(tmp, sizeof(tmp), #0);
gives the Hint: Local variable tmp does not seem to be initialized
message upon compilation, which should not happen because it is
actually the initialization.
It is not possible to change this in the compiler. The
On 29 May 2009, at 09:44, Flávio Etrusco wrote:
(...)
This is due to the fact that if you pass a variable to an out
parameter and
this variable is reference counted or contains reference counted
elements
(in case of an array/record/object), then the compiler has to insert
finalization
On 29 May 2009, at 09:04, Micha Nelissen wrote:
Jonas Maebe wrote:
It is not possible to change this in the compiler. The reason is
that if we change the first parameter of fillchar from a var
parameter (as it is now) into an out parameter (so the hint would
not be shown
On 31 May 2009, at 09:29, Sergei Gorelkin wrote:
Inoussa OUEDRAOGO wrote:
Hi
At http://blogs.embarcadero.com/abauer/2009/05/29/3
This could drastically reduce Lazarus executable size.
Doubt that. Just another feature ported from .NET,
I don't think it is very specific to .NET. We use
On 31 May 2009, at 10:38, Paul Ishenin wrote:
Jonas Maebe wrote:
Yes, we made a refactoring and as result empty form + button
application weights 200Kb less now. Can you check, maybe now WPO
results can be more impressive?
Still quite minimal results. But unless I'm misremembering
On 31 May 2009, at 11:42, Paul Ishenin wrote:
Jonas Maebe wrote:
Still quite minimal results. But unless I'm misremembering, it
seems that the size of the application itself has grown a lot. An
empty form with a button now results in an application of 1.8MB
(Carbon/i386). I thought
On 31 May 2009, at 19:34, Florian Klaempfl wrote:
Jonas Maebe schrieb:
situations, but not very much.
Has anyone tried it on Lazarus?
Yes, the but the results are not very impressive. The reason is due
to the way the LCL is constructed, almost every declared class can
theoretically
On 31 May 2009, at 21:27, Marco van de Voort wrote:
Yeah, I got it when I saw Jonas' reply. The IDE could list all visual
components in forms in a file and hand it to the compiler. And a
custom
list could allow additional streaming types (for users code)
Either the IDE has to be able to
On 31 May 2009, at 11:35, Jonas Maebe wrote:
On 31 May 2009, at 10:38, Paul Ishenin wrote:
Jonas Maebe wrote:
Yes, we made a refactoring and as result empty form + button
application weights 200Kb less now. Can you check, maybe now WPO
results can be more impressive?
Still quite
On 05 Jun 2009, at 17:47, Paul Ishenin wrote:
Jonas Maebe wrote:
All programs are stripped. As you can see, wpo can now remove about
61kb (before, wpo gained 8kb). Still not very much. The reason that
you need several iterations to get all possible savings, is that
the compiler only
On 05 Jun 2009, at 18:58, Mattias Gaertner wrote:
I think you guys are doing a great job. From 93MB with debugging
info down to 9mb is quite a big step. Especially since 2mb are icons
and images.
I don't think that it's useful to include debugging information in any
comparisons. Especially
On 05 Jun 2009, at 18:44, Daniël Mantione wrote:
The WPO features Jonas is working on are very promising, and I think
he is doing something unique, I know no competing compiler that does
it.
I know that method devirtualisation is done at least in JVMs from IBM
(and probably also in
On 19 May 2009, at 16:50, Peter Vreman wrote:
The linker scripts without the full SECTIONS details are only used
to reduce the length and
complexity of the commandline.
This is about the linker scripts /with/ SECTIONS details. That's what
the warning is about: there are SECTIONS details in a
On 11 Jun 2009, at 14:14, Martin Friebe wrote:
However it would be nice to have a feature like
property Foo[Index: Integer]: Integer write SetFoo read GetFoo;
property Foo[Index: Integer; Ask: Boolean]: Integer write
SetFooAsk read GetFooAsk;
The must have different Method Names,
On 11 Jun 2009, at 14:44, Michael Van Canneyt wrote:
On Thu, 11 Jun 2009, Jonas Maebe wrote:
On 11 Jun 2009, at 14:14, Martin Friebe wrote:
However it would be nice to have a feature like
property Foo[Index: Integer]: Integer write SetFoo read GetFoo;
property Foo[Index: Integer; Ask
On 13 Jun 2009, at 13:31, Alexander Klenin wrote:
Currently, Round and Trunc functions ignore the state of
$OVERFLOWCHECKS
compiler directive. The following code prints -2 -2:
{$MODE OBJFPC}{$OVERFLOWCHECKS ON}
var
a: Integer;
b: Double;
begin
b := MaxInt;
a := Round(2.0 * b);
On 13 Jun 2009, at 14:27, Alexander Klenin wrote:
On Sat, Jun 13, 2009 at 22:47, Jonas
Maebejonas.ma...@elis.ugent.be wrote:
The difference between range and overflow errors is as follows:
* range errors occur when an implicit type conversion occurs from
one type
to another (e.g., when
On 19 Jun 2009, at 06:45, Bruce Tulloch wrote:
type
function F ( C : TArray ) : TArray;
begin
{ does nothing }
end
begin
SetLength(B,4);
for I := 0 to 3 do
B[I] := I;
A := Copy(B);
A := F(B); { what is the correct answer here? }
end;
a question arises as to
On 19 Jun 2009, at 04:23, Paul Ishenin wrote:
I think that ChangeName should stay in the TComponent class. It is
the only way to change a component name without validation. Even if
it is not used by Lazarus it is probably used by some third-party
components. For example report generators
On 19 Jun 2009, at 12:01, Maxim Egorov wrote:
Micha Nelissen пишет:
Since the return value is undefined, anything is possible:
* calculate crc32 over executable
* random value from stack
* do nothing at all
It's not true in the case of functions that return dynamic arrays,
strings or
On 19 Jun 2009, at 13:21, Florian Klaempfl wrote:
Jonas Maebe schrieb:
On 19 Jun 2009, at 12:01, Maxim Egorov wrote:
It's not true in the case of functions that return dynamic arrays,
strings or interfaces. Because of these types require special
finalization and they must be initialized
Hello,
The order in which method/property and field declarations can appear
in class/object definitions has been changed in fpc trunk. This may
break existing code, but it's trivial to fix. See http://wiki.freepascal.org/User_Changes_Trunk#Order_of_field_and_method.2Fproperty_declarations
On 11 Jul 2009, at 12:53, Micha Nelissen wrote:
Are we supposed to be able to assign to Self?
Yes.
FPC accepts the attached unit
Kylix also.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 11 Jul 2009, at 13:11, Micha Nelissen wrote:
Jonas Maebe wrote:
On 11 Jul 2009, at 12:53, Micha Nelissen wrote:
Are we supposed to be able to assign to Self?
Yes.
When would it be used?
You can find some examples here:
* http://www.google.com/codesearch?hl=enq=%22self%3A%3D%22+lang
On 11 Jul 2009, at 14:19, Zaher Dirkey wrote:
When i update FPC from SVN repo
it updated for 10 mbytes then i had this error
Error: REPORT of '/svn/fpc/!svn/vcc/default': 200 OK
(http://svn2.freepascal.org:8080)
I guess there's a limit somewhere in the apache config that limits
certain
On 19 Jul 2009, at 20:57, Joost van der Sluis wrote:
The attached patch solves the problem, but I doubt this is the right
place to do this, since this way the 'DW_TAG_typedef' entry is always
added, and in some cases double.
How (and where) to fix this properly?
I guess by removing the
On 20 Jul 2009, at 17:12, Paul Ishenin wrote:
I have found that next functions are not described here:
http://freepascal.org/docs-html/rtl/system/index.html
Several of them are 2.3.1, so it's normal that they are not yet in the
documentation.
The functions are:
- BitSizeOf
It's
On 24 Jul 2009, at 02:59, Leonardo M. Ramé wrote:
Hi, I'm trying to run the examples of http22 units in a FreeBSD 7.2
for i386, with Apache 2.2.11.
The examples compiles with FPC 2.2.4, but when I try to run
apachectl start, it crashes with this message:
httpd: Syntax error on line 104
On 27 Jul 2009, at 22:11, Leonardo M. Ramé wrote:
I found a bug opened in 2006 about this issue, its number is 0007833.
For the initialization/finalization stuff, you may want to look at the
changes I did for Linux in r10551
Jonas___
fpc-devel
On 29 Jul 2009, at 18:47, Daniël Mantione wrote:
Op Wed, 29 Jul 2009, schreef Desmond Coertzen:
This is my first question / suggestion: With byte sized variables
being the
smallest accessible variable in the PC architecture, will we see a
language
extension to provide bit accessible
On 29 Jul 2009, at 19:46, Florian Klaempfl wrote:
Jonas Maebe schrieb:
This is not usable for accessing particular bits of microcontroller
registers, because the internal format of a bitpacked record is
undefined and can change at any time for any reason.
Indeed, but do you think we should
On 29 Jul 2009, at 20:28, Desmond Coertzen wrote:
But if I define the 'nibble' data types myself (or use the bit
packed data
types provided by a 'system' unit for the particular chip), they
would stay
that way?
The problem is that you have no guarantee how the compiler packs the
bits
On 29 Jul 2009, at 15:50, Peter Popov wrote:
I was able to trace it to the unwinding of the gcc exception handler
for the terminating thread. An obvious assertation fails (in unwind-
dw2.c), which means that some basic startup data of gcc is either 1)
messed up 2) not initialized.
The
On 29 Jul 2009, at 22:28, Peter Popov wrote:
I was able to trace it to the unwinding of the gcc exception
handler for the terminating thread. An obvious assertation fails
(in unwind-dw2.c), which means that some basic startup data of gcc
is either 1) messed up 2) not initialized.
The
On 30 Jul 2009, at 10:09, Michael Schnell wrote:
This is not usable for accessing particular bits of microcontroller
registers, because the internal format of a bitpacked record is
undefined and can change at any time for any reason.
Is this likely to happen ?
That's irrelevant, unless you
On 30 Jul 2009, at 10:04, Michael Schnell wrote:
Desmond Coertzen wrote:
Is this correct for application?
While I know that you in fact can use bitpacked records to access
singe
bits in the memory, I wonder what kind of OS you want to use in this
application.
Microcontrollers most of the
On 30 Jul 2009, at 10:58, Michael Schnell wrote:
What I meant was: I suppose FP applications mostly is used on some
kind
of OS.
Not when targeting microcontrollers.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 30 Jul 2009, at 11:04, Michael Schnell wrote:
Jonas Maebe wrote:
Not when targeting microcontrollers.
What kind of Microcontrollers do you know that are used with FP
programs ?
http://wiki.freepascal.org/Embedded
Jonas
___
fpc-devel
On 31 Jul 2009, at 13:21, Desmond Coertzen wrote:
As far as endian is concerned: Integer types i found always to be
little
endian in most pascal compilers by default.
It's big endian on big endian architectures.
As far as the FPC compiler is concerned, this should not be a
concern as it
On 31 Jul 2009, at 13:49, Desmond Coertzen wrote:
It's big endian on big endian architectures.
Which arhictecture(s) does big endian?
Of the ones that FPC currently supports: SPARC, PowerPC/PowerPC64
(some implementations can also be used in little endian mode, but
that's not often
On 02 Aug 2009, at 04:17, Martin wrote:
I am wondering if the code below is valid or not.
It is not.
It executes, but compiled with -CR gives a runtime error in
fpc_check_object
xfoo is a variable to store a class of TFooClass, or any inherited
class. It is initialized with the
On 05 Aug 2009, at 22:28, Peter Popov wrote:
Since you mentioned cprt0, you could try checking the order of
initialization of libc and libgcc. This may have something to do
with it, see alsohttp://bugs.freepascal.org/view.php?id=14265
Indeed, that may very well be the reason.
Jonas
On 14 Aug 2009, at 08:43, Graeme Geldenhuys wrote:
I can't agree more. Sometimes there is a valid design for something
like that. The compilers already handle forward declarations in the
same unit,
Actually, only in the same type block.
so why can that not be applied for multiple units
On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote:
Does anyone have an idea why the call to DoneKeyboard was previously
commented? It leaves the keyboard in a bad state if the IDE crashes.
It was changed in revision 3443, whose log message says:
r3443 | daniel | 2006-05-07 00:57:20 +0200
On 17 Aug 2009, at 17:43, Michael Van Canneyt wrote:
The reason for this - which has been given often - was the atypical
window size of the router in front of the server: Some ISP's routers
or network configuration could not cope with this atypical window
size.
To nitpick: it's not the
701 - 800 of 2636 matches
Mail list logo
