Re: [fpc-devel] Compiler trheads (was: NoGlobals branch)

[Helmut Hartl]

 Am 12.08.10 11:23, schrieb Marco van de Voort:

[2] How portable is a dynamic thread priorization?

You don't. Your control thread determines what module is compiled/resumed
next when a worker thread comes available. There is no reason to do this via
funky thread systems.
A single controlling thread does not scale very well. A better solution 
is that the
workers choose their work by themself. Or to use some sort of 
distribution queues.


After doing years of multithreaded development in our communication 
appliance
we found that apple came to a similar solution like our own, and took 
the time to write it down :-)


http://developer.apple.com/mac/library/documentation/General/Conceptual/ConcurrencyProgrammingGuide/ThreadMigration/ThreadMigration.html#//apple_ref/doc/uid/TP40008091-CH105-SW1

We have an custom written scheduler that operates on lock free 
distribution queues that feed exactly
or less that amount of threads that the machine is able to do really 
parallel.
We strive to use no locks at all by distributing the work(chunks) 
directly to a per worker thread queue,
and where not possible to use lock free algorithms. Ideally is to 
partition the data if it's known beforehand
or at an early stage. Also it is good to keep the working set data per 
thread and per core locally and don't move it from

core to core.

More infos:

About the speed of locks :
http://transact09.cs.washington.edu/19_paper.pdf

About  memory/cache/threading in general:
Google: Ulrich Drepper, What every programmer should know about memory

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Compiler trheads (was: NoGlobals branch)

[Helmut Hartl]

 Am 12.08.10 13:37, schrieb Marco van de Voort:

So, I'm no thread expert, but does this all really matter that much if the
units (literally) to schedule are in the tens of ms magnitude and HDD access
is required for each of them ?

Of course you are fully right and it depends on the particular problem -
we for example do inplace analysis of tcp / udp packets in memory over gb
links with no spinning disks.

What I wanted to say is that the work and concepts already done by 
others (apple and various others)
can be reused as it's unlikely to have a quick win with an own first 
solution and to provide some

(useful) links.

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Alternative parsers

[Helmut Hartl]

 Am 19.10.10 15:40, schrieb Alexander Klenin:

I fully understand that the reason for degrading the code structure
was efficiency.
I just doubt that it was/is a good trade-off.

Dear FPC Team,

After finishing porting the bullet physics library from C++ to FPC in the
last 2 months (http://bulletphysics.org/wordpress/). I had the chance
to compare Xcode, MS Visual C++  and MinGW GCC regarding compilation
speed.
FPC is about 3-20 times(!) faster then those (modern) compilers on pure
compilation speed. That is a fact at least for me and my employees.
I had to debug the library on multiple archs with multipe tools side by 
side,

step by step to find my porting errors - and I had to
add lots of debug code in the original code, so I was able to "feel" and
measure the turn around times.

I am happy that you all have a deep understanding of writing fast and
memory efficient code, because I can use the compiler as spell checker.

I am happy that I can use FPC to do 10 GBit Line speed network analysis and
real time protocol identification under FreeBSD, with a small team of
developers because they can read and debug pascal code fast and have 
superior

turn around times.

I am happy that I can also use "degraded" datastructures in conjunctions 
with
lock free algorithms and that I have the choice to use them if I 
understand them.


Thank you all for the exceptional stability of the FPC trunk on Windows, 
FreeBSD (32)
and OSX because we use the latest trunk version to do our development 
(generics).


Thank you that my company was/is able to write a cross platform OpenGL 
Engine

for data visualization which now works with OpenGL 4, OpenCL and optimized
Shadercode, completly driven by FPC. (Shadercode and OpenCL code is in C)
Proving that FPC is able to feature recent technology projects.

Thank you for your long time support of language features - using 
objects (TP objects)
as generics has proven to be sucessfully fast for vector, 
matrix,quaternion and memory

management operations while maintaining a FPU needed layout easily.

Thank you all for your time reading, thinking, answering often 
stupid/lazy mails and

bug reports from me.

Please continue your good judgement about trunk codebase improvements.

helmut







___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Dwarf3 and the encoding of classes

[Helmut Hartl]

Am 12.01.11 11:39, schrieb Joost van der Sluis:

That is bad news, because it seems like it that the
final-case-sensitivity solution will be that the case-sensitive flag is
used to control the behavior. But that will then break backwards
compatibility...

I have osx, freebsd, linux and windows as targets.
Currently debugging with lazarus under osx is a horrible experience :-).
(http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Known_Problems and 
more)


Is there a chance to build (your) patched gdb versions for that targets too?
So that there is the possibility to have the same (working) gdb version 
for all targets.(dreaming)

Maybe even a static build? (more dreaming)

As this is our daily business I think I am able to donate some time in 
testing/debugging/codeing too,

if that could help.

helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to get FPC to generate floating point instructions for ARM?

[Helmut Hartl]

Am 17.03.11 12:48, schrieb Jonas Maebe:

There won't be an iOS 2.4.4 release, because it would barely work with
current iOS SDK releases:
a) as of Xcode 3.2.0, simulator builds require the iphonesim target
that only exists in 2.5.x
b) as of Xcode 3.2.6 and Xcode 4, all object files (including those
generated by the resource compiler) must having matching ARM
architecture identifiers of the linker will refuse to link them, and
there does not appear to be a way to override this anymore (this
hasn't even been fixed in fpc trunk yet)


Jonas

What has to be done to get trunk working with XCode 4 ?

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] How to get FPC to generat floating point instructions for ARM? [solved Fpc 2.5.1 iOS4.3 Compiler Build]

[Helmut Hartl]

Am 13.04.11 14:59, schrieb Jonas Maebe:

On 13 Apr 2011, at 14:22, Helmut Hartl wrote:


Am 17.03.11 12:48, schrieb Jonas Maebe:

There won't be an iOS 2.4.4 release, because it would barely work
with
current iOS SDK releases:
[...]

What has to be done to get trunk working with XCode 4 ?

To clarify: that only affects iOS. Plain Mac OS X compilation works
fine with Xcode 4 (better than with Xcode 3 in fact, since the linker
bug mentioned at e.g. 
http://www.freepascal.org/down/i386/macosx-ftp.freepascal.org.var
   under "Mac OS X 10.6 (Snow Leopard) compatibility" has been fixed).

As for iOS, see the attached messages.

Thank you very much for your help.
It was not trivial (at least for me) to do the build, so i want
to give feedback how it worked for me.

1) I tried to install the last fpc ios 2.5.1 snapshot
(wiki iPhoneSnapshot-2.5.1-r14397)

->  failure due to only XCode4 and iOS SDK 4.3 available
->  and SDK not found by fpc after install script

2) Patched: "finish_fpc_iphone_install.command"

[…]
# Obtain the installation directory of the SDK.
[…]
+ elif [ -f 
"/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk/usr/include/arm/_structs.h"
 ]; then
+  IPHONEINSTALLDIR=/Developer
+  IPHONESDKDIR=iPhoneOS4.3.sdk
[…]

Resulting in :


ld: warning: -ios_version_min not specificed, assuming 4.3

ld: object file 
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk//usr/lib/crt1.o
 was built for different arm sub-type (6) than link command line (0) for 
architecture arm
An error occurred while linking
pp.pas(224,1) Error: Error while linking
pp.pas(224,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[3]: *** [ppcarm] Error 1
make[2]: *** [cycle] Error 2
make[1]: *** [compiler_cycle] Error 2
make: *** [build-stamp.arm-darwin] Error 2
An error occurred during building everything for ARM
When asking for help with this error, please provide the entire contents of
this window (you can copy/paste it)

You can restart this script by double-clicking it in the Finder at
/Developer/FreePascalCompiler/iPhoneSnapshot-2.5.1-r14397/InstallScript/finish_fpc_iphone_install.command

3) Now I copied the translated "sig_cpu.inc" to my svn trunk checkout 
"rtl/darwin/arm/" dir
4) Applied the cpu subarch type patch from jonas
5) regenerated the fcl-web makefile with the original version
  (cp Makefile.org Makefile.fpc then fpcmake -Tall)
Due to Error:
HHMacBookPro:trunk helly$ sudo make FPC=/usr/local/lib/fpc/2.4.2/ppc386 CPU_TARGET=arm 
CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin 
-XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap -Cfvfpv2" all
[…]
make -C fcl-web clean
./fpmake clean --localunitdir=../.. --globalunitdir=.. --os=darwin --cpu=arm -o 
-Parm -o -Ur -o -Xs -o -O2 -o -n -o 
-Fu/Users/helly/pascal/bzr_fpc/trunk/rtl/units/arm-darwin -o 
-Fu/Users/helly/pascal/bzr_fpc/trunk/packages/hash/units/arm-darwin -o 
-Fu/Users/helly/pascal/bzr_fpc/trunk/packages/paszlib/units/arm-darwin -o 
-Fu/Users/helly/pascal/bzr_fpc/trunk/packages/fcl-process/units/arm-darwin -o 
-Fu/Users/helly/pascal/bzr_fpc/trunk/packages/fpmkunit/units/arm-darwin -o -FE. 
-o -FUunits/arm-darwin -o -darm -o -dRELEASE -o 
-FD/Developer/Platforms/iPhoneOS.platform/Developer//usr/bin -o 
-XR/Developer/Platforms/iPhoneOS.platform/Developer//SDKs/iPhoneOS4.3.sdk/ -o 
-ap -o -Cfvfpv2 --compiler=/Users/helly/pascal/bzr_fpc/trunk/compiler/ppcrossarm
make[3]: ./fpmake: Bad CPU type in executable
make[3]: *** [clean] Error 1
make[2]: *** [fcl-web_clean] Error 2
make[1]: *** [packages_clean] Error 2
make: *** [build-stamp.arm-darwin] Error 2
[…]

6) Then finally:
sudo make FPC=/usr/local/lib/fpc/2.4.2/ppc386 CPU_TARGET=arm 
CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin 
-XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap -Cfvfpv2" all
sudo make FPC=`pwd`/compiler/ppcrossarm OPT="-ap" CPU_TARGET=arm 
CROSSOPT="-FD${IPHONEPLATFORMBASEDIR}/usr/bin 
-XR${IPHONEPLATFORMBASEDIR}/SDKs/iPhoneOS4.3.sdk/ -ap" install CROSSINSTALL=1
sudo ln -sf ../lib/fpc/2.5.1/ppcrossarm /usr/local/bin/ppcarm

Yielded:
HHMacBookPro:trunk helly$ ppcarm
Free Pascal Compiler version 2.5.1 [2011/04/14] for arm
[…]

I have not tested the compiler by now, but was happy to build it.
As next step I want to try to port some of our opengl/physics code
to the iPad2.

helmut





___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1

[Helmut Hartl]

Hi,

while testing our code on freebsd 9RC1/32 bit with fpc 2.6rc1
it seems that all programs compiled on that system using threads crash
with an "Illegal Instruction 4 (core dumped)" error.
Binaries compiled on Freebsd 8.2/32 and transferred to the 9RC1 box work,
which is a bit strange.

Any ideas ?

further details below:

Simple test case:

---
program thrd;
{$mode objfpc}{$H+}
uses
  cthreads,Classes;
type
   T=class(TThread)
   private
i:integer;
procedure Execute;override;
   end;

procedure T.Execute;
begin
  inc(i);
end;
begin
  T.create(false);
end.

---

After compiling fpc 2_6 fixes with debug info, and running the program
gdb stops at the below marked line in cthreads.pp

procedure CAllocateThreadVars;
  var
dataindex : pointer;
  begin
{ we've to allocate the memory from system  }
{ because the FPC heap management uses  }
{ exceptions which use threadvars but   }
{ these aren't allocated yet ...}
{ allocate room on the heap for the thread vars }
>  
DataIndex:=Pointer(Fpmmap(nil,threadvarblocksize,3,MAP_PRIVATE+MAP_ANONYMOUS,-1,0));

FillChar(DataIndex^,threadvarblocksize,0);
pthread_setspecific(tlskey,dataindex);
  end;

--
helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] threads crash on FreeBSD 9 RC1, FPC 2.6RC1

[Helmut Hartl]

Am 09.11.11 14:12, schrieb Pierre Free Pascal:

while testing our code on freebsd 9RC1/32 bit with fpc 2.6rc1
it seems that all programs compiled on that system using threads crash
with an "Illegal Instruction 4 (core dumped)" error.
Binaries compiled on Freebsd 8.2/32 and transferred to the 9RC1 box work,
which is a bit strange.

   There is no warranty that an executable for a given version
will work on a later...
   If only one system call interface is changed, this is enough to break
everything!

What made me wonder was, that the (old) binary compiled on 8.2 still 
worked on 9.0RC1
after the upgrade from 8.2 -> 9.0 (same machine) while the new one 
compiled with the same

compiler after the upgrade crashed.
If I copy back the new binary (same source) to a 8.2 machine it fails 
with a linker failure
unresolved symbol "sem_init".  But thats only a observation that i am 
too dumb to

understand atm, and maybe unrelated to the main problem.

My (quick) deduction from the output below was that somewhow the 
initialisation of the memory
managment for the new thread gone bad, as the crash seems to be in the 
new thread.

Hence I changed the memorymanager to cmem and the problem goes away, now our
software works and passes it's testsuites.


Any ideas ?



   What does
(gdb) x /10i $rip
(or $eip if it is an i386 executable)
give as output?

Here what Is what I have got on that:

[helly@f932 /usr/home/helly/pascal/fpctest]$ /usr/local/bin/gdb73.1 
./project_test

GNU gdb (GDB) 7.3.1 [GDB v7.3.1 for FreeBSD]
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-portbld-freebsd9.0".
For bug reporting instructions, please see:
...
Reading symbols from /usr/home/helly/pascal/fpctest/project_test...done.
(gdb) r
Starting program: /usr/home/helly/pascal/fpctest/project_test
[New LWP 100461]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to LWP 100461]
0x280a0e71 in r_debug_state () from /usr/libexec/ld-elf.so.1
(gdb) c
Continuing.
[New Thread 28404300 (LWP 100461)]
test
[New Thread 28404900 (LWP 100465)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28404900 (LWP 100465)]
0x0805c34d in WAITFREE_VAR (PMCV=0x282d10a4) at 
/usr/home/helly/pascal/fpc_fixes_2_6/rtl/inc/heap.inc:1084

1084  pmcv^.next_var := pmcv^.freelists^.waitvar;
(gdb) bt full
#0  0x0805c34d in WAITFREE_VAR (PMCV=0x282d10a4) at 
/usr/home/helly/pascal/fpc_fixes_2_6/rtl/inc/heap.inc:1084

No locals.
#1  0x282d10b0 in ?? ()
No symbol table info available.
#2  0x280ec46a in ?? () from /lib/libthr.so.3
No symbol table info available.
#3  0x in ?? ()
No symbol table info available.
(gdb) x /10i $eip
=> 0x805c34d :mov0xa0(%eax),%eax
   0x805c353 :mov%eax,0xc(%ebx)
   0x805c356 :mov0x4(%ebx),%eax
   0x805c359 :mov%ebx,0xa0(%eax)
   0x805c35f :mov$0x80e5698,%eax
   0x805c364 :call   0x805cd28 
   0x805c369 :mov(%esp),%ebx
   0x805c36c :add$0x4,%esp
   0x805c36f :ret
   0x805c370 :sub$0xc,%esp
(gdb)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] NowUTC in the RTL

[Helmut Hartl]

Am 09.12.11 15:19, schrieb Michael Van Canneyt:

That's not the question.

clock_gettime is a linux kernel call. No-one is proposing to add it to 
sysutils.


The question is whether clock_gettime is POSIX, and if BSD has it.
The linux man page seems to say it is POSIX 2001. My question is if 
BSD has it.


If so, it can be added to baseunix/unix, instead of linux.


it is - i am using it since years ...

http://www.freebsd.org/cgi/man.cgi?query=clock_gettime

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] NowUTC in the RTL

[Helmut Hartl]

Well, if OS-X does not have it, we can't really say it is POSIX for 
our purposes, so then it goes to the linux unit. It's as simple as that.


Only if you discriminate BSD  systems :-) - Many professional vendors 
use some sort of BSD in their products,

and some fpc.

Freebsd, Netbsd, Openbsd, and Linux  has it.
For OSX there is a substitution: 
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x


helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] NowUTC in the RTL

[Helmut Hartl]

Am 09.12.11 16:25, schrieb Michael Van Canneyt:



On Fri, 9 Dec 2011, Helmut Hartl wrote:



Well, if OS-X does not have it, we can't really say it is POSIX for 
our purposes, so then it goes to the linux unit. It's as simple as 
that.


Only if you discriminate BSD  systems :-) - Many professional vendors 
use some sort of BSD in their products,

and some fpc.

Freebsd, Netbsd, Openbsd, and Linux  has it.
For OSX there is a substitution: 
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x


Well, you'll have to convince Marco. But I think it's that time of the 
month, when he's hard to convince, just for the fun of discussion :)


But till you do convince him, I'll put it in the linux unit, and Marco 
can put it in a *BSD specific unit.


That's what these units are for.

Michael.


:-) Boy, I am happy that I dont need to convince anybody anymore.

@granularity:
The granularity is not only OS dependend but hardware dependend.
In FreeBSD you have the granularity if you have a hardware high 
precision timer.
This can be queried via sysctls, i assume this is handled in other os's 
similar.

For our software we have to handle this target and hardware specific(!).
But we use server appliance hardware with freebsd and fpc software
for our products - and that  is somewhat exotic.

@speed
The constants influence highly the time needed for the call, so
in general you want to know what for you need the time base.
Some background:
http://phk.freebsd.dk/pubs/timecounter.pdf

@portable NowUTC
I would have been happy if FPC had provided me the super ultra fast,
high precise and platform independend timer routine,
But i would not have been happy for long - As fpc simply can't
read ones mind and be better then the underlying hardware/os.
If i recall right we use 4 different timing mechanism throughout our
source because we need them.

So if FPC provides a generic higher precise timing routine is should be
documented that it is a starting point only.

But of course it would be nice for every day usage to have a
cross platform call.

helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Solaris and binutils 2.22 break fpc linking and workaround

[Helmut Hartl]

Hi,

While building under SmartOS in a buildzone
(IllumOS, former OpenSolaris) i have the problem that with
binutils 2.22 the fpc generated linker script line in ppas.sh

/opt/local/bin/gld -melf_x86_64-s -L. -o my_program link.res

is not working anymore. Because the only targets the new binutils 2.22 
support on solaris are elf_x86_64_sol2 and elf_i386_sol2.


Manually linking with: (after compiling with -Cn)

$/opt/local/bin/gld -melf_x86_64_sol2 -s -L. -o fpmake_packages link.res

is working!

Others have similar problems on gentoo:
http://archives.gentoo.org/gentoo-alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml


The problem is that on SmartOS the build machines and packages default 
to gcc47 with binutils 2.22.


I "fixed" it for me by compiling the compiler only on Openindiana 151a7
(older binutils) with the following  applied trivial patch, and copying 
the resulting compiler(s) (32/64) bit to the

target system. A full build for a 32 bit and a 64 bit fpc went well.

--- ./systems/t_sunos.pas.bak   2012-08-27 12:24:46.0 +0200
+++ ./systems/t_sunos.pas   2012-11-04 05:59:23.399713956 +0100
@@ -143,12 +143,12 @@
 }
 {$ifdef x86_64}
 const
-  gld = 'gld -m elf_x86_64 ';
+  gld = 'gld -m elf_x86_64_sol2 ';
   solaris_ld = '/usr/bin/ld -64 ';
 {$endif}
 {$ifdef i386}
 const
-  gld = 'gld ';
+  gld = 'gld -m elf_i386_sol2 ';
   solaris_ld = '/usr/bin/ld ';
 {$endif }
 {$ifdef sparc}


What are the options to fix this properly ?
I did not manage to get it working with the existing comand line 
options.I think it is needed to influence the -m option which fpc 
generates in "t_sunos", depending on an switch stating the usage of 
binutils greater than

a certain version.

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] extend fpjson with support for cardinal/qword

[Helmut Hartl]

I need to encode/transfer Cardinal and Qword values, which is currently 
not possible
 (at least for qwords) therefor i wanted to extend fpjson with support 
for that number types

and provide a patch.

bad idea ? / objections ?

thx,

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] extend fpjson with support for cardinal/qword

[Helmut Hartl]

Am 16.04.14 12:06, schrieb Michael Van Canneyt:


1. Cardinal should already be possible if you simply use Int64 to 
transfer them.
   There will be no type checking, but that is not a problem, we're 
talking Javascript subset here...

Yes.
2. Qword: we should check whether Javascript supports this range of 
value.

   If so, a patch would be accepted.
Javascript (standard) internally uses doubleprecision floating points 
(http://ecma262-5.com/ELS5_HTML.htm#Section_8.5)
to represent it's numbers so to some extent it's possible to represent 
that numbers, although arithmetic would behave

strange in that ranges :-)

JS  is only a subset of my usecase - I want to store such values in a 
text representation  as a backup format for our

database server, and do not want to use a string representation.
I'll send you a patch against current trunk when ready, so you can have 
a look.


thx,

 helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] ATTENTION - FPC BUILDFARM / HOSTING !

[Helmut Hartl]

Dear fellow fpc build-facility and VPN users,

You may have heard that FirmOS (my company) has ceased to be.
Currently I am working at a new startup named www.wolke.club,
and we have to rearrange the vm machine hosting.

I will try to host as many machines as possible, but we have to cleanup
(the mess) a bit and i need your help.

I also want to revoke unused OpenVPN acces to the buildfarm,
so you need to comment, on the google group to stay alive :-)

I have to make a disk reconfiguration on the host that the fpc vm's
live on. That means I have to backup and restore them to another
site. That is time consuming and cumbersome atm, and the machines
will not be reachable anymore until restored.

Furthermore I want to setup a Webgui so that the machines VNC console,
reboot and service could be done by the user(s) of the vm.
Therefor I need to create the Users = admins of the VM's.

Integration of existing machines to the interface is a bit tricky.

You will help me alot If you comment on the usage of the machines,
I only plan/want to restore needed machines.

So - What is needed / used  / Do we need new ones (win10) ?

The Lazrarus Forum/Mailinglist/Website KVM (lazarusteam32) is a special 
case.

I moved the KVM away to a new host some days ago.

!! If I get no feedback for particular machines / VPN Users
I plan to finally delete them !!

How to proceed?

For all It may concern, or who are willing to help, please subscribe
to the new google group: fpcwolke

https://groups.google.com/forum/#!forum/fpcwolke

I will try to answer service requests there.

As a reminder the current list of VM's

01dfc6a4-0d7c-401a-abce-ac431199fa45  KVM   512 stopped   openbsd32
17a9ead7-0e64-491e-905b-7be8f57c26f6  KVM   512 running   openbsd64
8dce2673-5461-4f4a-9020-78e0198bf1e1  KVM   512 running   
freelove_32
dc432b80-3ba0-43c5-b052-6611079ce2ee  KVM   512 running   
freelove864
f6ebc131-258b-4e48-89a4-5499646b0cb1  KVM   512 running   
freelove964

084d525d-40c5-47fe-8b97-b2de15ea1a52  KVM   1024 running   fpcfed32
5286709d-db5b-4eb9-8cf9-e3cf853ff99e  KVM   1024 running   
dragonflybsd

5c2959d7-4b38-4a1f-81db-3753f22ebeab  KVM   1024 running   netbsd32
61309ea0-6c47-4afe-a810-d0feaa93fc5e  KVM   1024 running   netbsd64
7aab24fd-a4ce-4192-9498-bc3523947497  KVM   1024 running   
fpcjenkins
7c652e8b-5e2d-4f84-bd2b-6b215e4482ae  KVM   1024 running   
openindiana
84810c1f-171b-447c-8f49-746e7e460805  KVM   1024 running   
freelove832
a2963da5-fa1d-4584-bf4c-1837f9149c62  KVM   1024 running   
fpchaiku32
b59a9558-7e0d-457c-b77c-b2e625bab272  KVM   1024 running   
fpcwinxp32

c5c6f718-0793-4fd6-af9e-db27ac2f5c0c  KVM   1024 running   fpcfed64
529130f8-e3dc-4bd9-8e0a-8b0951a99db9  KVM   2048 running   
fpcvista64
55893f44-72bb-47c2-8f92-23791e0e9ff7  KVM   2048 running   
fpcOpenSolaris

a0c87121-8656-4e82-bbab-77a6632f5736  KVM   2048 running   fpcwin764
c657f2ab-221d-43a6-9a24-ac8913bda285  KVM   2048 running   fpclin32
fa7de419-d85b-4e09-9d80-4c42e5937988  KVM   2048 running   
fpcORACLESolaris
058ef5cc-a62e-4faa-a94d-84c5cb327727  KVM   4096 running   
firmwin2008v2

ea5b9377-6d55-4bcb-9c65-f3bcbdbe73cb  KVM   4096 running   fpclin64
fcdf2316-161b-4454-b34c-d9fbce215d5b  KVM   4096 running   
fpcwin2008v2



I also bcc this mail to all known VPN Users.

 Thank you,

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Internal Compiler Error 2006122804

[Helmut Hartl]

When compiling my sources with the latest 2.2.1 fixes branch compiler
 
i get the following error:
 
imp_uci.pas(671,28) Fatal: Internal error 2006122804
 
in:

procedure TFOSInput.CleanEnvironment;
var v:variant;
begin
 Environment.StartEnum;
 while Environment.Next(v) do
 begin
  v:=Unassigned;
 end;
end;
-
 
Where "Environment" is some containerclasss of me.
The nearly identical code used in other units gives no errors.
This problem also did not occur with the 2.04 compiler from which 
i am trying to update to 2.2.1 ...
 
What does this error mean ? - Any ideas what causes this error ?
 
thanks,
 helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] Parallel Computing

[Helmut Hartl]

>I kind-of understand that... Borland tried to encapsulate the whole
threading thing in a  TThread class.  It made it easier and every bit
helps!  I simply thought I should >mention it here, so that FPC
developers know about this new API.  I haven't had a look at their API
docs yet, but thought if they come up with some neat idea not done 
>before, maybe FPC could borrow some of those ideas.  Piggy-back on
Microsoft's research findings.
>Regards,
>  - Graeme -

Hello,

If someone is truly interested in parallel computing - "lock free"
datstructures are what realy counts -
We program multithreades servercode with pthreads, NPTL threads, windows
threads now for around 6 years - 

(- and programm in assembler, c, c++, delphi, freepascal since 21 Years
(PDP 11,C64,C167,ARM uC,8051 uC,PIC uC,Amiga,x86)
- in all that time object pascal was the most effective language in
terms of error probability and turn around times ...)

It is a immense hassle to debug parallel  problems like deadlocks,
priority inversion and the like.
So for really cooperative porgramms the design phase on paper should be
taken into account even more.

The best solution for this problems by now is IMHO the lock free
paradigm - but has to be judged on the problem.
Several doctoral thesis, research findings, and papers for this exist -
if someone is interested - 
join the ACM, and the ACM Digital Library (http://www.acm.org/)
- and the technique is industry recogniced - you maybe don't know FirmOS
- (my firm) but you maybe 
know "Xen" (a cambridge project) which is now owned by Citrix, or you
maybe know "Half Life 2"
from Valve (which was computer game of the year, i think in 2006) - they
uses this techniques extensively.
(The Xen project, is IMHO the first project which uses this technique
practical and with immense success)
For Java and a were short primer/starting point read here:
http://www.ibm.com/developerworks/java/library/j-jtp11234/

Also "Open-MPI" sounds very interesting. But i fear a "no brain solution
API" for developers does not exist -
and without digging deeper into the problems of that field  someone
would have many hours of time searching 
bloody phenomenons and bugs 

So my personal findings are - nearly every technique "Microsoft"
invented, buyed or acquired was cancelled some
years later just to bind the customers by inventing something
revolutionary new, so a good stomach decision is
not to bind yourself too thight to this firm - 
(Access Runtime for Developers, WinG, DirectX Hardware support for sound
cards, the QoS Api (different for W2000, XP and Vista) 
 are all examples where i personally got a bloody nose running into a
wall :-(

I hope i could share some experience,

helmut


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] interfaces vs classes in dll

[Helmut Hartl]

>> One advantage is that it can be easely used on many languages, 
>> althougth the usefulness of that for ideintf is probably very small.
>>   

>I suppose you mean programming languages not spoken languages.
>But Interface is a Delphi language keyword. I don't see what this has
to with C or whatever.
>To interface Delphi Language "Interfaces" with other programming
languages additionally to the Delphi language construct a common ABI
needs to be defined.

>I do see that in Windows this is the case with a Delphi language
"Interface" assigned to a Windows "COM" interface, which "on the other
site" can have an interface to a 
>function written in any language (as a DLL, OLE thingy or whatever).
But as FP is supposed to be OS independent, the ABI between the FOP
program and "the other site" needs >to be done without Windows specs.
> -Michael

If one speaks of "interfaces", he could also mean it in the following
"computer science" relateted contexts:

http://en.wikipedia.org/wiki/Interface_%28computer_science%29

and

http://en.wikipedia.org/wiki/Design_Patterns (!)

The book about design patterns is a very valuable source of information,
and a good starting point for the
"interface" concept, beside CORBA, COM and Keywords.

Software Design using interfaces provides a big chance of reusing your
software, simplified tests 
(by just changing the class implemting the interface) and a clearer
contract between many programmers.

So the concept is also be Usable on its own without the link to CORBA,
COM, OLE.

ZEOS Database Libraries are based on the GoF Design Patterns,
extensively using interfaces, if someone wants
a practical implementation, that is FPC source code and not necessarely
windows centric

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] LockFree Queue algorithm

[Helmut Hartl]

Florian Klaempfl wrote:
> Michael Schnell schrieb:
>> 
> 
> The point is, it simply affects all processor. Its much better than
> an entercriticalsection but it is not only twice the time of a simply
> inc or whatever.

I want two give my two cent's too.

In the last 4 years, we developed a billing application
(fpc/linux/daemons) for VOIP calls.
The application bills in realtime cdr records generated from the telko
switch.
In one hour there are up to 15000 records to bill. In one month there
are estim. 5 million 
billed records in the database. (You must process estimately 7 Events, 
Start Call Event, Stop Call Event, Intermediate Timestamps to get one of
the 5 million CDR's).
(CDR := http://en.wikipedia.org/wiki/Call_detail_record)

In short: We must process a huge amount of data fast...

The application must find start and stop events in 7 different inmemory
data structures.
We use a multithreaded concept. A database reader, mediator threads
(finding start and stop)
,guiding threads (finding customers to call-id's),a rating threads
(making the price splitting a long the
time and destination axis), a db writing thread (writing results), a
fraud detection thread (checking per customer limits).
All threads use the same inmemory data structures.

The overall speed of the application is critical, as it makes a
difference if a re(rating) of a
month for 1 Telko customers producing 10.000.000 of CDR's on 1
phone bills takes 6 hours or
6 Weeks :-) (On a simple Multicore System)

We were (re)implemented the thing 3 times. The code is around 100.000
Lines.

Our conclusions for COMPLEX Algorithms are: (We read more often then we
write)

Involved Locking Structures:

A)-> TSemaphores / Critical Sections
Slow:-> Cause slow Writers block Readers too much
Deadlock Bugs -> if wrong Locking order -> Hard to debug.
Priority Inversion: High Priority operations gets blocked due to lock
held by
low prio thread. (Even harder to debug) 

B)->Multireader, Single Writer Locks
Faster:-> Due to the Multi Reader, Single Writer Locks
Much more Deadlock(!) Bugs, due to much more Readers.
Priority Inversion: High Priority operations gets blocked due to lock
held by
low prio thread. 

C) Lockfree Structures
No Deadlocks possible, No priority inversion,
No needless Waiting on Semaphores, if the Scheduler puts a Thread out of
the execution path
while in a Critical Section or holding a Lock.

Currently we have B) Running in Real World and C) Running in Testing.

C) Is not fully implemented due to large algorithmic changes. But in
prototypes and testing
Case C) is very promising because it is several times faster (not
serveral percents) than
Cases A and B).

The time spent on debugging A) and B) was enormous.

I think we all could need a good lockfree datastructure library for
Freepascal.
Our current implementation is not suitable as it don't cares for
multiplatform, and
64 Bit architectures and is too tightly bound with our internals.

But if someone is interested, we could work together to make something
new.
At least i have some links as starting points.

BTW: 
We are searching for a FPC/Delphi Programmer willing to work here in our
small team
in Graz/Austria.


helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] In FPC written FPC Debugger

[Helmut Hartl]

 
Hi,
 
When using Freepascal for various projects, tests and platforms, i tried
to identify what makes productivity bottlenecks for me and my team.
 
We currently mainly do daemon console apps with Delphi and Lazarus as
IDE for linux,
arm projects on NLSU2, and several WinCE Tests also performed well.
 
One of the main problems we face is the debugger gdb, wich makes us less
productive.
(unhandy, no real good pascal support)
 
So i am thinking about a freepascal debugger written in freepascal,
taking advantage of
the freepascal code/structures itself. Features should include a clean
interface, remote debugging ability
via net/udp (thinking about a rdp/vnc like server to control the
debugger) and or serial console and the ability 
to integrate it with a nice gui. (and other Features like Delphi's
debugger).
 
The advantage i see is that it should be buildable with fpc only, thus
working on all supported platforms from scratch,
maybe even suitable for mini OS Developments for embedded devices.

I am currently trying to study feasibility of such a project, and making
myself familiar with debugging techniques and
the DWARF(3) format. 
 
I have some general questions to the fpc team:
 
What do you think about the idea ?
Will some code of FPC be reusable ? (assembling / disassambling)
Any general ideas, proposals, negative emotions ?
What is the state of Debugging information symbol support ?
Are there any resources beside the source ?
 
thank you,
 
 helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] In FPC written FPC Debugger

[Helmut Hartl]

Paul Ishenin wrote:
> Maybe everybody will benefit in you boys will do 1 good bicycle
> instead of 3? 

At the moment i do not see the "good" bicycle to ride on.

> I see that Martin, Daniël and Marc are working/worked on one thing -
> debugger for fpc. And now we have 3 implementation based on gdb. +
> one start of native debugger.  
> 
> And we need:
> 1. abstraction layer to use gdb or native debugger or any other
> debugger 2. program interface which can satisfy fpc ide, mse ide, and
> lazaraus ide  

Well the abstraction layer should be one feature of the native debugger,
to make it usable for projects like lazarus, mseide etc ...
At the moment i don't see gdb supporting all necessary features
(e.g. gdb does not care for pascal enough).

> Is that more difficult than fixing/reimplementing already
> fixed/implemented things? 

I am currently trying to find pros and cons, feasibility.

Usecase: I want to develop and debug on an arm target nice and productive.
The arm target has udp, or serial console, but no display and has limited mem.
My vision is as follows load: The "fpc native debugger stub" to the arm board.
Communicate with the debugger, show a nice gui on linux/win. Do your job.
The same should(could) hold for windows, linux, macos too ...

The reality now would be: 
How do i find in internet or compile the gdb
for my target ? (2 weeks) Deal with linking (2 days), Deal with libraries (3 
days)
,deal with makefiles (1 day), deal with c code (1/2 day),
deal with memory shortage, deal with the poor gdb pacal support, 
deal with the poor gdb interfacing support. (priceless ;-))
Then start doing the job with limitations ...
In lazarus i have gdb/interfacing related crashes every one debugging run 
(making console apps for linux).
What i want to say in my firm i need 3 "experts" to set up the whole thing.
So why should i not start the project in c(++)?
Because i can write and read pascal code after 1 bottle of wodka :-)
And i vomit reading c code, as the language drives every user to win an 
obfuscation contest,
including me when i used it for firmware projects.

That is my motivation ...

PS: i did not had a look marc weustinks code, nor knowed about it, i will have 
a look soon ..

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] NetBSD / PPC (Xillinx 405)

[Helmut Hartl]

Hi to all,
 
I want to do some programming for a embedded system:
(Port our SIP/RTP Stack to some embedded system)

System is:

NetBSD 3.0  #1570: Tue Aug 15 15:08:31 CEST 2006 TG Board
total memory = 65536 KB
avail memory = 46160 KB
plb0 (root)
cpu0 at plb0: 200MHz 405EP (Revision 9.80)

 
This is a VoIP Box running under NetBSD with a PPC Architecture.
(ibm405 core embedded in Xilinx Virtex {2-Pro, 4 FX} series FPGA)

Can you give me some directions ?

Our sip stack is commercial/closed source at the moment, but if i win
the project,
i can do some porting of libraries/targets if necessary and give that
work back of
course ...

Thank you,

 helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] NetBSD / PPC (Xillinx 405)

[Helmut Hartl]

ik wrote:
> I'm not sure what you are looking for.
> I started binding a osip to FPC but i didn't had the time (and will)
> to finish the binding. 

Sorry, i will clarify what i want to do.
-
My firm is writing software for telco-carriers.
VoIP Solutions, billing solutions, firmware etc.
We traditionally programmed in delphi, fpc, c and c++.
I have a carrier grade sip/rtp stack written in fpc
for linux and windows. Lib osip is nice but has neither the
features nor the performance needed here.

Now i have to answer a tender (rfq/rfi). If i win my
team and i have to port the applications to an embedded box. 
(powerpc/netbsd embedded system)

I am not willing to port our work to c++.
(We are currently try to kill all old c firmware projects as
object pascal / fpc gives us a clear market advantage through
cut down turnaround times and less error prone code.)

If i win the tender our sip stack will maybe run around 100.000 
Voip/Gateway/CSTA boxes. They have to be supported with a timeframe
for around 5-8 years.

So my questions are in detail:

What is the state of a netbsd-powerpc port ?
What is done ? What has to be done ?

If we can use fpc for development my firm can support the
fpc project by supporting a/the netbsd-powerpc port.
Also we plan to release some basic datastructures libraries
into public domain.

Thank you, helmut

> 
> On Tue, May 20, 2008 at 2:20 PM, Helmut Hartl
> <[EMAIL PROTECTED]> wrote: 
>> Hi to all,
>> 
>> I want to do some programming for a embedded system:
>> (Port our SIP/RTP Stack to some embedded system)
>> 
>> System is:
>> 
>> NetBSD 3.0  #1570: Tue Aug 15 15:08:31 CEST 2006 TG Board total
>> memory = 65536 KB avail memory = 46160 KB plb0 (root) cpu0 at plb0:
>> 200MHz 405EP (Revision 9.80) 
>> 
>> This is a VoIP Box running under NetBSD with a PPC Architecture.
>> (ibm405 core embedded in Xilinx Virtex {2-Pro, 4 FX} series FPGA)
>> 
>> Can you give me some directions ?
>> 
>> Our sip stack is commercial/closed source at the moment, but if i win
>> the project, i can do some porting of libraries/targets if necessary
>> and give that work back of course ...
>> 
>> Thank you,
>> 
>>  helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: Multi threading support was Re: [fpc-devel] Russianlocale information not compatible withFPClocale variables

[Helmut Hartl]

Florian Klaempfl wrote:
> Micha Nelissen schrieb:
>> Florian Klaempfl wrote:
>>> procedure p;synchronized mycriticialsection;
>>> 
>>> Any suggestions about doing it better?
>> 
>> How to avoid deadlocks?
> 
> Indeed, I'am open to any suggestions :) Just an idea: maybe a global
> call tree analysis with a call tree attributed with critical section
> information can find potential deadlocks?  

Just some additional testing info and things to think about.

*) Performance of non granular locks is poor.
*) Creating 50K+ of lock instances makes the OS behave strange,
 so to fine granualer does not help either :-)

Simplest working Deadlock Avoidance strategys is:

Lock all resources at the same time in the same order.

Thread x
 LOCK A
  LOCK B
   LOCK C
 ... Work 
   UNLOCK C
  UNLOCK B
 UNLOCK A

Thread x
 LOCK B
  LOCK C
   ... Work ...
  UNLOCK C
 UNLOCK B

This way deadlocks are impossible.

As this is sometimes not possible - we use deadlock detection in our
software.
(as classical database servers are doing it :-))

I describe it brief:

Everytime we lock in a thread we post a event to an non-blocking queue
(Michael&Scott),
similar on unlocking. The MS Queue is fast and does not block. At the
other side we
Detect the deadlocks by time (like a asynchrounous logger).
All our Locked operations are designed to take a small amount of
time (say some milliseconds). When we detect a nonpairing timedifference
of say one second, we found the deadlock and have to correct the code.

This is a debugging tool, wich does not save design time. But saves huge
amount of time
searching for deadlocks.

IMHO a full graph-theoretic cyclic redundancy check would be to much
waste of time - inefficient.

Another aproach would be STM. (software transactional memory).

For theory about locks: 

Hector Garcia Molina, j.Ullman, J. Widom / DATABASE Systems the complete
Book.

Or hardcore: http://www.cs.rochester.edu/~scott/

Greets,

 helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: Multi threading support wasRe:[fpc-devel]Russianlocale information notcompatiblewithFPClocale variables

[Helmut Hartl]

Boian Mitov wrote:

> As you can see there are obvious scenarios where the granularity
> approach seems to be the only reasonable one. 

I think you misunderstood me:
I wanted to say:

*) Maximum granularity gives maximum performance, but as always there is
a tradeoff.
*) Problems come in if you have DIFFERENT resources to lock and are not
able to maintain the right 
   ORDER of locking, in the timeschedule.

Locks are well researched but yesterdays technology, and there is no
need to reinvent the wheel,
because there are exising published DEADLOCK Avoidance and DEADLOCK
Detection Algorithms available 
for decades ... (Start here http://www.acm.org/sigs) 
(So IMHO best would be to use existing and mathematical profen
strategies)

Please take a look at the papers at: http://www.cs.rochester.edu/~scott/

New directions are STM and Non Blocking Algorithms.

I want not to criticise, understand your design, nor i want to make it
better :-)
Just some state of the art research info - read it or ignore it - what
ever makes you happy ...

There are much smarter people then we are maybe, at least for me this
holds,
inventing new wheels ...

Greets,

 helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: Re: [fpc-devel] On code cleanup

[Helmut Hartl]

Von: Jonas Maebe 
Gesendet: So 03.05.2009 15:01
An: FPC developers' list ; 
Betreff: Re: [fpc-devel] On code cleanup
> 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.
> 

I started a test with a simple generic red-black tree implementation:
http://fpcfun.firmos.at/bin/view/Freepascal/GenericRedBlackTree
played around with it a bit and put it in our commercial codebase
dropping 12 different red-black tree implementations units with nearly 
the same code.

I am happy with the generics implementation at the current state
it is practically usable! 

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

[Helmut Hartl]

Am 20.05.10 01:27, schrieb Graeme Geldenhuys:

On 20/05/2010, Marco van de Voort  wrote:
   

Yeah. Studying means neither.
 

Well lets see: I have written numerous technical papers/articles on
the subject, been using it in commercial software for almost 10 years
and presented technical and training workshops on the subject. I think
I have a good knowledge on the subject.

   

  And while Michael advocates he has thought long about it, so have I. We even
  discussed about TStringlist and the sad way it plugs into the VCL/LCL in the
  car for at leat more than an hour when we drove to Muenchen the last time.
 

Code evolves over time - that's a fact. Refactoring code is also a way
of life (or at least should be) for developers. The only constant in
code is change! Introducing Observer into the classes unit is simply
code evolving - fulfilling a new software requirement that did not
exist before


*EXPLICIT WARNING : "ACADEMIC VIEWPOINT"*
 (this means worthless in practice :-)) (or I have read many books,
 understood something and I am able to impress
people with wrong mathematical proofs)

Be prepared to laugh - or think about your sense of humor.

Life flows - evolution is good (at least for they who are on the winning 
side),
reading books opens the mind (alcohol too - but little (own) childs the 
most).
Patterns are super -  but not if you are coding something performance 
critical.
Extra stuff that makes things easier is nice - I always want my VAN to 
be a Truck

when I am transporting something AND to be a bicycle when searching for a
parking lot.

While coding OpenGL/Physics I would like to hang everybody polluting the 
base,
while coding our boring business stuff  multitier bloatet database 
applications
I would like the observer. (We did databases long enough now and 
switched to

something more fun)

Now I contributed a whole bunch of unrelated feelings based stuff to 
this discussion,

trying to match the argumentative style so far. :-)

Isn't it better to to ask the right questions (at least some) before 
trying to swing opinions

(with brutal - but - wrong directed force) ?

1) Who decides what comes into the base ?
2) What If I am not able to respect this descision ?
3) Do I really need that red car toy on every case ? (eeh.. skip this)
4)  Is there a summary of the discussion that cares about more sides of 
the problem ?

  a) Performance Point ?
  b) Memory Usage point ?
  c) Embedded Usage ?
  d) Crossplatform Usage ?
  e) Compatibility ?
5) When is the RIGHT TIME to do that discussion ? (I certainly doubt 
that it is now, 2.4.2)
[To understand point 5 fully it may be good to be older than 25 
years ;-)]
6) Am I speaking for my personal pleasure or am I able to consider the 
points mentioned under 4 ?

7) Is it good to (often) block people who want to achieve something ?
8) Is there a solution who satisfies all parties to a certain degree or 
are we really to dumb to find it ?
9) How to make such a change at the right time, and give more people the 
ability to think about it
- or give them the time to not think - not test and live with the 
consequences ?


The result should be a summary with pro's and con's and the ability to 
take a proper and thought

through decision.
(Maybe a wiki page with a summary table and the ability to vote ?
- If this would be a "democratic discussion" of course (see point 1) -

Rather than "Who has the longest ?"

 (Expierience in reading, talking, teaching of course
- please forgive my english - I am not a native ;-)
 It should have read "... rather than who has the most "... ?)

Helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

[Helmut Hartl]

Am 20.05.10 10:29, schrieb Graeme Geldenhuys:

Joost van der Sluis het geskryf:
   

1) Ignore Marco and implement it any way. I think you have just as
much say as Macro on what goes into the FPC.
   

thread yet. But here you are going too far. Way too far. Imho we don't
 

Well my statement was true wasn't it? Michael's opinion should count too.
Why must Marco always get his way? Why must Marco always disagree with all
new proposals.

Short enough?
   

I personally met, talked to, and respect Michael and Marco (SYSTEMS/Munich).
 I agree to Joosts statement.

Can someone please explain to me what the change to TObject will do to 
my STM implementation ?

(Relying on memory layout, lockfree algo's and size ... )

Beware you need to make your self familiar with : 
http://www.cl.cam.ac.uk/research/srg/netos/lock-free/

at least: http://en.wikipedia.org/wiki/Software_transactional_memory
If you want to give statements with a clue - (and after that you still 
cannot answer my question).


A redisign of classes is ok as it implies the chance to adobt code to it.
But fundamential changes in an stability release ?

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Interface delegation fix: backport to FPC 2.4.2 ...?

[Helmut Hartl]

Am 20.05.10 11:01, schrieb Michael Van Canneyt:

There is no change to TObject.

Thank you very much for your clarification.
That satisfies my personal needs full.

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] HEAP Memory Manager BUG

[Helmut Hartl]

Hello,

We are trying to port a Project around 220.000 Lines of code from
Delphi/Kylix to FPC. Primary it runs :-), our main problems were Variant
Support (Various conversions behaving not as in Delphi/Kylix). We made an
own Variant Manager (to not break the existing one ) which is closer to
Delphi, we would like to contribute if we are done with it.

The biggest problem still not solved is a BUG in the heap memory manager
wich causes various SIGSEGV in various pieces of code i reported it
yesterday as BUG 4189. (http://www.freepascal.org/bugs/showrec.php3?ID=4189)

I want to supply additional info:

Program test;
var s:string;
begin
 setlength(s,3);
 setlength(s,655360); -> CRASHES WITH SIGSEGV  
 writeln('OK'); 
end;
Compile with: fpc -Sdh test.pas

Program crashes under linux and win32 with current SVN 2.1.1
Problem seems to be in:


function SysTryResizeMem(var p: pointer; size: ptrint): boolean;

We "FIXED" it by changing function to:

function SysTryResizeMem(var p: pointer; size: ptrint): boolean; var
  pcurrsize,
  oldsize,
  currsize : ptrint;
  pcurr : pmemchunk_var;
begin
  SysTryResizeMem := false;
exit;  <--- Don't Resize
 .

Thanks for the good work,

Helmut



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] 2.0.3 AV's (ZEOS SVN)

[Helmut Hartl]

> Where can I find ZeOS with MySQL 5 support ? The alpha of 6.5.X on
> sourceforge only contains 4.1 support, and that even does not work
> with Delphi... 
> Michael.

Development SVN is now at: 

svn://www.firmos.at/zeos  (it's still beta)

Lazarus installation is not fully ready by now ... 
we use it through lazarus, but not installed in the ide,
creating the objects by hand.

Helmut

PS:
You can contact me per Mail if you have specific questions.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] 2.0.3 AV's/ BUG 4999 / BUG 5000

[Helmut Hartl]

Hello,

> It has nothing to do with the memory manager? It's a bug in the fastmove
> routines probably.

Many thank's for fixing the BUG 4999!
I postet the follow up as 5000 now.

As with 4999 in 2.0.2 it works, 2.0.3 crashes.

helmut

 Source

program fpc203fish_2;
{$mode objfpc}{$H+}
uses  Classes,zstream;
var cz:TCompressionStream;
 m:TMemoryStream;
 s:String;
pc:PChar;
 i:integer;
begin
 m:=TMemoryStream.Create;
 cz:=TCompressionStream.Create(TCompressionlevel(2),m);
 s:='123123sdfjkysdjfklsdn3m';
 for i:=0 to 10 do begin
  s:=s+s;
 end;
 pc:=pchar(s);
 i:=length(s);
 cz.Write(pc^,i);
 cz.Write(i,sizeof(i));
 cz.Write(pc^,i);
 cz.Write(i,sizeof(i));
 m.SaveToFile('test');
end.  

 Output

EAccessViolation : Access violation
$0807141E INSERT_STRING, line 489 of zdeflate.pas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] MemoryLeak with AS Operator

[Helmut Hartl]

Hello,
In testing upcoming 2.0.4 release i found an incompatibility/memory 
leak which is present in fpc versions greater 2.0.2.

I tested faulty against

2.0.3 fixes svn
2.1.1 head svn
2.0.4 rc2 branch svn

Working OK with 2.0.2 Release.

The following code runs differently on compiler versions greater 2.0.2

function TTestCollection.Add(const 
 Item:IInterface): Integer; begin
 
FList^[0] := Item as IInterface; // (1)
//FList^[0] := Item;  // (2)

end;

(1) => Original Code  No Memory Leak with FPC=2.0.2 but with > 2.0.2
(2) => No Memory Leak 

Reported with a demo program as Bug 7174.
http://www.freepascal.org/mantis/bug_view_advanced_page.php?bug_id=7174

I post this to the list, as i spent the whole night on searching this
bug 
and maybe it helps someone out.

Greets,

helmut


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] MemoryLeak with AS Operator

[Helmut Hartl]

Hello,

can anyone give me a hint where to search for the "AS" compiler problem.
We tried to workaround that in ZEOS Code and gave up, as we are not able
to find all Memory holes and pinpoint them.

With 2.02 we have the problem that the TDataset has different behaviour
than in Delphi (Datetime).

No we are making production code with a self patched 2.02 release
(TDataset from 2.04) but that's no good solution.

Thanks,
helmut



 
> Hello,
> In testing upcoming 2.0.4 release i found an incompatibility/memory
> leak which is present in fpc versions greater 2.0.2.
>  ...
> The following code runs differently on compiler versions greater 2.0.2
> 
> function TTestCollection.Add(const
>  Item:IInterface): Integer; begin
> 
> FList^[0] := Item as IInterface; // (1)
> //FList^[0] := Item;  // (2)
> 
> end;
> 
> (1) => Original Code  No Memory Leak with FPC=2.0.2 but with > 2.0.2
> (2) => No Memory Leak
> 
> Reported with a demo program as Bug 7174.
>
http://www.freepascal.org/mantis/bug_view_advanced_page.php?bug_id=7174
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: AW: [fpc-devel] MemoryLeak with AS Operator

[Helmut Hartl]

Hello Joost,

Maybe I should be a bit more informative:

We (I) am the currently technical maintainer of ZEOS Database Library.
We donate some of our work to the ZEOS DB Library.

We are currently stabilizing it and using it in a 
carrier grade billing system for a VOIP Telco Provider.

We have a 7/24 SLA with an uptime guarantee of 99,9% per month
for the daemon applications. (Linux Server side built with Lazarus and FPC)
The client side on windows is crossplattform and is built with Delphi. 
You see we have a strong belief in Object Pascal. :-)

We closely follow the SVN Versions of FPC so our interest is
to help FPC to be and to become ultra stable.

In our testsuite test we saw now that there is a bug in
compiler/rtl memory management. We pinpointed the 
problem with a demo app and bug report. 

Our interest is to help fixing it as we won't want to search
and change our code in about 90.000 lines of code, nor we 
wont want to make hybrid compiler versions as we do at the moment.

We regularly test our whole code against the fixes branch and
the 2.1.1 branch and use a hybrid 2.0.2 + dataset patches
for our release.

A new ZEOS library with crossplattform support for 
MySQL5, PostgreSQL8 and others and FPC compatibility
is directly depending on the ability to compile it with
a compiler greater 2.0.2.

In the Moment we have the option to release next ZEOS 
recommending a nonworking 2.0.2 (Dataset Problems) or
recommending a non working (memory leaks) other version.

And in the moment there exists none greater 2.0.2, which runs our 
testsuite without mem leaks.

As a RTL memory leak is a blocker for every serious application
developer, all FPC users will benefit from a fix.

So the question to IMHO is simple:

1) We all have no time :-)
2) Someone changed something with the AS operator or memory management.
3) The same one will (hopefully) know that his change possibly made some side 
effects.

If that "someone" reads this, I hope I triggered him to say something
like:

1) Ah - I know - I fix it.

OR

2) Ah - I know where the problem (sourcefilename) will be, but I have no   time 
to do something about it. 

In case 2 I hope he will say "Hey I have no time but the problem is serious 
just have a look at  xxx.pp "

Then after SVN usage there will be the possibility to fix something, quicker 
then searching in the dark...


Thanks,

Helmut


----
Dipl.- Ing. Helmut Hartl 
Head of Development
FirmOS Business Solutions GmbH

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:fpc-devel-
> [EMAIL PROTECTED] Im Auftrag von Joost van der Sluis
> Bereitgestellt: Mittwoch, 26. Juli 2006 12:44
> Bereitgestellt in: fpc_devel
> Unterhaltung: AW: [fpc-devel] MemoryLeak with AS Operator
> Betreff: Re: AW: [fpc-devel] MemoryLeak with AS Operator
> 
> 
> > With 2.02 we have the problem that the TDataset has different behaviour
> > than in Delphi (Datetime).
> 
> That's easily patchable. And idscussed in this list a few times. Just
> return a TDateTime in the GetFieldData.
> 
> > No we are making production code with a self patched 2.02 release
> > (TDataset from 2.04) but that's no good solution.
> 
> Why not? It's the only one. There are several other changes in 2.0.4
> that you need to get ZEOS working properly.
> 
> And as long ZEOS isn't released, you can safely build it against a fpc-
> version that isn't released. I guess that fpc 2.0.4 will be there long
> before the next ZEOS release.
> 
> Joost
> 
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: AW: AW: [fpc-devel] MemoryLeak with AS Operator

[Helmut Hartl]

Hi,

> That mem-leak bug, do you have it's bug-number? And do you think it's
> serious enough to block the release of 2.0.4?


I testet faulty against fresh built 2.1.1, 2.04 RC 2 Tag and fixes
branch.
Maybe I am doing something wrong ... but if someone confirms:

http://www.freepascal.org/mantis/bug_view_advanced_page.php?bug_id=7174

as faulty then I would block the release.
But of course that only represents my opinion - 
I am not able to prognose the relevancy of the bug to others.
If you have commandline tool written in fpc you will maybe
not even notice a problem...

greets,
helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: AW: AW: [fpc-devel] MemoryLeak with AS Operator

[Helmut Hartl]

> 
> I'll look into the bug report the next days.
>

Hello Florian,

Thanks for fixing the first bug, but
i am afraid, that there exist other memory related problems in 
FPC 2.0.3 (fixes branch). Our applications are not memory stable.
(Related Bugs 7174, 7209)

I am in the moment not able to reproduce the problems in a 
small non ZEOS dependent app, but as the program is memory
stable with delphi and fpc 2.0.2 i think of an bug in fpc.

If memory is acquired through:

"Getmem(x,size)"
and Freed through
"Freemem(x,size)"

I have a leak because Getmem reserves occasionally
more mem as specified in size?

Is 
"Getmem(x,size)" Freemem(x) correct?

I tried to check the program with valgrind 3.2

But valgrind 3.2 brings weird errors (garbled strings), when
i compile with something above 2.0.2 stable. (Tested 2.0.3 and 2.11).
With 2.0.2 Valgrind output is ok - but the program also :-)

Is valgrind support broken or do
I have to do something beyond setting the valgrind compiler switch?

Any ideas ?

For the brave and interested I include the 
test project, Makefile & settings.

Required: Linux, i386, fpc 202 fpc 204, mysql 5

Steps:
1) svn co svn://firmos.at/zeos/trunk
2) make a link to it under /z 
   (/z -> /svnwork/zeos/trunk/)
3) unpack the demo
4) make a link from fos_fpc to testing fpc_version
   (fos_fpc -> /usr/local/lib/fpc/2.0.2/ppc386)
5) execute make zeos_memhole2
6) Change the Database,Host,User ... in the sourcecode
7) Change the table name in the SQL to some table in your database
8) start the program / you see the leak 
   (depending on fpc version)

Maybe some config files must be adjusted.

Greets,

helmut 


zeos_mtest.tar.bz2
Description: zeos_mtest.tar.bz2
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] Lock Free Memory Management

[Helmut Hartl]

> >>
 > >> Does the Codegenerator already support this?
 > >> Are they portable?
 > >> How would you suggest to implement such operations platform
 > independent?
 > >
 > > I don't think this is possible, as it depends on processor support
?
 > 
 > I think it can be implemented easily using
InterlockedCompareExchange,
 > no?

Yes it will be but to my knowledge there exists no platform independent
version of InterlockedCompareExchange in Free Pascal...and even none for
64Bit.

For a new memory manager there must be a lowlevel function supporting
this.
Also this operation must not be reordered/optimized by the compiler.

The operation should preferrably be a
InterlockedCompareExchangePointer()
wich always does the right thing :-) depending on architecture ... 

For the interested ...

http://en.wikipedia.org/wiki/Compare-and-swap

http://groups.google.de/group/comp.programming.threads/browse_frm/thread
/d062e1bfa460a375/3461ab7dd927a6ec?group=comp.programming.threads#3461ab
7dd927a6ec


helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] bug 07281 / mem leak / interfaces

[Helmut Hartl]

Hello Developers,

 

Are there any news regarding bug 07281?

 

I think this bug is closely related to bug 7209.

 

The problem is that it is not possible with any
compilers greater 2.0.2 to compile

a memory stable program that uses interfaces.

 

We would like to release Zeos Dataset components for
2.0.4, but as Zeos make intensive

use of interfaces, it is not possible to make a
program that runs memory stable with it. 

 

Please help us.

 

Zeos is a mature set of database components allowing
access to e.g. 

MySQL, PostgreSQL, Firebird/Interbase, Oracle with
the same set of components.

 

 

Bug 07281 contains a heap trace and short program
showing the problem.

 

Greetings, 

 

helmut






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] ZEOS Contribution Offer

[Helmut Hartl]

I speak in the name of the ZEOS Developers.

We want to contribute to the FPC Project, in the form
that we

deliver a FPC usable Version of the ZEOS DBO.

 

If you don’t know ZEOS by now, it is a set of
mature database components

usable visual or nonvisual, wich interface to SQLite,
MySQL, 

PostgreSQL, Interbase, Firebird,Oracle and others.

Normally the latest versions are supported.

 

Currently we are preparing the 6.6 Version. (beta
cycle).

We will change our licensing terms to make it LGPL
with the

FPC / Lazarus static linking exception.

The library works fine for Delphi’s,
FPC under Windows and Linux.

 

Currently only SVN versions and snapshots are usable,

But the Beta Cycle starts soon.

 

If someone is willing to integrate/maintain the
sources into next fpc version,

maybe we get another set of databse components that
work out of the

box with FPC/Lazarus.

 

As ZEOS is quite huge and we are all short of time
(as everybody is :)

we are searching for testers, developers and users if
someone is interested  …

 

The forum is reachable under

zeos.firmos.at

 

Please tell me your thoughts.

 

Thanks,

helmut

--

helmut dot hartl at firmos dot at

 

 






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] ZEOS Contribution Offer

[Helmut Hartl]

 > The upshot of all this is that we don't need to include all packages
 > in FPC by default, making the maintenance burden smaller for the core
 > team. All you would need to do is create one small driver file,
 > and the rest will be automated for you.
 > The central repository access will also be automated. 
 > Michael.

That sounds pretty cool.

Helmut.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Bug 0007281 / MemLeak with interfaces

[Helmut Hartl]

Is it possible to backport the resolution of 0007281 from
head to fixes branch?

 

Best Regards, helmut






___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] Bug 0007281 / MemLeak with interfaces

[Helmut Hartl]

> It is not usefull to do. There won't be a new release anymore from the
> fixes branch.

Your statement concludes that 2.04 is not usable for production
environment.
-> Except you do not use interfaces - or write programs which are only
commandlinetools, not expected to run for some time.

This also means we cannot release Zeos Database Objects for Freepascal,
which is quite sad. We cannot recommend an average ZEOS user what to do
to
get a memory stable and usable compiler environment.

FPC 2.0.2 is not usable -> Dataset has bugs. (but is memstable)
FPC 2.0.4 is not usable -> Dataset is OK (but it's not memstable)
(A real world deamon app with about 80.000 lines of code runs about 2
hours,
before crashing the machine.)
FPC 2.1.1 is not usable, as it is the development branch.

For our company it's not a problem we use a patched 2.0.2.
But in our forum we have lots of request for a stable environment.

So what we have done is what the FPC site recommends:

>Download Daily Update of Release Tree (version 2.0.x)
>These snapshots contain the latest bug fixes, without any major new
>feature. This should be more stable than the development snapshots (and
>even the last official release), but there is still no guarantee that
these >snapshots are bugfree.

We have 1446 registered users in the zeosforum and many of them are
using/ starting to use freepascal apart from delphi & kylix.

Maybe you can give me a recommendation what to say to them?
I personally don't want to say them "It's not usefull to use fpc"

It's maybe even usefull for FPC people as we offered to contribute the
whole ZEOS Library with the Lazarus/FPC modified LGPL license.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: AW: [fpc-devel] Bug 0007281 / MemLeak with interfaces

[Helmut Hartl]

Florian Klaempfl schrieb:

 > I merged the patch but help us to test 2.1.1 as much as possible
based
 > on the revisions known to be good
 > (http://www.freepascal.org/wiki/index.php/Tested_Unstable_Revisions)
so
 > we can get 2.2.0 out asap (head is currently broken due to heavy
 > rewrites).

Thank you very much form merging. -> 2.0.4 Fixes looks better now... :-)

 > The perfect solution for your users would be if you run daily
regression
 > tests with trunk and tell users which revisions work good with Zeos
 > (currently 5191 is a good bet) and tell us if you get worse test
results.

I found a very strange memory leak occurring with 2.1.1.

Bug is: 0007776 / FPC Revision 5191
http://www.freepascal.org/mantis/view.php?id=7776



program zeos_memhole2;
{$mode objfpc}{$H+}

Function dlopen(Name : PChar; Flags : longint) : Pointer; cdecl;
external 'dl'; //A

Type
  TTest=class
   function Find(const Value:String):TTest;
  end;
 { TTest }
 function TTest.Find(const Value: String): TTest;
 // var i:integer; //C
 begin
  if (Length(Value) > 1) and (Result <> nil) then begin
   result:=Find(Copy(Value, 2, Length(Value) - 1));
   // x:=Find(Copy(Value, 2, Length(Value) - 1)); // B
   // result:=x;
  end;
 end;
 var TT:TTest;
begin
 TT:=TTest.Create;
 TT.Find('AA');
 TT.Free;
end.  


Comment Line //A or uncomment line //B or //C 
and the problem is "fixed" :-)

helmut


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

AW: [fpc-devel] Bug 0007281 / MemLeak with interfaces

[Helmut Hartl]

> If anybody is willing to do so, he'll get svn write access so feel
free
> to volounteer ;)

I am maybe interested in doing so - if I am bright enough to do it. :-)

helmut
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] BlackFin

[Helmut Hartl]

 > Michael Schnell schrieb:
 > > Florian, Thanks a lot for discussing this !

Big thanks from me too!

 > Coding the compiler part isn't that hard. I can do this, I 
 > did the initial arm port within a few weeks. The more 
 > annoying part is doing the debugging and find the things 
 > being broken.

We have to start a research hardware project end of may, and
are also in the middle between choosing an ARM/FPC way or
a blackfin/non fpc way. This discussions opens a new possibility, which
I would gratly favour. We could help to debug a blackfin port,
and i would also donate some money for a development board, if that
helps.

Helmut

--
Helmut dot hartl at firmos.at

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] BlackFin

[Helmut Hartl]

 
 > 
 > Big thanks from me too!
 > 
 >  > Coding the compiler part isn't that hard. I can do this, 
 > I  > did the initial arm port within a few weeks. The more  
 > > annoying part is doing the debugging and find the things  
 > > being broken.
 > 
 > We have to start a research hardware project end of may, and 
 > are also in the middle between choosing an ARM/FPC way or a 
 > blackfin/non fpc way. This discussions opens a new 
 > possibility, which I would gratly favour. We could help to 
 > debug a blackfin port, and i would also donate some money 
 > for a development board, if that helps.
 > 
 > Helmut

Sorry, i forgot to mention a valuable source of information:

http://www.bluetechnix.at/

 
 --
 Helmut dot hartl at firmos.at
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] POSIX threads and classes

[Helmut Hartl]

>  > fpc 2.0.4, opensuse 10.2, glibc-2.4-31.1

You may try this version of your program 
-
program Project1;

{$mode objfpc}{$H+}

uses
 UnixType,pthreads;

type

TCondv = class
private
   Cond : UnixType.pthread_cond_t;
   CAttr : UnixType.pthread_condattr_t;
public
  constructor Create;
  destructor Destroy; override;
end;

{TCondv}
constructor TCondv.Create;
begin
  pthread_condattr_init(@CAttr);
  pthread_cond_init(@Cond, @CAttr);
end;


destructor TCondv.Destroy;
begin
  inherited;
  pthread_cond_destroy(@Cond);
  pthread_condattr_destroy(@CAttr);
end;
{TCondv}

var
  obj1 : TCondv;
  obj2 : TCondv;
begin
  obj1 := TCondv.Create;
  obj2 := TCondv.Create;
  obj1.Destroy;
  obj2.Destroy;
end.   
---


I had bad experiences with types differently declared in pthreads and
UnixTypes.
Namely the following:

In pthread:

  pthread_cond_t = record
__c_lock: _pthread_fastlock;
__c_waiting: _pthread_descr;
  end;

In UnixType: (ptypes.inc)

  pthread_cond_t = record
__c_lock: _pthread_fastlock;
__c_waiting: pointer;
__padding:
array[0..48-1-sizeof(_pthread_fastlock)-sizeof(pointer)-sizeof(clonglong
)] of byte;
__align: clonglong;
  end;


A call like: i:=pthread_cond_timedwait(@FSignal, @MMutex,@tim);
Fails with the first version (EINVAL), but succedes with the second one.


HTH,
 helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

RE: [fpc-devel] what fpc is good for?

[Helmut Hartl]

> There is nothing in this article we can consider, for starters because

> it does not contain any proposals.

It even tries to give directions on how to and how to not use a tool. 
Normally a tool proves itself usefull by being usefull in some way for
someone. Now we got a ultraflexible, even changeable and adoptable tool.
So why do we sit down and cry about the tool and give directions what 
to do with it and what not. Is it too expensive ? Can't we change 
it and make everything better what we want ? Or do we want that the
tool magically adopt to our wishes without further work, even 
if that is not that what the tool constructors intended ?

"Everyone is able or limited to see only what he can imagine."

So - What is FPC good for?

After reading that i just have to state my opinion too by
providing a so called "success story".

I program since i am 10 Years old - now i am 33 - so
i have seen and tried many different things.

I hacked firmware in assembler for microcontrollers - 
=> 2 Weeks for 1000 Lines of Code tested, understood and working.
I programmed firmware in C for microcontrolers used on hundreds of
Devices. => 1 Week for 1000 Lines of Code tested, understood and
working.

But for my "hobbies" i always programmed in Pascal. And on 
an good day i program 1000 Lines of code understood, tested and working
in 
just 1 Day. 

So after studying informatics me and a colleague made the hobby a
profession.
We develop programs, projects and solutions WE consider attractive using
delphi and freepascal. Where the amount of freepascal solutions is 50%
and rising.

So what do we do with it? => Everything that is imaginable.
Server applications on Linux using NPTL and servicing 1000 Clients
simultanousely.
Embedded solutions, databaseapplications and GUI Applications,
Middleware.
(We run a carrier grade Billing Solution for a Cable Net VOIP/SIP
Provider here in Austria,
using Freepascal, ZEOS, and PostgreSQL)

So what is FPC good for ? 

-> Maybe to make a big bunch of money using it. (we do)
-> Learn programming - look as deep into the sources as you like, even
the compiler.
-> Program a Scene Demo in OpenGL, make a Game, or write a "Delphi
Killer" like Lazarus.
-> Waste your time with Web Applications ... :-) (just to make some
emotions too)
-> It enables that our firm with 4-5 Programmers sucessfully competes
with firms employed
   10-20 programmers.

*) Object Pascal is a great Language allowing to make readable,
understandable,
 small, fast and efficient code, if you provide the skills to use it.

*) Freepascal is (IMHO) after the GNU C++ environment the most flexible
free compiler
   providing a useful and professional framework, for a variety of
architectures.

Don't ever press FPC or Lazarus in a scheme, as it clearly depends on
your skills,
what you make out of it. It is even suitable to make an OS.

I am humble, and gratefull that FPC is here allowing me to make my hobby
my profession,
to earn money and to spend more time with my family - and that there is
a community
which answer questions and helps on problems - as no one is able to do
eveything alone.

That is what is FPC good for !

helmut



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] 2.0.3 AV's

[Dipl.- Ing. Helmut Hartl]

Hi,

I am currently managing ZEOS DBO Development. 
We are testing ZEOS with MySQL 5 & Postgres 8.1 and FPC 2.0.2 
which works pretty stable! We would like to release 
"more stable" packages for lazarus and fpc in the next time.

But due to the TDatetime issue in TDataset we wanted to 
switch over to 2.0.3, as the TDatetime behaviour
is fixed there (and remove the patches in ZEOS DBO).

Our problem at the moment is that it seems that 2.0.3 is unstable
with memory management as we get random errors throughout the testsuites . 
Also strange errors with TCompressionStream are occurring, where I am not
sure if they are follow up's from the AV's. 
I'll report back if I can isolate them better .

Are there some major changes between 2.0.2 and 2.0.3 fixes branch im Memory
Management ?

Following test program crashes under 2.0.3 and works under 2.0.3
("accidentially" discovered while playing with streams)

program fpc203fish;
{$mode objfpc}{$H+}
uses  Classes;
vars:String;
   i:integer;
begin
 s:='123123sdfjkysdjfklsdn3m,w45';
 for i:=0 to 22 do begin
  s:=s+s;
  writeln(i);
 end;
end.  

With Output:
.
13
14
15
An unhandled exception occurred at $08048573 :
EAccessViolation : Access violation
  $08048573  FORWARDS_IA32_3,  line 375 of
/opt/fpc_svn/rtl/i386/fastmove.inc
  $0804810A  main,  line 9 of fpc203fish.lpr


Postet as BUG 4999

Thanks,

helmut

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel