>But this seems to be be a propriety Microsoft definition while AFAIK,
"ANSI" denotes "American National Standards Institute".
While ANSI does denote american national standards institute in general
it doesn't really mean that in this context.
A windows machine has two main code pages in use (b
I decided to take another look at the freepascal armhf issue and decided
that the first step would be to build freepascal with vfp enabled but
still the softfloat ABI then once that was working.
(note: i'm currently working on upstream fpc svn, if/when I get things
working reasonablly on armhf
Maybe this will help you:
http://wiki.freepascal.org/FPC_New_Features_2.6.0#Support_for_VFPv2_and_VFPv3
Thus additionially defining -Cparmv6 might allow the build to be
completed.
It didn't.
I did find the issue though, it seems freepascal wasn't passing a fpu
type parameter to the ass
I've made some progress on armhf porting, i've added the nessacery
frameworks (vfpv3_d16 FPU target, EABIVFP ABI target, FPC_ARMHF define)
and made a start on actually implementing the new ABI. I decided to
start with function results.
However i've now reached a problem which has me stumped.
Florian Klaempfl wrote:
Am 11.03.2012 12:01, schrieb peter green:
It appears to me (i'm not an expert on arm assembler and I can't seem
to find any documentation on FPA) that FPC is generating FPA
instructions even though the FPU is set to a VFP type. What i'm really
struggl
Where is the FPU set to a VFP type?
I set it in code.
Defining FPC_ARMHF selects a new version of "system_arm_linux_info"
which sets the ABI to abi_eabivfp.
That in turn triggers a block of code that I added to options.pas which
sets the default fpu to "fpu_vfpv3_d16" and errors out if t
Then I suggest you simply debug it like any other code: first set a breakpoint in options.pas where the fpu type should be set, and verify that it is in fact set.
I'm pretty sure it is getting set because I use it in generating the
assembler command line and i'm using an assembler wrapper that
Just set a breakpoint in the place where one of the offending instructions is
generated, found via grep. E.g., the only place where an LDF is generated is in
arm/cgcpu.pas (in a_loadfpu_ref_reg).
Hmm, when I grepped for the first and most prolific problem instruction
(mvfd) I didn't find
Are you saying that VFP registers are treated as multimedia registers and not
as FPU registers? If so presumablly that mean I should be using LOC_MMREG and
not LOC_FPUREG as the location for parameters and return values?
Yes.
Thank you for your help so-far, i'm gradually making progr
NR_S0<>NR_D0: they can be identified by the sub type. Further, one can
perfectly assign NR_S1 to any location explicitly.
Umm, my copy of narmcon.pas contains the following.
NR_S0 = tregister($0406);
NR_S1 = tregister($0406);
NR_D0 = tregister($0407);
I can see how the compiler ca
Jonas Maebe wrote:
You can give S1, S3, S5 etc different super register numbers (> $1F,
so they don't conflict with the super register numbers for D0..D31).
As long as you don't change the code in
tarmcgarm/Tthumb2cgarm.init_register_allocators() to explicitly tell
the register allocator that
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
A patch with the current state of the work is attatche
While testing my armhf porting work (which I will send on request, including it
in this mail seems to make it too big for the list to accept) I came across a
case
where parameters were passed incorrectly to a function with a large number of
parameters (14 single, 1 double). Initially I thought
Daniël Mantione wrote:
Please use the command line option -sr to check the generated code
before register allocation.
Done and attatched.
You can likely find the cause in there.
The code with imaginary registers looks correct to me. It seems to load
each parameter into a seperate even numbere
Then a register is spilled, i.e. replace by a location in memory. This
may be possible without new registers:
mov ireg30d,ireg29d-> mov ireg30d,[ebp-40]
... but in some cases a help register is needed:
mov ireg30d,[ebp+20] -> mov ireg99d,[ebp+20]
The algorithm used is called "iterated register coalescing", an
advanced form of graph colouting and was designed by Andrew W. Appel.
He describes in detail in his book "Modern Compiler Implementation in C".
Thanks, I think i'll grab a copy from the uni library tomorrow.
Basically the regi
Okay, it is quite unlikely that the register allocator itself ignores
such an interference, so you may be rigth it tries to spill but
nothing happens.
Ok that wasn't the issue but you were right about not being the register
allocator.
Turns out the actual cause was a one character typo i
S30,$04,$06,$0F,s20,0,0
Should be
S30,$04,$06,$0F,s20,0,0
Doh seems I pasted the wrong line twice, it really should be
S30,$04,$06,$0F,s30,0,0
Please don't change it in trunk at the moment through because my armhf
porting work makes a lot of other changes to armreg.dat and I doubt this
b
peter green wrote:
The bad news is that a number of testcases are still failing. Next on
my list is 16 singles.
Ok that was easy, a small logic flaw in my code was preventing a
parameter being correctly assigned to the last available single
precision register when it should have been. And with
I can now successfully pass doubles to/from C functions on armhf. I've
written a test program that passes lots of different combinations of
single/double/longint/int64 to C code and all combinations that do not
involve singles are working.
It would also be helpful to add this test to th
The buildfaq claims that OPT= will add parameters to every compiler
commandline. Unfortunately it doesn't seem to actually do that. The
options are added when building the compiler and RTL but it seems they
aren't added when building fpmake.
This is a problem for me as to successfully build fp
Jonas Maebe wrote:
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Unfortunately just after I sent the mail what I thought was a minor
problem in the build system turned out to be more serious than I
thought, namely
Jonas Maebe wrote:
The compiler should find the crt*.o files on its own, especially if you create
a special compiler binary for the hard float ABI (there is no point in creating
a special binary if you still need to separately specify a bunch of additional
options to get the correct behaviour)
Unfortunately just after I sent the mail what I thought was a minor
problem in the build system turned out to be more serious than I
thought, namely cthreads is crashing at initalisation time. I really
need to figure out why before merging this patch is considered.
Ok solved that issue, it see
Jonas Maebe wrote:
On 20 Mar 2012, at 23:43, peter green wrote:
I attatch a patch which adds support for armhf to freepascal.
Thanks!
Armhf reffers to arm with the VFP hardfloat variant of EABI. The
defaults are setup to
be suitable for debian armhf (armv7 vfpv3_d16).
Are they Debian
Is it possible to tell the inline assembler to output something to the
resulting assembler file even though it doesn't recognise the opcode?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
I am involved in a project called raspbian to produce a hard-float
derivative of debian for the raspberry pi. Within this port we had
problems with floating point exceptions while running the compiler.
These problems were tracked down by masta (a freepascal upstream
developer) to reversed logic
peter green wrote:
an IMX53 quickstart board running
That should have said running 3.2.0-2-mx5
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
shawn wrote:
http://sourceware.org/ml/libc-ports/2012-06/msg00021.html
I quote: "ARM VFPv3 and VFPv4 do not support trapping floating-point
exceptions;
VFPv2, VFPv3U and VFPv4U do. The lack of support causes the glibc
math/test-fenv test to fail on VFPv3 and VFPv4 systems
Am I correctly inte
Thomas Schatzl wrote:
Last time I tried compiling with -Cfvfpv2 or 3 the compiler did not
cycle, so I could not test further. Has been some time, and this was
native compilation.
Last I heard cycling goes fine but FPU options don't get passed down
to other parts of the build process leading t
I have long understood that each stable release of freepascal is made to
be compilable with the previous release but at a quick glance at the
website I couldn't seem to spot any official statement of this. Is it
indeed "supported" to compile a stable release with the previous stable
release and
Den Jean wrote:
On Thursday 04 October 2012 21:54:19 Thomas Schatzl wrote:
Basically the difference between armel and armhf are
- fpc cannot create valid armhf shared libraries
Other problems common to both (just from interpreting the testsuite
results, filtering known failing tests):
-
Michel Catudal wrote:
I am also having some issues with Lazarus, I am not sure if it is the
right forum to talk about it. I had a previous version working fine on
Rasphberry Pi.
For some reason I can't get it to work on Mele A2000G. I have compiled
it on gentoo on the Mele, using distcc and loc
Johan Kotze wrote:
It seems that fpc in fact does not produce ARMHF executables with the
parameters that I use. Am I using the wrong parameters or is something broken
in the ARMHF support ?
IIRC fpc doesn't set elf tags to mark objects as hardfloat, this is
something I need to look into (if
For those reading this on fpc-devel the context is that the upload of
fpc 2.6.2 to debian failed on most architectures and I would like
upstream input on sorting it out.
Abou Al Montacir wrote:
Many targets are broken: powerpc, sparc, armel, armhf. The error message
looks very similar on 3 tar
Marco van de Voort wrote:
After some discussion, something to try:
try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT
(for host)
Unfortunately it seems that at least when building natively (note:
debian is and always has been natively built) neither OPT or CROSSOPT is
Michel Catudal wrote:
You will find binaries for fpc 2.6.2 with hard float support as well as larazus
1. The code is based on the code from Debian.
Out of interest what if anything did you change compared to the package
from debian? did you just rebuild it in a different environment?
_
Joost van der Sluis wrote:
On 08/09/2013 07:07 PM, Jonas Maebe wrote:
On 09 Aug 2013, at 18:46, Joost van der Sluis wrote:
Thing is that I'm trying to get fpc 2.6.2 working on the new
arm-target of Fedora (armv7, hardware float, little endian).
The EABI with hardfloat is not supported at al
I don't think that people will be happy if the compiler just deletes
their ppus if it can't read it for any reason. The compiler cannot know
if it can recreate the ppu when it deletes it.
Can't it just be made to treat a damaged/unreadable ppu in the same way
as an outdated or incompatible (
Freepascal has been failing sometimes with "einouterror file not found"
on armel buildds but i'm not really seeing any pattern to the failures
either in terms of upstream versions or in terms of buildds
2.4.0-2 was successfully built on muscat
2.4.0-3 failed on arnold
2.4.0-4 failed on arnold a
Riku Voipio wrote:
Qemu allows unaligned memory accesses, which do not always work on real
hardware, especially on armv5 and other older arms.
Do you know specifically how the debian buildds handle unaligned
accesses? do they fix them up? do they generate a bus error? do they let
them go si
Mark Morgan Lloyd wrote:
Riku Voipio wrote:
On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote:
The current FPC package builds fine in qemu for me. I will attempt
to try on some real hardware too when I get a chance.
Qemu allows unaligned memory accesses, which do not always work
Jonas Maebe wrote:
On 30 Jun 2011, at 19:04, peter green wrote:
Mark Morgan Lloyd wrote:
Riku Voipio wrote:
On Thu, Jun 30, 2011 at 03:33:36PM +0100, peter green wrote:
The current FPC package builds fine in qemu for me. I will attempt to try on
some real hardware
reassign 636802 fpc
thanks
From my testing on armel I now belive that the issue causing the
lazarus build failures is a problem with freepascal and multiarch. I
haven't tried to troubleshoot the issue on powerpc or sparc as I don't
have access to them but I presume it is the same issue.
On a
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the
unit serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp
works fine.
tags 636802 +patch
thanks
Note: jonas's reply was only posted to fpc-devel, not to the debian bug
report , a copy can be found at
http://lists.freepascal.org/lists/fpc-devel/2011-August/025444.html
Jonas Maebe wrote:
Is there a standard for multiarch library path locations and names?
Multi
First a bit of background, on arm ebi gcc has three options for
"-mfloat-abi"
soft: do all floating point in software, ignore the fpu type selection
softfp: use the selected fpu type but use the same calling conventions
as "soft" (that is parameters are passed using integer registers). This
gi
have you tried using virtual pascals wincrt unit with freepascal?
and if so does it compile and work?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Rimgaudas
> Laucius
> Sent: 05 November 2004 00:07
> To: [EMAIL PROTECTED]
> Subject: [fpc-devel] gui
just move what you presently have in the implementation to the interface and
remove what you currently have in the interface
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of
> [EMAIL PROTECTED]
> Sent: 25 November 2004 17:19
> To: FPC developers' list
>
> I guess this is no solution. It makes porting delphi apps very hard.
> What's the problem if thandle is 64 bit on 64 bit systems? You can still
> store a 32 bit file handle in it.
the only place I could see is var parameters.
and if needed that could be got around by overloading functions users
Warning: Access denied for user: '[EMAIL PROTECTED]' (Using password: YES)
in /FPC/html/bugs/bugs.php on line 11
Warning: MySQL Connection Failed: Access denied for user:
'[EMAIL PROTECTED]' (Using password: YES) in /FPC/html/bugs/bugs.php on line
11
An error occurred while executing an mYSQL que
im posting this direct to the list as the bug report system is down
www.p10link.net/iesecondcompile.tbz
extract the archive with tar -jxf and run the test script.
the first compile will succeed the second compile will exit with ie
the problem appears to happen when loading the lcore.ppu
have you tried using virtual pascals wincrt unit with freepascal?
and if so does it compile and work?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Rimgaudas
> Laucius
> Sent: 05 November 2004 00:07
> To: fpc-devel@lists.freepascal.org
> Subject: [fp
you are forciblly putting an out of range value in a variable what do you
expect to happen?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
> Sent: 30 December 2004 19:37
> To: lista de fpc-devel
> Subject: [fpc-devel] compiler bug?
>
>
> I
.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
> Sent: 30 December 2004 21:49
> To: FPC developers' list
> Subject: RE: [fpc-devel] compiler bug?
>
>
> --- peter green <[EMAIL PROTECTED]> escribió:
> > you are
Different languages approach boolean operations in different ways.
1: the C way
false=0 true=anything else seperate logical and bitwise operators.
2: the BASIC way (also used by the access database)
false=0 true=-1 logical and bitwise operations therefore equivilent
(though it should be noted
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marco van de
erstanding of include files. Codetools don't work at
> all if you use
> > include files. That said: $ifdefs confuse it as well...
>
> That is one, the another is that they simply have support
>If you go this way I'd suggest adding also Lazarus.
>I know the thing is "just another project made with FPC" but I think it
>would be good for both.
lazarus and freepascal are far closer than that.
lazarus is essentially what completes the cloning of delphi by freepascal.
_
if i do ansistringvar := widestringvar or widestringvar := ansistringvar
what does the compiler do?
1: use the systems default encoding (if so obtained from where?)
2: use utf-8
3: use iso-8859-1
4: use something else?
furthermore if the encoding used is one not capable of representing all
unicod
where are theese default versions located in the code?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Alexey
> Barkovoy
> Sent: 05 January 2005 07:36
> To: FPC developers' list
> Subject: Re: [fpc-devel] ansistrings and widestrings
>
>
> > if i do ans
Van
> Canneyt
> Sent: 05 January 2005 16:11
> To: FPC developers' list
> Subject: RE: [fpc-devel] ansistrings and widestrings
>
>
>
>
> On Wed, 5 Jan 2005, peter green wrote:
>
> > where are theese default versions located in the code?
> >
>
fpc-devel] ansistrings and widestrings
>
>
>
>
> On Wed, 5 Jan 2005, peter green wrote:
>
> > where are theese default versions located in the code?
> >
>
> In the inc directory of the rtl. wstrings.inc
>
> procedure Wide2AnsiMove(source:pwidechar;dest:pchar
and both
> Delphi and FPC define WideString as double byte strings. So semantically
> functions do that is required. IMHO then assigning widestring to
> ansistring
> noone should expect multibyte encoded result. Then you need utf-8
> you should
> call special functions.
>
>
> PPS. AFAIK UTF-8 is not used internally in any OS - it's only
> used for storing
> UNICODE text in more compact form - web site authors really like it.
i belive a lot of linux distros are switching to it for the console at least
for less common languages i don't know how gui stuff on linux hand
it should be noted that pascal classes are really not suited to doing
strings.
to do strings with classes you really need language features which fpc
doesn't have.
doing strings with non garbage collected heap based classes would make
something that was as painfull to work with as pchars and that
> Type
> // Lenght paremeters are number of CHARS not bytes
> TWide2AnsiMove=function(source:pwidechar; srclen:SizeInt;
> dest:pansichar;
> destlen:SizeInt): SizeInt;
> TAnsi2WideMove=function(source:pansichar; srclen:SizeInt;
> dest:pwidechar;
> destlen:SizeInt): SizeInt;
>
> These function
> [EMAIL PROTECTED] wrote:
> > int64 <> integer ???
>
> The compiler reports a range check error depending on $R as
> warning or error. So
> where is the problem? What do you expect to happen?
im not going to argue whether this is right or wrong but in delphi at least
$R only affects run time rang
i want to atempt to port FPC to a new CPU target (PIC18F452)
there don't seem to be any guides to starting a port. any idea where one
sohuld start when porting fpc.
note: the cpu architecture in question has nowhere near enough power to
support the compiler so all compilation for this target will
this is not a bug
if when someone does pcharvar := ansistringvar or pwidecharvar :=
widestringvar we increased the refcount every program that used that
construct would leak memory.
where compiler automated types like ansistring and widestring meet non
automated types like pchar and pwidechar som
> 1. Memory management. Delphi is quite incosistent here by allowing
> component classes to be auto managed (via their owner) whilst
> non-component class have to be manually managed. The best solution I can
> think for this is to reference count non-component classes. This should
> be safe for TO
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 26 February 2005 03:34
> To: FPC developers' list
> Subject: Re: [fpc-devel] Modernising Pascal
>
>
> Jamie McCracken wrote:
>
> > GC is very inefficient with memory and current implem
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 01 March 2005 07:33
> To: FPC developers' list
> Subject: Re: [fpc-devel] Improving Ref Counting
>
>
> Jamie McCracken wrote:
>
> > A GC needs to trace an object's references to see if
note: a config file is NOT needed to compile freepascal itself the makefiles
pass an option that tells the compiler to ignore it anyway.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Dr.
> Karl-Michael Schindler
> Sent: 19 March 2005 23:11
> To: FPC d
btw theese changes have already been committed (i sent them personally to
fpk). It seems like this mail was held for approval or something (i
previously thought it had been dropped)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of peter green
&
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of DrDiettrich
> Sent: 16 March 2005 10:59
> To: FPC developers' list
> Subject: Re: [fpc-devel] "Friend" classes?
>
>
> Michael Van Canneyt wrote:
>
> > > type TFriendClass = class(TNotMyClass);
> >
> > Thi
oops looks like i commented out the wrong line when changing the
widestringmanager system for improved flexibility.
the code should be:
Function fpc_ShortStr_To_WideStr (Const S2 : ShortString): WideString;
{$ifdef hascompilerproc} compilerproc; {$endif}
{
Converts a ShortString to a WideString
> > The only *disadvantage* of units are the current Pascal compilers, which
> > cannot handle circular unit references :-(
>
> No, it's an advantage: it makes the code and design clearer, plus
> it increases the speed of compilation a *lot*.
>
note: you can have cuircular implementation reference
the second part of the filename of the compiler specifies the target cpu (ie
what cpu it produces code for)
no information on the system the compiler itself is meant to run on is
contained in the file name
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf
> "DO NOT CONTACT THE JUDGES DIRECTLY. ANY ENTRANT WHO CONTACTS THE
> JUDGES DIRECTLY FOR ANY REASON WILL BE IMMEDIATELY DISQUALIFIED."
>
> We are the judges for this port. I assume "posting on a mailing list"
> does not constitute "contacting judges directly", but better be safe
> than sorry.
>
>
exe size is significant if you wan't to get your apps good reviews on
freeware sites etc.
thats why people use upx in the first place. its all about perception.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marco van de
> Voort
> Sent: 29 May 2005 20
> > Well the problem is that you cannot find a word about this "setting" in
> > any readme or web-page, the problem is that someone that doesn't know
> > about it could loose hours trying to find why GtkFileChooserDialog is
> > unavailable although there's an entire array of files with it's nam
> >
> > Would it be possible to get something like
> >
> > L.Sort(@ICmp(PBigInt,PBigInt));
> >
> > in case ICmp is overloaded? If we could add the parameter
> > types, there would be no more ambiguity, the compiler would
>
> There is ambiguity with a normal call to the function. The compiler sees
shouldn't it implement inv(v,-1) in exactly the same way it implements
v:=v-1?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Marcel
> Martin
> Sent: 06 July 2005 23:36
> To: FPC developers' list
> Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)
>
>
>
> > As I understand it the ARM version of FPC is not self hosting,
> it must run
> > on a 386 based Linux system and run as a cross compiler, correct?
>
> The precompiled package, yes. However, you could create a self hosting
> package (having an arm with at least 64 MB RAM and 1 GB disk) or a cros
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Robert
> Reimiller
> Sent: 20 August 2005 02:10
> To: fpc-devel mailing list
> Subject: [fpc-devel] Re: FPC Arm options
>
>
> Just a followup, I noticed the following during bootup:
>
> NetWinder Floating
would it be feasible to turn them off just for calls into the carbon
framework and have them on the rest of the time?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jonas Maebe
> Sent: 04 November 2005 21:32
> To: FPC developers' list
> Subject: Re: [f
> pos('ë','Daniël');
>
> ... has a different implementation for utf-8 and 8-bit code pages.
one little desgin feature of utf-8 is that is was carefully designed to be
friendly to byte-orientated code. No special precautions are needed for
substring matching in utf-8!
_
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Daniël
> Mantione
> Sent: 16 November 2005 21:58
> To: FPC developers' list
> Subject: RE: [fpc-devel] Unicode RTL
>
>
> Op Wed, 16 Nov 2005, schreef peter
> *sigh* Yes, what he says is correct. Now to do something with
> strings. I.e. reverse them, or any other operation that needs to split
> the string into pieces.
reversing a string properly requires a very deep understanding of unicode
and huge lookup tables (reversing the code point order will b
> Who knows the future?
> Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all
> remaining languages.
> Or maybe 32bit encodings will become the default.
the unix and web worlds are going utf-8 the ms and java worlds are going
utf-16 both are variable width
> The way to get users do
> more work in writing
> documentation, is to have a comment system right up live on the
> website. Even the PHP
> manual does this ;-)
yeah the accuracy of said information leaves a LOT to be desired though
imo if this is done someone needs to be resposible for looking a
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Micha
> Nelissen
> Sent: 12 December 2005 11:18
> To: FPC developers' list
> Subject: Re: [fpc-devel] StrPos giving a access violation
>
>
> Jonas Maebe wrote:
> > strpos, I don't know about Delphi. If yo
note
that if the data you wan't to store in a tlist is the size of a pointer or less
you can store it directly in the tlist.
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Sterling
BatesSent: 14 December 2005 22:04To: FPC developers'
list
should we use MSWINDOWS instead especailly
as thats what borland seems to be using for windows now (in addition to the more
specific WIN32).
-Original Message-From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of
[EMAIL PROTECTED]Sent: 15 January 2006 20:14To:
fp
i belive there was recently a change to how widestring length was stored for
OLE compatibility reasons. this bug was probablly caused by that change.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Jesus Reyes
> Sent: 29 January 2006 04:53
> To: FPC dev
if 3 out of the 4 major bsds support it shouldn't it be in a generic bsd
unit?
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Ales Katona
> Sent: 31 January 2006 16:05
> To: FPC developers' list
> Subject: [fpc-devel] FreeBSD/kqueue
>
>
> These files a
D] Behalf Of Ales Katona
> Sent: 31 January 2006 16:45
> To: FPC developers' list
> Subject: Re: [fpc-devel] FreeBSD/kqueue
>
>
> peter green wrote:
>
> >if 3 out of the 4 major bsds support it shouldn't it be in a generic bsd
> >unit?
> >
> >
&g
What i'd like to see is compiler level support for loading dynamic libraries
and binding thier functions on demand.
this would mean a lot more flexibility. New features could be used without
breaking compatibility with older versions of the library. Version and
naming issues could be dealt with at
> > What i'd like to see is compiler level support for loading
> dynamic libraries
> > and binding thier functions on demand.
>
> Like the database-base packages do? (example:
> packages/base/ibase/ibase60dyn.pp)
ok that unit really confuses me, it seems to treat procedures declared
external as if
oost van
> der Sluis
> Sent: 09 May 2006 23:26
> To: FPC developers' list
> Subject: RE: [fpc-devel] a shared library suggestion
>
>
> On Tue, 2006-05-09 at 21:26 +0100, peter green wrote:
> > > > What i'd like to see is compiler level support for loading
>
1 - 100 of 180 matches
Mail list logo
