On 16 Oct 2009, at 14:16, Paul Davidson wrote:
dsl-corax:~ pauldavidson$ lipo -info /Users/pauldavidson/dev/cape96/
libmysqlclient.a
input file /Users/pauldavidson/dev/cape96/libmysqlclient.a is not a
fat file
Non-fat file: /Users/pauldavidson/dev/cape96/libmysqlclient.a is
architecture: x8
On 16 Oct 2009, at 14:51, Vincent Snijders wrote:
Jonas Maebe schreef:
That's correct, FPC 2.2.4 only support i386 and PowerPC for Mac OS
X. The upcoming 2.4.0 release will also support x86_64, PowerPC/64
and ARM.
As far as I could see, there are no x86_64 Mac OS X snapshots. Is
On 16 Oct 2009, at 15:12, Paul Davidson wrote:
Ok, 32 bit universal it is!
Is there any database access method that works with this mode for
10.6.1? And how?
Since MySQL is not shipped with Mac OS X, you somehow installed/
obtained an x86_64 version of its client library. Install/obtain
Hello,
Please continue this thread to the fpc-other mailing list. This list
is for discussions about *programming* in Pascal and FPC, and moreover
language advocacy threads have a tendency to drown everything else by
the sheer volume of posts they elicit.
Thanks,
Jonas
FPC mailing lists
On 18 Oct 2009, at 17:52, Tom Verhoeff wrote:
It would be nicer if one had the ability to make floating-point
division
by zero return an IEEE 754 plus/minus infinity, without raising an
exception.
http://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
Fully cross-platform, even
On 19 Oct 2009, at 14:14, Tom Verhoeff wrote:
On Mon, Oct 19, 2009 at 10:21:01AM +0200, Jonas Maebe wrote:
http://www.freepascal.org/docs-html/rtl/math/setexceptionmask.html
Fully cross-platform, even.
How new is that?
Not very. I think it exists at least since 2.0.0.
It works
On 19 Oct 2009, at 14:36, Jonas Maebe wrote:
In case it's Mac OS X on x86: floating point exception reporting via
Unix signals isn't exactly its forte.
And in case Mac OS X on ppc: the same caveats apply as for x86, except
that we don't have to any opcode decoding since
On 19 Oct 2009, at 17:04, Bart wrote:
Could you comment on my opinion that in case of a floating point
divide by zero error an EZeroDivide should be raised (or no exception
at all depending on the FPU exception mask) and only in case of
integer divide by zero (div operation) an EDivByZero shoul
On 19 Oct 2009, at 19:08, Bart wrote:
In the code that "translates" the "you did something nasty" to
runerror(some_exit_code) it may be possible to differentiate between
float and integer fault?
It is (on some platforms with some hacking).
This info could then be stored in some variable/obj
On 20 Oct 2009, at 10:45, fpcl...@silvermono.co.za wrote:
Have you considered implementing the foreach construct similar to
that found
in many modern languages?
You may want to subscribe to the fpc-devel list, as a discussion on
this topic was just started there.
To everyone: please kee
On 20 Oct 2009, at 16:43, Matthias Klumpp wrote:
Linking build/project1
/usr/bin/ld: warning: bin/link.res contains output sections; did you
forget
-T?
./libipkinject.so: undefined reference to `fpc_geteipasebx'
project1.lpr(42,1) Error: Error while linking
Do you have any idea why this hap
ik wrote on Fri, 23 Oct 2009:
You can use bitpacked records:
http://www.google.com/codesearch?hl=en&lr=&q=bitpacked+record+package%3Ahttp%3A%2F%2Fpasxlibbind
\.googlecode\.com&sbtn=Search
Here is an example on how I use it :)
No, you cannot use bitpacked records for C header translations.
Graeme Geldenhuys wrote on Fri, 23 Oct 2009:
uint32_tSearchStart:31;// file offset to full text search table
uint32_tsearchlen:1; // if high bit set, size of
search record size is 16-bit
If not, I guess I can continue with what I already do - read this as
a 32bit u
ik wrote on Sat, 24 Oct 2009:
[bitpacked records cannot be used for interfacing with C]
That's make this feature very not useful and unneeded.
It was primarily added for compatibility with Mac Pascal compiler, and
it's also compatible with GPC's bitpacked records. It's as useless as
"set"
On 25 Oct 2009, at 13:17, "Henrik Genssen" > wrote:
Hi JoshyFun,
yes, I am writeing debug information. I tried:
-g
-Xg
and both with no success
the output send earlier was made using both options.
-Xg can only work with DWARF on Mac OS X. Either use -gw -Xg or plain -
g without -Xg.
On 25 Oct 2009, at 19:45, Henrik Genssen wrote:
if I use plain -g I get:
[TCmdLineDebugger] Debug PID: 15860
TGDBMIDebugger.ProcessResult Error: ,msg="No symbol table is
loaded. Use the \"file\" command."
Does the directory yourapp.dSYM still exist? (this is what gets
generated when you
On 30 Oct 2009, at 15:38, Vincent Snijders wrote:
Also attached sample program compiles without error. Why is there no
error on the line:
@C.Test;
Looks like a compiler bug to me.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.or
On 01 Nov 2009, at 17:29, Martin wrote:
If I compile a package, the lcl, the rtl, whatever, I can do so with
-g getting stabs, then any app I compile with -gw will not see the
debug info for those package
-gw geting dwarf, and any app compiled with -g will not see it
That is normal.
So I
Holger Bruns wrote on Mon, 02 Nov 2009:
Martin schrieb:
you can do:
var buffer: Array of byte;
SetLength(Buffer, 1000);
SerRead(Handle, Buffer[0], 1000);
I checked this out. It works not reliable. Sometimes I get real
data, sometimes the data are corrupted. I have no idea to rule out
cor
Holger Bruns wrote on Mon, 02 Nov 2009:
Felipe Monteiro de Carvalho schrieb:
It may be useful to know that there is a serial communication example
using Synaser here:
http://wiki.lazarus.freepascal.org/Hardware_Access#Serial_Communication
Yes, thank you. I checked this out. The procedure recc
Holger Bruns wrote on Mon, 02 Nov 2009:
Accessing ports is limited to ports < 03ffh, more ports cannot be
released with fpioperm. This means to me, successful serial port
access on higher addresses cannot yet be implemented with fpc. If
this policy can be ruled out, let me know.
fpioperm
Holger Bruns wrote on Tue, 03 Nov 2009:
I decided to copy all the necessary files for x86.pp and oldlinux.pp
into one directory for compiling these two units. This compilation
failed due to syntax errors. A bunch of warnings also appeared. I
post only the syntax error messages:
You appear
Holger Bruns wrote on Tue, 03 Nov 2009:
Jonas Maebe schrieb:
The next release of FPC will include a version of the x86 unit for
Linux/x86_64. In general, if a unit is not available in a
precompiled version for your platform, the reason is that it does
not work. Unless you intend to fix
On 06 Nov 2009, at 09:03, Michael Van Canneyt wrote:
Can you give us some more info on conformant arrays ? It's the first
time I heard of such a construct.
http://docs.hp.com/cgi-bin/doc3k/B3150290023.10194/53
Jonas
___
fpc-pascal maillist - fp
Andrew Brunner wrote on Sat, 07 Nov 2009:
Yes. From any folder in command prompt I get fpc access. I just
don't know the make commands and parameters.
make all
make install INSTALL_PREFIX=c:\path\without\spaces
(and make sure the sources are also installed in a hierarchy without
spaces in
Andrew Brunner wrote on Sat, 07 Nov 2009:
C:/FPC/bin/i386-Win32/cp.exe -Rfp examples/* C:\FPC/examples/hash
cp.exe: cannot remove old link to
`C:/FPC/examples/hash/.svn/all-wcprops': Permi
ssion denied
You have to build/install an exported copy under Windows due to a bug
in cp.exe there.
ik wrote on Sun, 08 Nov 2009:
Hello all,
I'm trying to figure out valgrind's log about a program I wrote in Pascal
using FPC.
I have a lot of the following messages:\
==30348== Mismatched free() / delete / delete []
==30348==at 0x4C21A18: free (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-
cobines wrote on Sun, 08 Nov 2009:
I have to conclude that the values in rtl/inc/systemh.inc: StackTop,
StackBottom, StackLength are not behaving as thread-specific variables
in the library, even though they are declared using ThreadVar.
Your problem is that every FPC-compiled library contains
On 09 Nov 2009, at 09:07, Michael Van Canneyt wrote:
It should stop the daemons properly. This is the code that gets
executed:
Procedure DoShutDown(Sig : Longint; Info : PSigInfo; Context :
PSigContext);
cdecl;
begin
Application.StopDaemons(True);
Application.Terminate;
end;
If it doe
On 09 Nov 2009, at 13:49, Graeme Geldenhuys wrote:
See the output below. The 32bit Linux FPC can target 32bit & 64bit
platforms. But 64bit Linux FPC cannot target 32bit platforms. The
later
can only cross-compile to other 64bit platforms.
I guess you mean this:
--
./p
On 09 Nov 2009, at 14:27, Graeme Geldenhuys wrote:
Jonas Maebe wrote:
library search paths or so. The i386 compiler cannot generate x86_64
binaries. The appropriate code generator is simply not available.
Ummm... I'll go read the wiki and buildfaq again. I'm a bit confused
thou
On 09 Nov 2009, at 15:01, Graeme Geldenhuys wrote:
Rainer Stratmann wrote:
Is it possible to create an .exe file at linux os when choosing
target 'windows'?
Yes - when you compile your applications using the cross compiler. The
crosscompiler wiki page explains it all. I have successfully cre
On 09 Nov 2009, at 21:03, Michael Van Canneyt wrote:
On Mon, 9 Nov 2009, "Vinzent Höfler" wrote:
As wrong as in "Don't call most system functions from within a
signal handler.", maybe?
Hmm... In that case, many exceptions would not work either ?
The sigaction handlers for catching except
On 09 Nov 2009, at 21:51, Michael Van Canneyt wrote:
Hm. Quite complex code, and not processor independent.
It never was processor-independent, because the siginfo codes already
varied between architectures.
Is there not a more generic way of handling this ?
I doubt it.
Jonas
___
On 10 Nov 2009, at 14:35, Anthony Walter wrote:
In my opinion the warning should be removed, or at least able to be
suppress through a switch.
FPC 2.4.0 will include the ability to suppress individual messages.
Use -vq to show the messages numbers, and -vm to suppress a
particular message
On 11 Nov 2009, at 00:55, epergola wrote:
Is there a way (or a 3rd party component or a library) to catch an
endless
loop after x seconds
in applications running on arm Wince?
It is not possible to know whether a loop is endless or not (at least
not in the general case, see the "halting p
On 13 Nov 2009, at 10:26, Lidia Stanganelli wrote:
> I have a program in Pascal that compiles correctly on windows 32-bit but
I anyone answers, please CC the original poster, because she's not subscribed
to the list (at least not with the address she posted from).
Jonas___
On 15 Nov 2009, at 16:09, Rainer Stratmann wrote:
> At some reason it is not possible to unsubscribe me from the bugs-mailinglist.
It's not a mailing list, but the bug tracker itself. I thought this problem has
been solved by now. Do you still get mails if you log in to the bug tracker, go
to
On 16 Nov 2009, at 14:50, Anthony Walter wrote:
There is a problem with the above code on FPC when you change calling
conventions of A.
Const indeed behaves differently depending on the calling convention.
With register and stdcall, we emulate Delphi. With mwpascal, we
emulate MetroWerks
On 16 Nov 2009, at 15:01, Anthony Walter wrote:
Jonas, why is FPC emulating C when it could simply follow the Delphi
way and prevent these incompatibilities?
I think that FPC's behaviour predates the existence of Delphi.
Jonas
___
fpc-pascal maill
On 16 Nov 2009, at 15:29, Anthony Walter wrote:
"FreePascal did this before something else so we shouldn't change"
Forgetting the whole argument about who was actually first, I have to
ask what difference does it make?
I was merely answering your question why we do it differently than
Delp
On 16 Nov 2009, at 16:19, Marco van de Voort wrote:
The fpc-devel group and/or irc.
The fpc-devel mailing list is best, I think, if only because the
answers will be indexed by Google.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepasca
On 16 Nov 2009, at 15:51, Jonas Maebe wrote:
The main problem with changing it now would obviously be that it
would break backwards compatibility with existing code. It could
still be done in Delphi mode onlu, of course, but changing the
behaviour of a calling convention (which is
Anthony Walter wrote on Mon, 16 Nov 2009:
Jonas:
I noticed the bit you posted which looked like this:
{$define cdecl:=delphicdecl}
Does this mean I can redefine patterns as seen by FPC?
Yes. They are basically equivalent to C macro's, except that they do
not support parameters. See
htt
On 16 Nov 2009, at 18:55, Anthony Walter wrote:
I think Delphi should be using actual operators like + * and / instead
of Add, Multiply, Divide, but then again I think the named results of
FPC are stranger. What's wrong with using the type in the declaration
and Result in the implementation?
On 16 Nov 2009, at 19:56, Anthony Walter wrote:
On Mon, Nov 16, 2009 at 1:39 PM, Jonas Maebe > wrote:
For this reason, I think the Delphi operator naming decision is
actually
better than FPC's. Limiting them to classes is another matter.
Jonas
Jonas,
Delphi doesn't l
On 17 Nov 2009, at 10:02, Graeme Geldenhuys wrote:
> How to I solve this compiler hint?
Don't cast ordinals to pointers.
> -
> procedure XorBlock(var InData1, InData2; Size: longword);
> var
> i: longword;
> begin
> for i:= 1 to Size do
>Pbyte(PtrUInt(@InDa
On 17 Nov 2009, at 10:17, Aleksa Todorovic wrote:
> On Tue, Nov 17, 2009 at 10:05, Jonas Maebe wrote:
>>
>> Replace the PtrUInt types casts with PByte (or Pointer) type casts.
>>
>
> Does that mean that (PByte(p) + N) = (Pointer(p) + N) for
> pointer-casta
On 17 Nov 2009, at 10:38, Graeme Geldenhuys wrote:
> So in that case because a untyped parameters are treated like generic
> Pointer types whereby arithmetic increments in byte size, I don't
> actually need any type casts the parameters at all?
Indeed. In general, I'd recommend to always add a p
On 17 Nov 2009, at 19:34, Bruce Bauman wrote:
> I am using the FpTimes function from the BaseUnix package. The
> documentation says it returns -1 on an error, otherwise the number of
> clock ticks since boot time. However, the return type of this function
> is TClock, which is unsigned.
From "ma
On 17 Nov 2009, at 20:47, cobines wrote:
> Can the Fill... functions be changed to have the first parameter "out"
> instead of "var"
No: http://lists.freepascal.org/lists/fpc-devel/2009-November/018532.html
Jonas
___
fpc-pascal maillist - fpc-pasc
On 18 Nov 2009, at 17:35, Jürgen Hestermann wrote:
> But isn't the warning raised when x is used as a parameter of a function? The
> problem is, that fillchar is not considered to be an initialization of x. So
> when using x it is still considered uninitialized.
a) a "var" parameter is conside
On 18 Nov 2009, at 17:53, Zaher Dirkey wrote:
> In Delphi there is ZeroMemory, i guess it is windows API, can we have
> one in FreePascal to use it instead of FillChar.
What is the problem with fillchar? (other than that it prints a wrong hint in
some cases.
Also note that the difference betwe
On 18 Nov 2009, at 17:58, Jonas Maebe wrote:
> Also note that the difference between hints and warnings is exactly that
> hints are not guaranteed to be 100% correct or relevant in all situations; if
> they were, then they would be warnings.
Or notes. In order of usefulness/accuracy
On 19 Nov 2009, at 07:35, Graeme Geldenhuys wrote:
Somebody did once attempt to correct the var parameter to out
parameter
in FillChar, but got to many errors. Probably not a high priority
issue,
so the problem was simply swept under the rug.
It's not about it not being a high priority pr
On 19 Nov 2009, at 08:18, Jonas Maebe wrote:
On 19 Nov 2009, at 07:35, Graeme Geldenhuys wrote:
Somebody did once attempt to correct the var parameter to out
parameter
in FillChar, but got to many errors. Probably not a high priority
issue,
so the problem was simply swept under the rug
On 19 Nov 2009, at 14:30, Holger Bruns wrote:
Since iopl is still not available to fpc in its 64-bit-version, I
should move to c for future port programming.
$ man iopl
...
This call is mostly for the i386 architecture. On many other
architec-
tures it does not exist or will
On 19 Nov 2009, at 20:44, cobines wrote:
> Is it wrong to use "out" for the sole purpose of informing the compiler that
> a function will set the initial value of a variable passed as the parameter?
No.
> Or is it just a side effect?
Yes.
> I use it all over the place in my programs. Is it s
On 19 Nov 2009, at 22:50, Rainer Stratmann wrote:
> Yes, but for that is the compiler-switch $PASS_VAR_NO_HINT ON.
> Then no hint is put out by the compiler.
When using FPC 2.4.0rc1 or later:
a) compile your code with -vq
b) note the message number for the warning/note/hint you want to suppress
On 20 Nov 2009, at 11:51, Michael Van Canneyt wrote:
No, because you don't know if a terminal is available or whether
standard
output is writable.
And I guess that if the crt unit is used, it would just put some
strange character on the screen.
Jonas
___
On 20 Nov 2009, at 23:49, Bruce Bauman wrote:
> I need to convert the st_time field of the record returned by BaseUnix.FpStat
> to the year, month, day, hour, minute and second and need to compensate for
> the local timezone.
The dateutils unit contains the following functions that you can use
On 21 Nov 2009, at 19:00, Pascal wrote:
> In example tgeneric16.pp (from FPC 2.2.4 sources) the generic type TStack is
> declared as:
tgeneric16.pp is not an example, it's a test. Moreover, it doesn't compile yet,
not even with FPC 2.5.1. So documenting that syntax is not really a good idea.
On 21 Nov 2009, at 20:16, Wimpie Nortje wrote:
> Is there any way to use a C library that use the __fastcall calling
> convention?
Not at this time. Also note that that the fastcall convention is not
standardised and varies between different C compilers.
Jonas
On 22 Nov 2009, at 02:56, Anthony Walter wrote:
> It would be a real shame to create more Delphi incompatibilities.
Generics were developed in parallel in FPC and in Delphi, and both came up with
a different syntax. The incompatibility was there from the start, it wasn't
created afterwards.
On 22 Nov 2009, at 10:10, Thierry Coq wrote:
> I'm trying to use inline to remove unnecessary debugging code, such as the
> following code, with FPC 2.3.1 on Windows, when compiling for production.
> However when I compile the code, at O1 optimisation level (my default), the
> call to DebugInfo
On 22 Nov 2009, at 16:10, Anthony Walter wrote:
> n Sun, Nov 22, 2009 at 6:15 AM, Jonas Maebe wrote:
>>
>> Generics were developed in parallel in FPC and in Delphi, and both came up
>> with a different syntax.
>> The incompatibility was there from the start, i
On 21 Nov 2009, at 14:20, Michael Van Canneyt wrote:
> I have been thinking along similar lines, and made an implementation for beep
> that works with a handler. It's not yet committed, as I was trying to make an
> LCL plugin which would work on Linux/X11.
Wouldn't it be better to do nothing by
On 22 Nov 2009, at 21:17, Pascal wrote:
> Have you some documentation available on Internet?
> The one I found is Delphi Object Pascal Language Guide, version 7, 2002.
> http://docs.codegear.com/products/rad_studio/delphi7/D7_DevelopersGuide.pdf
> Generic types are not described in it ;-(
http:/
On 23 Nov 2009, at 00:42, Bruce Bauman wrote:
If you look at the HTML documentation:
http://www.freepascal.org/docs-html/rtl/dateutils/datetimetounix.html
under Description it says:
Not yet implemented
under "Errors" it says:
Currently, trying to use this function will raise an exception
On 23 Nov 2009, at 13:40, Juha Manninen wrote:
I understand the compiler is a devel version but if you need a good
test case,
here you have one.
Unfortunately, not really. A good test case is a small self-contained
test program with no external dependencies that crashes or prints a
wro
On 23 Nov 2009, at 13:58, ik wrote:
I'm trying to cross compile FPC 2.5.1 in Linux 64 bit (in Arch
Linux) to arm
(eabi) cpu.
When I'm using
make CPUT_TARGET=arm OS=TARGET=linux all
That should be CPU_TARGET, not CPUT_TARGET, and OS_TARGET instead of
OS=TARGET
The make file build an x86
On 23 Nov 2009, at 15:37, ik wrote:
Is there a
way I can make a cross compiler zipinstall to install (at the end)
as a
package in my linux ?
Try this:
make OPT='dFPC_ARMEL -dFPC_ABI_EABI -Xd' OS=TARGET=linux
CPU_TARGET=arm FPC=`pwd`/compiler/ppcrossarm zipdistinstall
Jonas
__
On 22 Nov 2009, at 19:02, Jonas Maebe wrote:
On 21 Nov 2009, at 14:20, Michael Van Canneyt wrote:
I have been thinking along similar lines, and made an
implementation for beep
that works with a handler. It's not yet committed, as I was trying
to make an
LCL plugin which would wo
On 25 Nov 2009, at 11:46, Schatzl Thomas wrote:
Hi,
is there anyone who ported cpu.pp (from Thomas Schatzl) to fpc 2.2.4
(target go32v2)
it compiles out of the box with the 2.2.4 go32v2 compiler.
You will want to add a {$CALLING PASCAL} statement at the top of the
units - some assembly
On 26 Nov 2009, at 12:27, Wimpie Nortje wrote:
I have translated a C header file for interfacing with a National
Instruments data acquisition device. This is a standalone,
independant unit which will rarely if ever change. It also has no
dependancy on lazarus.
Where is the best place to
On 27 Nov 2009, at 15:49, Juha Manninen wrote:
If I define a private integer:
TDemo = class(TCustomApplication)
private
i: integer;
...
and in a protected method I use it:
for i := 0 to List.Count - 1 do
...
then I get an error:
Error: Illegal counter variable
Moving it to meth
On 27 Nov 2009, at 23:43, Juha Manninen wrote:
> I understand it is important to support also the old shortstring but it
> should
> be defined explicitly and "string" should always mean just one thing.
ansistring and shortstring always mean just one thing. "string" originally
meant shortstrin
On 28 Nov 2009, at 22:34, Michael Van Canneyt wrote:
> It was Jonas Maebe (Jonas, correct me if I'm wrong) who pointed
> out (already some time ago) that this behaviour is purely coincidental (but
> admittedly convenient), and should not be taken for granted.
That's correct
On 28 Nov 2009, at 23:31, Anthony Walter wrote:
> This second time regarding the current discussion you said: "This is
> not guaranteed in any way." and "nowhere it says in the Pascal
> language specification that this is guaranteed by the compiler"
>
> And I responded with the section, subsecti
On 29 Nov 2009, at 16:51, Anthony Walter wrote:
> Having said all that, Jonas, what is the actual implemented behaviour
> of FPC? Does it 0 initialize heap memory at startup or not?
I guess you mean global data rather than heap (heap is what is handled by
getmem/freemem/..., and there are no gu
On 29 Nov 2009, at 19:20, Mehmet Erol Sanliturk wrote:
> My experience with Windows XP Professional is that it is NOT zeroing the
> memory . I know this from actual Delphi ( and also Free Pascal ) compiled
> program executions . Due to this I am explicitly initializing all of the
> local simpl
On 29 Nov 2009, at 22:59, Anthony Walter wrote:
>> Do you mean this one?
>>
>> "Using const allows the compiler to optimize code for structured- and
>> string-type parameters."
>>
>> "Allows" is not the same as "forces". This line in the help file does not
>> say that const parameters are passe
On 30 Nov 2009, at 10:29, Marco van de Voort wrote:
> In our previous episode, Anthony Walter said:
>> Martin Schreiber also chimed in, pointing out:
>>
>> http://bit.ly/6uaAiB
>>
>> "Larger sets, records, and static arrays are passed as 32-bit pointers
>> to the value."
>>
>> The documentatio
On 01 Dec 2009, at 17:58, Bruce Bauman wrote:
> Is there a way I can tell if an arbitrary address is within the heap or
> stack?
>
> I want to do something like:
>
> Assert(ValidHeapAddress(a))
That is not possible without installing your own memory manager that tracks all
allocations. Also k
On 01 Dec 2009, at 18:03, Luca Olivetti wrote:
> I always protect multithreaded sting access with a critical section.
> Do you mean it is not needed?
The reference counting of ansistrings/... is thread safe. Accessing the
characters etc still requires explicit synchronisation if at least one wr
On 02 Dec 2009, at 00:56, Seth Grover wrote:
Using the examples from the test suite for an .so and a host program
(http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw12704a.pp?view=markup
and http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/tests/webtbs/tw12704b.pp?view=markup)
On 02 Dec 2009, at 10:26, Holger Bruns wrote:
I checked this out. Both Turbo Pascal and fpc reported the same
error massage: Variable identifier expected. You simply cannot pass
constant values by reference.
Passing a parameter by reference and "var" parameters are not the same
thing. Co
On 03 Dec 2009, at 14:45, Roland Turcan wrote:
I am not able to build SVN 14295.
/Users/test/lazarus/fpcsrc/compiler/ppc386 -XX -CX -Ur -Xs -O2 -n -
Fu/Users/test/lazarus/fpcsrc/rtl/units/i386-darwin -Fu/Users/test/
lazarus/fpcsrc/packages/univint/units/i386-darwin -FE. -FUunits/i386-
darwi
On 03 Dec 2009, at 22:59, Bruce Bauman wrote:
> If I am compiling a file bar.pas, but I want the resulting .o filename
> to be something different, is there a way to do this?
No, there is not. The unit searching logic in the compiler requires the .ppu
files and .o files to be named the same, an
On 04 Dec 2009, at 05:02, Bruce Bauman wrote:
Will it cause problems if the unit name (e.g. unit foo__bar;)
doesn't match the source filename?
I want to source filename to remain unchanged (e.g. bar.pas), but
the unit name (and .ppu and .o filenames) to be different (e.g.
foo__bar.o, foo
On 04 Dec 2009, at 14:57, Carsten Bager wrote:
I have 2 lines of code
1 I allocate memory
2 I read from the screen (Nano-X) and save it in the "BitMapArray".
Can I do this or can I not be sure that the memory is in one block.
I have no idea whether that is guaranteed. It is currently impleme
On 04 Dec 2009, at 17:03, Flávio Etrusco wrote:
On Fri, Dec 4, 2009 at 12:32 PM, Jonas Maebe > wrote:
On 04 Dec 2009, at 14:57, Carsten Bager wrote:
I have 2 lines of code
1 I allocate memory
2 I read from the screen (Nano-X) and save it in the "BitMapArray".
Can I do this or
On 04 Dec 2009, at 21:37, ik wrote:
> Is there a way to see a preprocessor of what fpc creates rather then the
> assembly code so I could see how defines and ifdefs executes (when compiling
> rtl) ?
No, but you can compile with -vc and then the compiler will print for each
conditional whether i
On 05 Dec 2009, at 21:42, Žilvinas Ledas wrote:
> is this intended behavior or it is a bug that iostream.Position always
> returns -1?
Are you reading from standard input or so? In that case it's logical that the
position is always -1, since you can't seek standard input (in theory it's
infin
On 06 Dec 2009, at 17:01, Aleksa Todorovic wrote:
> I've just started porting an application from Java to FPC (current
> targets are Win32 and Linux). I can successfully compile and run
> initial tests on both targets. The problem I have is with -FU
> parameter. When I execute
>
> fpc -FUunits/$
On 07 Dec 2009, at 10:46, Hartmut Eilers wrote:
I try to crosscompile one of my projects to the arm based
USB9263 from Calao Systems
(http://www.calao-systems.com/articles.php?lng=en&pg=5932)
I get the following linking error:
ubu...@kubuntu904:~/OpenLabTools/DeviceServer$
/usr/local/bin/ppcr
On 07 Dec 2009, at 13:41, Hartmut Eilers wrote:
ubu...@kubuntu904:~/OpenLabTools/DeviceServer$
/usr/local/bin/ppcrossarm -CfFPA -dUSB92 -CaARMEB -CpARMV5 -darm
-dFPC_ARMEL -gl -Fu../webserver -Fu../PhysMach
-Fu../divLibs/pwu-1.6.0.2-src/main/
-FL/usr/xtools/arm-unknown-linux-uclibc/arm-unknow
On 07 Dec 2009, at 14:01, ik wrote:
I'm using FPC 2.5.1 and I'm trying to do the following:
if not (Char in ['a'..'z'])
however fpc gives me an error of type mismatch for the "in"
directive. Why
can't I use the in directive on a char ?
You made a mistake somewhere. *Always* post a source
On 07 Dec 2009, at 15:19, Frank Peelo wrote:
On 07/12/2009 13:40, ik wrote:
Now it works properly. However it seems like the not is for the
"in" rather then the key if it inside the pertness.
"pertness"? I would love to know what that was before babelfish got
it...
I put my money on an
On 07 Dec 2009, at 18:05, Seth Grover wrote:
http://bugs.freepascal.org/bug_view_advanced_page.php?bug_id=15278
I have logged a bug for this. I can't see how it's anything I'm doing
personally wrong (see my "Steps to Reproduce" in the bug report).
I can't see what FPC is doing wrong either.
901 - 1000 of 3208 matches
Mail list logo
