Agreed, this is one of the weird Delphi misfeatures...
In later SynEdit versions I implemented custom streameing functions
which only store the diff from default keystrokes (i.e. the removed
and added keystrokes compared to the default list).
-Flávio
On 9/7/06, Marc Weustink [EMAIL PROTECTED]
On 7 sep 2006, at 22:08, Daniël Mantione wrote:
Or could we perhaps just import back zutil.pas but without the
memory functions?
No, there is no reason why you want to use types like Pulong etc.
One reason to do that is to keep code portable between different
Pascal compilers.
in
Op Fri, 8 Sep 2006, schreef Daniël Mantione:
For Pascal compilers, we have a very stable situation, i.e. a word is 16
bits unsigned. There is only some disagreement about the size of a
pointer.
... of an integer.
Daniël___
fpc-devel maillist -
On 8 sep 2006, at 10:37, Daniël Mantione wrote:
No, there is no reason why you want to use types like Pulong etc.
One reason to do that is to keep code portable between different
Pascal
compilers.
C compilers.
I'm only talking Pascal compilers: this is a unit part of a package
which
Op Fri, 8 Sep 2006, schreef Jonas Maebe:
On 8 sep 2006, at 10:37, Daniël Mantione wrote:
No, there is no reason why you want to use types like Pulong etc.
One reason to do that is to keep code portable between different
Pascal
compilers.
C compilers.
I'm only
On 8 sep 2006, at 10:55, Daniël Mantione wrote:
I'm only talking Pascal compilers: this is a unit part of a
package which is
available for different Pascal compiler, so people using different
Pascal
compilers (apparently) use the unit and the types declared to it.
There is no need for
On 8 sep 2006, at 11:01, Jonas Maebe wrote:
There are no endian conversions at all in the paszlib package,
which is
IMHO impossible for correct behaviour but many of these
constructions. To
be sure, can you test minigzip on OS X?
It works fine (I compressed a file with minigzip and
On 8 sep 2006, at 11:03, Jonas Maebe wrote:
There are no endian conversions at all in the paszlib package,
which is
IMHO impossible for correct behaviour but many of these
constructions. To
be sure, can you test minigzip on OS X?
It works fine (I compressed a file with minigzip and
Op Fri, 8 Sep 2006, schreef Jonas Maebe:
On 8 sep 2006, at 11:03, Jonas Maebe wrote:
There are no endian conversions at all in the paszlib package,
which is
IMHO impossible for correct behaviour but many of these
constructions. To
be sure, can you test minigzip on OS X?
Op Fri, 8 Sep 2006, schreef Jonas Maebe:
The problem is that it breaks code which depends on zutil and the
types
declared in it.
Zutil is internal paszlib use only, it is not part of the published
interface.
But it is nevertheless used by external code according the posts in
Op Fri, 8 Sep 2006, schreef Jonas Maebe:
On 8 sep 2006, at 11:03, Jonas Maebe wrote:
There are no endian conversions at all in the paszlib package,
which is
IMHO impossible for correct behaviour but many of these
constructions. To
be sure, can you test minigzip on OS X?
I have downloaded the 204 source code and compiled a Arm cross
compiler to run on a Windows PC (make clean all FPCTARGET=
OS_TARGET=linux CPU_TARGET=arm BINUTILSPREFIX=arm-linux-)
When compiling some code that has worked with the 2.0.2 (Windows)
compiler I get this error:
On 8 sep 2006, at 06:07, Robert Reimiller wrote:
Tool:0: libstrucs.pas:726: error: 36: Wrong number of parameters
specified
Tool:0: libstrucs.pas:727: error: 36: Wrong number of parameters
specified
Tool:0: libstrucs.pas:728: error: 25: Wrong number of parameters
specified
Tool:0:
On 8 sep 2006, at 00:09, Robert Reimiller wrote:
The biggest problem I'm having is that FPC is different from both
Win32 and Posix
so it hasn't been straight forward.
FPC's *nix interface is pretty much entirely based on Posix, only
with a few naming conventions:
* all Posix functions
seems more appropriate, given the turn of
the thread.
I just compiled the current 2.1.1 snapshot, and tried to compile a dumb
program with it ( with -gw -gv) and run it under valgrind for x86_64
I got the following result :
[EMAIL PROTECTED] test]$
/home/dleducq/fpc-2.1.1-20060908/lib/fpc
Marco van de Voort wrote:
P.s. Note that Indy10 clients work on OS X (powerpc)
But Indy is entirely blocking-oriented.
It depends on what the OP's intentions are. He asked for non-blocking
sockets, but that could be a result of porting some lib for which LNet or
Indy could be a substitute,
At 10:29 7-9-2006, you wrote:
Here's a patch for the readme file for fp2html. I added a
description on the added variables and the commandline options.
Applied, Thanks.
Peter
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
At 13:21 7-9-2006, you wrote:
On 7 sep 2006, at 12:54, Ale? Katona wrote:
Today I tried to find the reason behind Lazarus GTK2 slowdowns by
using
profilers. After both failed me (callgrind crashed with stabs info
error
Did you compile everything with either -gv or without debugging info?
If
On Fri, 08 Sep 2006 11:18:49 -, Jonas Maebe
[EMAIL PROTECTED] wrote:
You are using the default FPC mode as opposed to Delphi or MacPas
mode (which Xcode template are you using? They all set macpas mode by
default). Therefore the compiler interprets your use of libthread
as a function
On Fri, 08 Sep 2006 11:21:51 -, Jonas Maebe
[EMAIL PROTECTED] wrote:
FPC's *nix interface is pretty much entirely based on Posix, only
with a few naming conventions:
* all Posix functions are prefixed with fp (to avoid naming clashes
between e.g. Pascal's close and Posix' close)
* the
On Fri, 08 Sep 2006 11:21:51 -, Jonas Maebe
between e.g. Pascal's close and Posix' close)
* the things Marco mentioned
In quite a few cases var parameters are used instead of pointers, that's
the other major difference I found when porting from delphi. Maybe those
were in the
Am Freitag, 8. September 2006 21:44 schrieb Robert Reimiller:
[..]
I'm using objfpc mode. Changing addr(libthread) into @libthread
solved the problem.
I should have thought of that since I had the same problem with
getting the address of a callback procedure. It now all compiles, now
for the
This looks promising. I'll look at the code when I get some free time
and see if I'm able to do anything in this department.
Ales
If it needs to be added this more generic AOP is the best solution.
AOP also allows easy tracing on the fly with start/end of procedure
infos. We can add a
This looks promising. I'll look at the code when I get some free time
and see if I'm able to do anything in this department.
Ales
If it needs to be added this more generic AOP is the best solution.
AOP also allows easy tracing on the fly with start/end of procedure
infos. We can add a
On Fri, 08 Sep 2006 20:27:37 -, Marco van de Voort [EMAIL PROTECTED]
wrote:
On Fri, 08 Sep 2006 11:21:51 -, Jonas Maebe
between e.g. Pascal's close and Posix' close)
* the things Marco mentioned
In quite a few cases var parameters are used instead of pointers, that's
the other major
On Fri, 08 Sep 2006 20:34:48 -, Burkhard Carstens [EMAIL PROTECTED]
wrote:
Am Freitag, 8. September 2006 21:44 schrieb Robert Reimiller:
[..]
I'm using objfpc mode. Changing addr(libthread) into @libthread
solved the problem.
I should have thought of that since I had the same problem
On Fri, 08 Sep 2006 20:27:37 -, Marco van de Voort [EMAIL PROTECTED]
wrote:
fpgetsockopt uses pointers. getsocketoptions is an older (1.0.x)
compability
function.
Must of have missed it, too many choices
Got the program working (it's about 2 lines of code) with the MD5
causing
me
On Saturday 09 September 2006 04.07, Robert Reimiller wrote:
I don't know how you can keep all those different operating systems and
processors straight in your mind, an amazing feat. I think I was initially
supporting 3 or 4 operating systems back when I was doing 6809 Pascal (and
later in
28 matches
Mail list logo
