[fpc-devel] mysql error when compiling latest CVS
I get this with latest CVS: Compiling /home/ales/fpc/packages/base/mysql/mysql.pp mysqldb.pp(241,30) Error: Illegal qualifier mysqldb.pp(241,24) Error: Operator is not overloaded mysqldb.pp(241,30) Fatal: Syntax error, THEN expected but identifier NAME found Have found out probably buggy declaration in mysql unit: MYSQL_FIELD = st_mysql_field; TMYSQL_FIELD = ^MYSQL_FIELD; -- should probably be MYSQL_FIELD PMYSQL_FIELD = ^MYSQL_FIELD; However changing it will produce other errors. Note that this bug is cross-platform ;) Ales ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XmlCfg Patch
This patch fixes a problem with XmlCfg related to reading a bad xml file
and catching an exception:
try
axml:=TXMlConfig.Create(filename); // try to parse the file
except
on E: Exception do
begin
writeln('Error: '+ E.Message);
freeandnil(axml);
end;
end;
There's a memory leak if the exception get's called(with or without
freeandnil).
Ales
Index: fpc-1.9/fcl/xml/xmlread.pp
===
RCS file: /FPC/CVS/fpc/fcl/xml/xmlread.pp,v
retrieving revision 1.12
diff -u -r1.12 xmlread.pp
--- fpc-1.9/fcl/xml/xmlread.pp 5 Nov 2004 22:32:28 - 1.12
+++ fpc-1.9/fcl/xml/xmlread.pp 16 Dec 2004 12:27:34 -
@@ -1389,8 +1389,8 @@
Reader := TXMLReader.Create;
try
Reader.ProcessXML(buf, AFilename);
- ADoc := TXMLDocument(Reader.doc);
finally
+ ADoc := TXMLDocument(Reader.doc);
Reader.Free;
end;
finally
___
fpc-devel maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TList slowness in classes
I've read a complaint about TList being slow so I decided to give it a test.
Quite frankly the test showed this is truth, but I couldn't find out why.
I found out that if I copy the TList from classes as-is into my unit
and use this
copy, it is about 3x faster in certain conditions. I have no idea why
this is so but
I think there's something wrong...
I posted my test at http://members.chello.sk/ales/testlist.zip
Just download, unzip and compile:
you'll get swap time and access time for the original TList
uncomment {$DEFINE USEMYLIST} to get the times for my copy of TList
The copy there is unchanged.
Ales Katona
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
Michalis Kamburelis wrote:
Hi,
I tested your code and found that indeed version in ucopylist is
slightly faster (by about 9.5 / 7 =~ 1.357). Two things:
1. Speedup is only 1.357x, not 3x, like you said. Are you sure that
you're getting 3x speedup ? On what OS and with what FPC version are
you testing this ? I was doing tests with Linux/i386 with FPC 1.9.4
and 1.9.5 (from CVS 2004-12-20).
2. Still, speedup 1.357x may be significant in some cases so I
investigated what's the cause:
After many tests I found that this slight speedup is caused by the
fact that in ucopylist you declared string constants SListIndexError,
SListCapacityError and SListCountError as normal constants while with
original Classes unit these constants are taken from RTLConst unit
that defines them as resourcestrings.
Using resourcestrings in RTL is a must, since this allows to translate
error messages without modifying unit Classes sources.
However in this case exceptions are not raised, so resourcestrings are
not actually used. But it looks that any procedure that uses some
resourcestring in implementation is doomed to be slower than the
similar procedure that instead uses normal string consts, *even if
this procedure doesn't actually access the string at runtime*. It
seems that if some procedure uses resourcestring then upon entry it
does some lengthy initialization of this resourcestring, even if it
will not actually make use of that resourcestring.
I'm attaching a simple demo program that shows this. When compiled like
fpc -OG -O2 -Op2 demo_resourcestring_slow.pas
(to get maximum optimizations) sample output of it is
Time of Foo_Normal: 16
Time of Foo_ResourceString: 106
So time difference is really noticeable. Question goes to FPC
developers, maybe such cases with using resourcestrings can be speed up ?
Regards,
{$mode objfpc}{$H+}
uses
{BaseUnix, Unix needed only to implement Clock} BaseUnix, Unix,
SysUtils;
function Clock: Int64;
var Dummy: tms;
begin
Clock := FpTimes(Dummy);
end;
const
SNormal= 'blah blah blah blah blah blah blah blah blah blah';
resourcestring
SResString = 'blah blah blah blah blah blah blah blah blah blah';
{ Foo_Normal and Foo_ResourceString do the same thing,
but Foo_Normal uses normal string constant while
Foo_ResourceString uses resourcestring. }
procedure Foo_Normal(i: Integer);
begin
if i = -1 then raise Exception.Create(SNormal);
end;
procedure Foo_ResourceString(i: Integer);
begin
if i = -1 then raise Exception.Create(SResString);
end;
{ Note that when I call Foo_Normal and Foo_ResourceString
i is always = 0 so Exception is never actually raised.
So string constants SNormal and SResString are not really used. }
const
TestCount = 1000;
var
i: Integer;
Start: Int64;
begin
Start := Clock;
for i := 0 to TestCount do Foo_Normal(i);
Writeln('Time of Foo_Normal: ', Clock - Start);
Start := Clock;
for i := 0 to TestCount do Foo_ResourceString(i);
Writeln('Time of Foo_ResourceString: ', Clock - Start);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
The slowness 3x I ment was not between atomics like get/put but when I
tested a bigger(1x1) bubblesort with the copy and original. The
times back then I got were about:
Original: ~28seconds
Copy: ~6seconds
This is even more than 3x.(ups ;-) ) In any case the point is in
critical operations these things can be real problematic. Another
interresting fact is that ListArray from java(almost same thing as our
TList) was about 8 seconds with same test.
Don't get me wrong, I'm not trying to reasure myself here, it's just
that I think it can be made faster nothing else.
The resourcestrings are interresting. I'd look at the code but I'm
afraid that's a bit too deep RTL for me...
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 1.9.6 (a.k.a. 2.0.0-RC1) is out
Jonas Maebe wrote: On 4 jan 2005, at 15:27, peter green wrote: lazarus is essentially what completes the cloning of delphi by freepascal. I prefer to think that we're much more than just a clone of Delphi :) In fact, I've never even used Delphi in my entire life (nor really used Lazarus, for that matter). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel By the qotes I ment that someone might think so. I view lazarus as sometimes more important than FPC itself when it comes to spreading the word(tm). Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] XMLCfg leaking
Try this program with a corrupted xml file(just delte part of a tag or
something)
Compile with -ghl and you'll get a few bytes leaked.
program xmltest;
{$mode objfpc}{$H+}
uses
SysUtils, XMLCfg;
function LoadXML(var axml: TXmlConfig; const filename: string): boolean;
begin
writeln('Loading');
axml:=nil;
result:=true;
try
axml:=TXMlConfig.Create(filename); // try to parse the file
except
on E: Exception do
begin
writeln('Error: '+ E.Message);
result:=false;
end;
end;
if not result then
freeandnil(axml);
end;
var xml: TXMLConfig;
begin
if LoadXML(xml, 'test.xml') then
writeln('Success');
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc/fcl/image buggy
Reading certain JPEGs results in a JPEG error. One such is http://members.chello.sk/ales/title.jpg Just try to convert it to a PNG by imgconv(also present in fpc/fcl/image) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modernising Pascal
. Then GC might be made so that not every collection has to hit entire memory. And collection is often incremental (interleaved with user code execution). If some of it was swapped out, you can then expect hell (I've seen it happen), and as compaction is a necessity of linear allocation, you can never be 100% sure to avoid it with a linearly allocating GC. Well, I had once wait ~half a minute for one few hundred MB allocation to finish (that was on 4BG RAM, 4 CPU Tru64 box with code compiled with one of the best code-preformance-wise compilers around DEC CXX 6.x). This was explicit allocation of course (so far with allocation in constant time). So yes, shit happens. The other thing is that especuially early Java implementations had primitive poor GC. Incremental generational collector won't try to access entire heap allmost at once. Finally garbage collection isn't a linear phase, and it's also intrinsically not cache friendly (lots of random accesses all over the allocated memory, most of which are going to be cache misses). Nowadays, cache inefficiency can result in a lot of hidden perf hits, with uncached accesses being 10 or more times slower (from CPU ratios, RAM latencies, controler/chipset latencies, that all add to the CPU's own L1/L2 latencies). Memory is 100-300 times slower latency wise than L1 cache. 10 CPU cycles doesn't sound like much, but that's enough time for a dozen+ instructions under adequate circumstances, Todays OutOfOrder CPUs can find a lot of useful work during such relatively short (10 cycles is very little) periods of time -- btw even L2 cache hits take longer (out of PC processors only PentiumM has 10 cycle L2 latency, others are worse. have it happen too often, and that's enough to make the difference between smooth and sluggish. You didn't touch the other side. Non compacting allocation is either slow or has significant internal fragmentation, especially heap allocating tiny objects is very wasteful. You'll go out of small L1 cache quick while large portions of your cache lines will contain just unused holes. rgds -- Sebastian Kaliszewski ___ 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 I don't want to hit the bleeding wound but I think the point is: NO GC. Each of us has better things to do than try some GCs out which in the end won't be used anyhow. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RE: Hint: Parameter sender not used
Jeff Pohlmeyer wrote / napísal (a): This is not a big issue, anyway could we avoid the endless list of such similar hints compiling Lazarus and our program? I frequently find a similar annoyance with c library callbacks. For instance, most gtk functions have a user_data parameter that is often unused. Maybe there could be a procedure directive and/or compiler switch to ignore unsused parameter hints on prototyped functions, or perhaps to turn this particluar hint off completely? Or even a dummy function like: Ignore(Sender); - Jeff I agree. Something to turn of only parameter unused variables checks. It's not critical or anything but I think it might be good if it made it to 2.0 I'm not sure but doesn't Delphi actualy ignore unused parameters? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
Michael Van Canneyt wrote / napísal (a): On Wed, 16 Mar 2005, DrDiettrich wrote: Michael Van Canneyt wrote: type TFriendClass = class(TNotMyClass); This is a simple descendent. Yes and no. The only purpose of this declaration is to get access to the protected members of the class, not to extend the class in any way. Yes. This is OK, no ? 3) What alternatives could be used, so that not all class members must be made public, when they shall be used only in specific related units? ? Please explain. protected members of a class are for internal use only, not for public use. IMO it's against the spirit of visibility levels, when the protected and even private members of a class become accessible from outside the class, throughout the whole unit in which a class is defined. But sometimes multiple classes are designed for cooperation, where one class needs access to not normally accessible methods or properties of another class. When now the required methods are made public, they become available for abuse by everybody. With the above trick instead it's possible to gain access to the internals of a class, without making everything public. Such a backdoor does not prevent abuse, but as the (C++) term friend class suggests, it exists only for the sake of cooperation, and at the responsibility of the implementor. That's why I would like to know how such cooperative functionality can be implemented, by perhaps less tricky means. sorry, but I fail to see the problem ? The above makes all protected members of a class visible. This is normal, that is why they are protected. If you want to avoid that, make the members private. Then they are visible only in the same unit, even for other classes (for 'cooperation'), but not outside the unit, even with a descendent. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Friend classes?
DrDiettrich wrote / napísal (a): Ales Katona wrote: C++ requires friend only because it lacks the idea of modularity. Since all classes are apart they need some way to tell each other I can use you In pascal you simply put them into 1 unit. That's why the C++ model is better, there exists no requirement to implement related classes in a single module. In porting C++ code to Pascal I often stumbled into circular unit references. Then the only solution is a monster unit, that implements all the related classes at once, where the C++ implementation can be split into appropriate modules. Even in Java it's possible to implement every class in a dedicated unit, regardless of class relationships, and without a need for separate header files. That's what I call a good modular concept. Perhaps I dislike Pascal include files only because they are poorly supported by the Delphi IDE. With better support it were possible to split the implementation into multiple dedicated include files, which could be thought of as implementation files, according to e.g. the Modula model. Lazarus offers better support for included files, but unfortunately it currently groups the types, constants etc. overview together by the according clauses; I hope for better grouping options in the near future, so that e.g. all types of an unit can reside in a single group. I already considered to contribute to the Lazarus development, but currently I have other projects with higher priority... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel This is actualy a C problem. If you imagine the outcome any bigger C program is one big piece of code. If C/C++ had proper modularity support, things like this wouldn't happen. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
Jonas Maebe wrote / napísal (a): On 17 Apr 2005, at 09:38, Yury B. wrote: for 32-bit x86... or does 64-bit platform also uses 32-bit integers as default, so that longint would be good? JM It would break a lot of existing code if we did that. You can perfectly JM define integer to be whatever you want yourself. I want a kind of standard. I don't understand why. If I don't need classes then I would prefer not using objfpc or delphi mode (in order not to include huge fcl stuff) They don't include any fcl stuff by default. And with smartlinking turned on, the only extra thing you get from the objpas unit is a procedure called ResetResourceTables (and the ResourceStringTable record). but i want integer to be natural to the platform. Even C is now moving more and more to types with a predictable size (see all the types in C99). I think knowing how large a type is, is much more important in order to create good programs than some perceived speed gain (especially since you can easily redefine any type to be whatever you want). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I think that pascal typesystem requires a bit overhaul when it comes to integers. First of all Integer should be size independent, that is, xy bits depending on the platform. All others should be specific. Second, we should force people in a friendly way to use more readible names like: sint32, uint64, etc. than cardinal In a few years when 64 bits are normal, what will cardinal become? who knows.. just one big IMHO Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
Vinzent Hoefler wrote / napísal (a): On Sunday 17 April 2005 10:45, Ales Katona wrote: First of all Integer should be size independent, that is, xy bits depending on the platform. I second that. Second, we should force people in a friendly way to use more readible names like: sint32, uint64, etc. than cardinal No. Such stuff is only needed when you do hardware-interfacing. And that's the _only_ reason someone would need types with defined bit-sizes. In a few years when 64 bits are normal, what will cardinal become? who knows.. That's why Pascal has range types. Define the range you need, and don't use just some type which has the range you think you will need. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel And how about ABI and API compatibility? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Gerhard Scholz wrote: var x : type1, y : type2 ; x *:= y ; in my humble opinion(IMHO): := is based on the fact that A: is written normaly in math etc. where it means this is a fact about A So when someone writes A:=5; it means it's a fact that A equals 5 Writing A*:= is stupid. If nothing else do it like this: A:*= But IMHO it's useless in ANY case. Even C people tend to not use it when they want readible code(especialy * which is so ambiguos) As to the ASM: in C if you do a+=b; and a is int b is longint it does this actualy: a = a + (int)b; which is stupid and unsafe. Just my 0.05 euros ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Jamie McCracken wrote: Marc Weustink wrote: What is easier to read is a matter of taste. Being a pascal devel for years now, it takes time to decode a a := b := c := d := 0 line. There might be a ; inbeween which results in a complete different assignment. With such lines I've to read them over and over to see what is going on. Where a line like a := 0; b := 0; c := 0; d := 0; is clear to me. This also counts for the proposed c-isms. For me I prefere clarity above less typing (besides if you want to write realy short code, you sould use APL) I totally agree with you in this case - we dont want or need cryptic c stlye syntax in any version of Pascal. However, in general Pascal has poor developer productivity when compared to modern languages like python and C#. Ironically python is perhaps the most popular language on Linux and most of its syntax is derived from object pascal whereas pascal on linux is virtually non-existant. Of course Python is piss poor in both performance and memory usage but it does point the way to a revitalised pascal. Adopting less verbose but still clean and clear syntax ala python is IMHO the way to make Pascal great again. Consider the developer unfirendly nature of pascal/Delphi atm: 1) Forward declarations - they sux! Why should the developers have the burden of making the code totally sequential declaration wise. All other modern compilers dont need this. Sure your code might take a bit longer to compile but thats peanuts compare to the time saved in extra typing and reordering your code 2) I have touched on manual memory managaement of tobjects before so I wont rehash it here (in summary ref count tobjects and they should have good performance with c++ style exception handling). 3) loads of small and pointless additional syntax like EG for creating an object you should just be able to say: myobject.create; and not myobject := Tobject.create; also Begin..End blocks should IMO be replaced with python's indenting. Yeah I know this sounds like a hybrid pascal/python but I believe thats the way to go - marry Delphi's speed and component framework with less verbose python style syntax and you will have the best RAD language ever written. jamie. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel MyObject.Create is impossible with classes on the heap. You need to assign MyObject a pointer but you can't do that from within create. Forward declarations are IMHO required because otherwise the compiler would have to make additional passes(it does 3 AFAIK). Besides, they are seldom enough to be a problem. How does python handle modularity btw? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: [fpc-l] type discussion
Marco van de Voort wrote: Also, I simply don't see the use of it. Borland Pascal's have the forward directive for those really few cases where it is annoying. Also, forward declarations mostly mean shitty code / design. Atleast in my case it does. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetText patch
This patch makes GetText/TranslateResourceStrings(FileName) work in
win32. (it didn't detect the right language under win32 before it worked
only in POSIX enviroments)
GetLanguageIDs is used with permission from Vincent(it's his code in
lazarus)
Ales
Index: fcl/inc/gettext.pp
===
--- fcl/inc/gettext.pp (revision 285)
+++ fcl/inc/gettext.pp (working copy)
@@ -1,5 +1,4 @@
{
-$Id: gettext.pp,v 1.9 2005/03/15 16:27:04 peter Exp $
This file is part of the Free Pascal run time library.
Copyright (c) 1999-2001 by the Free Pascal development team
@@ -77,7 +76,7 @@
implementation
-uses dos;
+uses {$ifdef win32} windows, {$endif}dos;
var
GettextUsed: Boolean;
@@ -261,10 +260,39 @@
{$endif}
procedure TranslateResourceStrings(const AFilename: String);
+
+{$ifdef win32}
+procedure GetLanguageIDs(var Lang, FallbackLang: string);
var
+ Buffer: array[1..4] of char;
+ Country: string;
+ UserLCID: LCID;
+begin
+ //defaults
+ Lang := '';
+ FallbackLang:='';
+ UserLCID := GetUserDefaultLCID;
+ if GetLocaleInfo(UserLCID, LOCALE_SABBREVLANGNAME, @Buffer, 4)0 then
+FallbackLang := lowercase(copy(Buffer,1,2));
+ if GetLocaleInfo(UserLCID, LOCALE_SABBREVCTRYNAME, @Buffer, 4)0 then begin
+Country := copy(Buffer,1,2);
+
+// some 2 letter codes are not the first two letters of the 3 letter code
+// there are probably more, but first let us see if there are translations
+if (Buffer='PRT') then Country:='PT';
+
+Lang := FallbackLang+'_'+Country;
+ end;
+end;
+{$endif}
+
+var
mo: TMOFile;
lang, FallbackLanguage: String;
begin
+ {$ifdef win32}
+ GetLanguageIDs(Lang, FallbackLanguage);
+ {$else}
lang := GetEnv('LC_ALL');
if Length(lang) = 0 then
begin
@@ -276,8 +304,8 @@
exit; // no language defined via environment variables
end;
end;
-
FallbackLanguage := Copy(lang, 1, 2);
+ {$endif}
try
mo := TMOFile.Create(Format(AFilename, [FallbackLanguage]));
try
@@ -306,14 +334,3 @@
if GettextUsed then
ResetResourceTables;
end.
-
-
-{
- $Log: gettext.pp,v $
- Revision 1.9 2005/03/15 16:27:04 peter
-* use dispose instead of freemem to also release the initialize types
-
- Revision 1.8 2005/02/14 17:13:15 peter
-* truncate log
-
-}
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library and unit search paths under MacOSX with fpc 2.0.0?
Your fpc.cfg file is ether not existing, in the wrong place or wrongly
configured. I don't know where it should be on MacOSX but if you find it
fix the -Fu entries so they point to right locations(note: $fpcversion
etc. are variables, leave them as they are: for example in here:
-Fu/usr/local/lib/fpc/$fpcversion/units/*
Ales
Tom Verhoeff wrote:
I have a standard release installation of fpc 2.0.0 under Mac OS X.
I installed GTK through fink (as explained in the Lazarus wiki).
This has given me GTK 1.2.10. No problems so far.
When I try to compile the following simple GTK Pascal tutorial program
PROGRAM base;
USES gtk;
VAR window : pGtkWidget;
BEGIN
gtk_init(@argc, @argv); { Initialise GTK }
window := gtk_window_new(GTK_WINDOW_TOPLEVEL); { Create a new window }
gtk_widget_show(window);
gtk_main();
END.
with fpc, I need to add the following command-line options
-Fl/sw/lib -Fl/usr/X11R6/lib
as well as
-Fu/usr/local/lib/fpc/2.0.0/units/powerpc-darwin/gtk
The first two caught me by surprise, but some tracking resolved this.
However, under Linux, I don't need to specify further library locations.
How come?
Is there any documentation where this can be found? Is there a place
where I can put this info in the FPCWiki?
But the need for -Fu is downright strange, because the standard /etc/fpc.cfg
(which I have not changed) has the line
-Fu/usr/local/lib/fpc/2.0.0/units/$fpctarget/*
Why does it not find the gtk directory? Under Linux it simply works.
In fact, when I try to compile Lazarus under Mac OS X with
make clean all
it dies with
Fatal: Can't find unit Contnrs
It should find the Contnrs unit in
/usr/local/lib/fpc/2.0.0/units/powerpc-darwin/fcl
which should be searched because of the -Fu line shown above in /etc/fpc.cfg.
What is the problem? And how can it be repaired?
Best regards,
Tom
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Library and unit search paths under MacOSX with fpc 2.0.0?
Micha Nelissen wrote: On Wed, 15 Jun 2005 08:29:54 +0200 Ales Katona [EMAIL PROTECTED] wrote: Your fpc.cfg file is ether not existing, in the wrong place or wrongly configured. I don't know where it should be on MacOSX but if you find it It's not so simple, I think, because otherwise he also wouldn't find RTL units like system and sysutils. It seems the '*' construct doesn't work on MacOSX ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Actualy I get contnrs missing too if I put fpc.cfg away.. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] OpenGL library loading
I've noticed that openGL libraies are loaded in the initialization section and if the loading fails it writelns something and halts. I think this is innapropriate. I've made some changes but first I want to know your opinion. Do you think it's better to let the user load the library(via some simple procedure) or have it initialized automaticly. If so, IMHO an exception should be used(because of windows crashing with writeln). I've currently made it to try and load the library in the initialization but without any failure notice. I've added a GL[u[t]]IsLoaded function so the users can see and also TryLoadGL[u[t]]. Tell me which way to go and I'll implement it. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] OpenGL patch
Ok so here's the patch. If you feel some things should change, tell me
about it.
This patch adds TryLoadGL[u[t]] and GL[u[t]]IsLoaded methods and
also fixes the crash on win32 if opengl is not present. (but it will
still crash later, if the user doesn't check)
Ales
Index: packages/extra/opengl/gl.pp
===
--- packages/extra/opengl/gl.pp (revision 446)
+++ packages/extra/opengl/gl.pp (working copy)
@@ -1534,15 +1534,26 @@
PFNGLGETCOLORTABLEPARAMETERIVEXTPROC = procedure(target, pname: GLenum;
params: PGLint); extdecl;
PFNGLGETCOLORTABLEPARAMETERFVEXTPROC = procedure(target, pname: GLenum;
params: PGLfloat); extdecl;
+function GLIsLoaded: Boolean;
procedure LoadOpenGL(const dll: String);
+procedure TryLoadGL;
procedure FreeOpenGL;
+
implementation
+var
+ GLLoaded: Boolean;
+
{$ifdef win32}
function WinChoosePixelFormat(DC: HDC; p2: PPixelFormatDescriptor): Integer;
extdecl; external 'gdi32' name 'ChoosePixelFormat';
{$endif}
+function GLIsLoaded: Boolean;
+begin
+ Result:=GLLoaded;
+end;
+
procedure FreeOpenGL;
begin
@@ -1887,7 +1898,7 @@
{$ENDIF}
FreeLibrary(LibGL);
-
+ GLLoaded:=False;
end;
procedure LoadOpenGL(const dll: String);
@@ -2240,15 +2251,11 @@
if not Assigned(ChoosePixelFormat) then
@ChoosePixelFormat := @WinChoosePixelFormat;
{$ENDIF}
-
+ GLLoaded:=True;
end;
-initialization
-
- {$IFDEF WIN32}
- Set8087CW($133F);
- {$ENDIF WIN32}
-
+procedure TryLoadGL;
+begin
try
{$IFDEF Win32}
LoadOpenGL('opengl32.dll');
@@ -2260,10 +2267,19 @@
{$endif}
{$ENDIF}
except
-writeln('Error opening OpenGL library');
-halt(1);
+GLLoaded:=False;
end;
+end;
+initialization
+
+ {$IFDEF WIN32}
+ Set8087CW($133F);
+ {$ENDIF WIN32}
+
+ GLLoaded:=False;
+ TryLoadGL;
+
finalization
FreeOpenGL;
Index: packages/extra/opengl/glu.pp
===
--- packages/extra/opengl/glu.pp(revision 446)
+++ packages/extra/opengl/glu.pp(working copy)
@@ -363,14 +363,22 @@
GLU_ERROR = GLU_TESS_ERROR;
GLU_EDGE_FLAG = GLU_TESS_EDGE_FLAG;
+function GLuIsLoaded: Boolean;
procedure LoadGLu(const dll: String);
+procedure TryLoadGLu;
procedure FreeGLu;
implementation
var
hDLL: THandle;
+ GLuLoaded: Boolean;
+function GLuIsLoaded: Boolean;
+begin
+ Result:=GLuLoaded;
+end;
+
procedure FreeGLu;
begin
@@ -428,7 +436,7 @@
@gluEndPolygon := nil;
FreeLibrary(hDLL);
-
+ GLuLoaded:=False;
end;
procedure LoadGLu(const dll: String);
@@ -492,11 +500,11 @@
@gluBeginPolygon := GetProcAddress(hDLL, 'gluBeginPolygon');
@gluNextContour := GetProcAddress(hDLL, 'gluNextContour');
@gluEndPolygon := GetProcAddress(hDLL, 'gluEndPolygon');
-
+ GLuLoaded:=True;
end;
-initialization
-
+procedure TryLoadGLU;
+begin
try
{$IFDEF Win32}
LoadGLu('glu32.dll');
@@ -508,10 +516,14 @@
{$ENDIF}
{$endif}
except
-writeln('error opening libGLU');
-halt(1);
+GLuLoaded:=False;
end;
+end;
+initialization
+ GLuLoaded:=False;
+ TryLoadGLu;
+
finalization
FreeGLu;
Index: packages/extra/opengl/glut.pp
===
--- packages/extra/opengl/glut.pp (revision 446)
+++ packages/extra/opengl/glut.pp (working copy)
@@ -390,14 +390,22 @@
glutLeaveGameMode : procedure; extdecl;
glutGameModeGet : function (mode : GLenum) : integer; extdecl;
+function GLutIsLoaded: Boolean;
procedure LoadGlut(const dll: String);
+procedure TryLoadGLut;
procedure FreeGlut;
implementation
var
hDLL: THandle;
+ GLutLoaded: Boolean;
+function GLutIsLoaded: Boolean;
+begin
+ Result:=GLutLoaded;
+end;
+
procedure FreeGlut;
begin
@@ -507,7 +515,7 @@
@glutVideoResize := nil;
@glutVideoPan := nil;
@glutReportErrors := nil;
-
+ GLutLoaded:=False;
end;
procedure LoadGlut(const dll: String);
@@ -626,11 +634,11 @@
@glutEnterGameMode := GetProcAddress(hDLL, 'glutEnterGameMode');
@glutLeaveGameMode := GetProcAddress(hDLL, 'glutLeaveGameMode');
@glutGameModeGet:= GetProcAddress(hDLL, 'glutGameModeGet');
-
+ GLutLoaded:=True;
end;
-initialization
-
+procedure TryLoadGLut;
+begin
try
{$IFDEF Win32}
LoadGlut('glut32.dll');
@@ -642,10 +650,14 @@
{$endif}
{$ENDIF}
except
-writeln('Can''t load glut library');
-halt(1);
+GLutLoaded:=False;
end;
+end;
+initialization
+ GLutLoaded:=False;
+ TryLoadGLut;
+
finalization
FreeGlut;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenGL patch, final(I hope)
Florian Klaempfl wrote: Ales Katona wrote: Ok this patch does the following: Removes the writeln() in case the library fails to load. If the whole library is not found, it throws an exception which tell the library name. If any method within the library is not found it throws an exception with the given method name. Ales P.S: it's packed because of size Applied. Shall we merge it back to 2.0.x? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel IMHO yes, but I haven't tested it much. I know that GL and GLu work with it, and I know that if I get missing/renamed dll it exceptions as advertized. The other goodies are pretty hard to test. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TFPObjectList patch
This patch adds TFPObjectList to contnrs.
It's a descendent of TFPList and uses same tricks to gain speed.(inline
etc.)
I've tested with bubblesort and it was 1/3 faster.
P.S: I wanted to get rid of inherited calls too but FCount is private in
TFPList ;(
Ales
Index: fcl/inc/contnrs.pp
===
--- fcl/inc/contnrs.pp (revision 468)
+++ fcl/inc/contnrs.pp (working copy)
@@ -21,7 +21,29 @@
SysUtils,Classes;
Type
+{$inline on}
+ TFPObjectList = class(TFPList)
+ private
+FFreeObjects : Boolean;
+ protected
+function GetItem(Index: Integer): TObject; {$ifdef HASINLINE}
inline;{$endif}
+procedure SetItem(Index: Integer; AObject: TObject); {$ifdef HASINLINE}
inline;{$endif}
+ public
+constructor Create;
+constructor Create(FreeObjects : Boolean);
+function Add(AObject: TObject): Integer; {$ifdef HASINLINE} inline;{$endif}
+function Extract(Item: TObject): TObject;
+function Remove(AObject: TObject): Integer;
+function IndexOf(AObject: TObject): Integer;
+function FindInstanceOf(AClass: TClass; AExact: Boolean; AStartAt:
Integer): Integer;
+procedure Insert(Index: Integer; AObject: TObject); {$ifdef HASINLINE}
inline;{$endif}
+function First: TObject;
+function Last: TObject;
+property OwnsObjects: Boolean read FFreeObjects write FFreeObjects;
+property Items[Index: Integer]: TObject read GetItem write SetItem;
default;
+ end;
+
TObjectList = class(TList)
private
ffreeobjects : boolean;
@@ -131,6 +153,92 @@
implementation
+constructor TFPObjectList.Create(FreeObjects : boolean);
+begin
+ inherited Create;
+ FFreeObjects:=Freeobjects;
+end;
+
+constructor TFPObjectList.Create;
+begin
+ inherited Create;
+ FFreeObjects:=True;
+end;
+
+function TFPObjectList.GetItem(Index: Integer): TObject; {$ifdef HASINLINE}
inline;{$endif}
+begin
+ Result:=TObject(inherited Get(Index));
+end;
+
+procedure TFPObjectList.SetItem(Index: Integer; AObject: TObject); {$ifdef
HASINLINE} inline;{$endif}
+var
+ O : TObject;
+begin
+ if OwnsObjects then
+begin
+O:=GetItem(Index);
+O.Free;
+end;
+ Put(Index,Pointer(AObject));
+end;
+
+function TFPObjectList.Add(AObject: TObject): Integer; {$ifdef HASINLINE}
inline;{$endif}
+begin
+ Result:=inherited Add(Pointer(AObject));
+end;
+
+function TFPObjectList.Extract(Item: TObject): TObject;
+begin
+ Result:=Tobject(inherited Extract(Pointer(Item)));
+end;
+
+function TFPObjectList.Remove(AObject: TObject): Integer;
+begin
+ Result:=inherited Remove(Pointer(AObject));
+end;
+
+function TFPObjectList.IndexOf(AObject: TObject): Integer;
+begin
+ Result:=inherited indexOF(Pointer(AObject));
+end;
+
+function TFPObjectList.FindInstanceOf(AClass: TClass; AExact: Boolean;
AStartAt : Integer): Integer;
+var
+ I : Integer;
+begin
+ I:=AStartAt;
+ Result:=-1;
+ If AExact then
+while (ICount) and (Result=-1) do
+ If Items[i].ClassType=AClass then
+Result:=I
+ else
+Inc(I)
+ else
+while (ICount) and (Result=-1) do
+ If Items[i].InheritsFrom(AClass) then
+Result:=I
+ else
+Inc(I);
+end;
+
+procedure TFPObjectList.Insert(Index: Integer; AObject: TObject); {$ifdef
HASINLINE} inline;{$endif}
+begin
+ inherited Insert(Index,Pointer(AObject));
+end;
+
+function TFPObjectList.First: TObject;
+begin
+ Result := TObject(inherited First);
+end;
+
+function TFPObjectList.Last: TObject;
+begin
+ Result := TObject(inherited Last);
+end;
+
+{ TObjectList }
+
constructor tobjectlist.create(freeobjects : boolean);
begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetText patch #2
This patch (ment for 2.1.1) cleans some of my old unnecessery mess but
more importantly adds the GetLanguageIDs() method. This way, you can see
what language was/will be autodetected. Good for those special holiday
occasions. Works on win32 as well as POSIX.
Ales
P.S: sorry, I didn't think about it earlier.
Index: fcl/inc/gettext.pp
===
--- fcl/inc/gettext.pp (revision 482)
+++ fcl/inc/gettext.pp (working copy)
@@ -70,6 +70,7 @@
EMOFileError = class(Exception);
+ procedure GetLanguageIDs(var Lang, FallbackLang: string);
procedure TranslateResourceStrings(AFile: TMOFile);
procedure TranslateResourceStrings(const AFilename: String);
@@ -259,8 +260,6 @@
end;
{$endif}
-procedure TranslateResourceStrings(const AFilename: String);
-
{$ifdef win32}
procedure GetLanguageIDs(var Lang, FallbackLang: string);
var
@@ -284,15 +283,11 @@
Lang := FallbackLang+'_'+Country;
end;
end;
-{$endif}
-var
- mo: TMOFile;
- lang, FallbackLanguage: String;
+{$else}
+
+procedure GetLanguageIDs(var Lang, FallbackLang: string);
begin
- {$ifdef win32}
- GetLanguageIDs(Lang, FallbackLanguage);
- {$else}
lang := GetEnv('LC_ALL');
if Length(lang) = 0 then
begin
@@ -305,7 +300,15 @@
end;
end;
FallbackLanguage := Copy(lang, 1, 2);
- {$endif}
+end;
+{$endif}
+
+procedure TranslateResourceStrings(const AFilename: String);
+var
+ mo: TMOFile;
+ lang, FallbackLanguage: String;
+begin
+ GetLanguageIDs(Lang, FallbackLanguage);
try
mo := TMOFile.Create(Format(AFilename, [FallbackLanguage]));
try
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Win32 sockets patch
There is an ugly type bug in win32 sockets.pp. This patch fixes it. ssize_t = cuint16 -- this caused a bug with fprecv/fprecvfrom and fpsend/fpsendto calls because winsock.recv[from]/winsock.send[to] calls return a longint while fprecv used an unsigned int as return value. This caused the recv call to recieve loads of rubbish when an error occured. I changed ssize_t to Int64(as it is in unix). Index: rtl/win32/sockets.pp === --- rtl/win32/sockets.pp(revision 744) +++ rtl/win32/sockets.pp(working copy) @@ -26,7 +26,7 @@ cuint16=word; cuint32=cardinal; size_t =cuint32; - ssize_t=cuint16; + ssize_t=Int64; cint =longint; pcint =^cint; tsocklen=cint; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Sockets patch for the patch :)
Sorry I looked at the wrong unix part (it was in ifdef cpu64) so I used int64 in windows. This patch (apply after the 1st one) changes ssize_t to cint32 as it should be on 32bit systems. Sorry again, Ales Index: sockets.pp === --- sockets.pp (revision 749) +++ sockets.pp (working copy) @@ -26,7 +26,7 @@ cuint16=word; cuint32=cardinal; size_t =cuint32; - ssize_t=Int64; + ssize_t=cint32; cint =longint; pcint =^cint; tsocklen=cint; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Libc patch 2
Apply after the 1st one. This patch fixes crypto function in libc unit.
Ales
Index: crypth.inc
===
--- crypth.inc (revision 1156)
+++ crypth.inc (working copy)
@@ -1,9 +1,9 @@
{ defined earlier in unistdh.inc...
-function crypt(__key:Pchar; __salt:Pchar):Pchar;cdecl;external clib name
'crypt';
-procedure setkey(__key:Pchar);cdecl;external clib name 'setkey';
-procedure encrypt(__block:Pchar; __edflag:longint);cdecl;external clib name
'encrypt';
+function crypt(__key:Pchar; __salt:Pchar):Pchar;cdecl;external cryptlib name
'crypt';
+procedure setkey(__key:Pchar);cdecl;external cryptlib name 'setkey';
+procedure encrypt(__block:Pchar; __edflag:longint);cdecl;external cryptlib
name 'encrypt';
}
type
Pcrypt_data = ^crypt_data;
@@ -20,9 +20,9 @@
initialized : longint;
end;
-function crypt_r(__key:Pchar; __salt:Pchar;
__data:Pcrypt_data):Pchar;cdecl;external clib name 'crypt_r';
-procedure setkey_r(__key:Pchar; __data:Pcrypt_data);cdecl;external clib name
'setkey_r';
-procedure encrypt_r(__block:Pchar; __edflag:longint;
__data:Pcrypt_data);cdecl;external clib name 'encrypt_r';
+function crypt_r(__key:Pchar; __salt:Pchar;
__data:Pcrypt_data):Pchar;cdecl;external cryptlib name 'crypt_r';
+procedure setkey_r(__key:Pchar; __data:Pcrypt_data);cdecl;external cryptlib
name 'setkey_r';
+procedure encrypt_r(__block:Pchar; __edflag:longint;
__data:Pcrypt_data);cdecl;external cryptlib name 'encrypt_r';
{ -
Borland compatibility types
Index: dlfcnh.inc
===
--- dlfcnh.inc (revision 1156)
+++ dlfcnh.inc (working copy)
@@ -3,10 +3,10 @@
RTLD_NEXT = Pointer(-1);
RTLD_DEFAULT = nil;
-function dlopen(__file:Pchar; __mode:longint):pointer;cdecl;external clib name
'dlopen';
-function dlclose(__handle:pointer):longint;cdecl;external clib name 'dlclose';
-function dlsym(__handle:pointer; __name:Pchar):pointer;cdecl;external clib
name 'dlsym';
-function dlvsym(__handle:pointer; __name:Pchar;
__version:Pchar):pointer;cdecl;external clib name 'dlvsym';
+function dlopen(__file:Pchar; __mode:longint):pointer;cdecl;external dllib
name 'dlopen';
+function dlclose(__handle:pointer):longint;cdecl;external dllib name 'dlclose';
+function dlsym(__handle:pointer; __name:Pchar):pointer;cdecl;external dllib
name 'dlsym';
+function dlvsym(__handle:pointer; __name:Pchar;
__version:Pchar):pointer;cdecl;external dllib name 'dlvsym';
function dlerror:Pchar;cdecl;external clib name 'dlerror';
type
@@ -19,7 +19,7 @@
dli_saddr : pointer;
end;
-function dladdr(__address:pointer; __info:PDl_info):longint;cdecl;external
clib name 'dladdr';
+function dladdr(__address:pointer; __info:PDl_info):longint;cdecl;external
dllib name 'dladdr';
{ -
Borland compatibility types
@@ -29,5 +29,5 @@
TDLInfo = Dl_info;
PDLInfo = ^TDLInfo;
-function dladdr(__address:pointer; var __info: Dl_info):longint;cdecl;external
clib name 'dladdr';
+function dladdr(__address:pointer; var __info: Dl_info):longint;cdecl;external
dllib name 'dladdr';
Index: libc.pp
===
--- libc.pp (revision 1156)
+++ libc.pp (working copy)
@@ -9,6 +9,8 @@
Const
clib = 'c';
+ dllib = 'dl';
+ cryptlib = 'crypt';
threadslib = 'pthread';
{$i glue.inc} // C to Pascal type mappings
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Libc patch 2
Ales Katona wrote:
Apply after the 1st one. This patch fixes crypto function in libc unit.
Ales
Index: crypth.inc
===
--- crypth.inc (revision 1156)
+++ crypth.inc (working copy)
@@ -1,9 +1,9 @@
{ defined earlier in unistdh.inc...
-function crypt(__key:Pchar; __salt:Pchar):Pchar;cdecl;external clib name
'crypt';
-procedure setkey(__key:Pchar);cdecl;external clib name 'setkey';
-procedure encrypt(__block:Pchar; __edflag:longint);cdecl;external clib name
'encrypt';
+function crypt(__key:Pchar; __salt:Pchar):Pchar;cdecl;external cryptlib name
'crypt';
+procedure setkey(__key:Pchar);cdecl;external cryptlib name 'setkey';
+procedure encrypt(__block:Pchar; __edflag:longint);cdecl;external cryptlib
name 'encrypt';
}
type
Pcrypt_data = ^crypt_data;
@@ -20,9 +20,9 @@
initialized : longint;
end;
-function crypt_r(__key:Pchar; __salt:Pchar;
__data:Pcrypt_data):Pchar;cdecl;external clib name 'crypt_r';
-procedure setkey_r(__key:Pchar; __data:Pcrypt_data);cdecl;external clib name
'setkey_r';
-procedure encrypt_r(__block:Pchar; __edflag:longint;
__data:Pcrypt_data);cdecl;external clib name 'encrypt_r';
+function crypt_r(__key:Pchar; __salt:Pchar;
__data:Pcrypt_data):Pchar;cdecl;external cryptlib name 'crypt_r';
+procedure setkey_r(__key:Pchar; __data:Pcrypt_data);cdecl;external cryptlib
name 'setkey_r';
+procedure encrypt_r(__block:Pchar; __edflag:longint;
__data:Pcrypt_data);cdecl;external cryptlib name 'encrypt_r';
{ -
Borland compatibility types
Index: dlfcnh.inc
===
--- dlfcnh.inc (revision 1156)
+++ dlfcnh.inc (working copy)
@@ -3,10 +3,10 @@
RTLD_NEXT = Pointer(-1);
RTLD_DEFAULT = nil;
-function dlopen(__file:Pchar; __mode:longint):pointer;cdecl;external clib name
'dlopen';
-function dlclose(__handle:pointer):longint;cdecl;external clib name 'dlclose';
-function dlsym(__handle:pointer; __name:Pchar):pointer;cdecl;external clib
name 'dlsym';
-function dlvsym(__handle:pointer; __name:Pchar;
__version:Pchar):pointer;cdecl;external clib name 'dlvsym';
+function dlopen(__file:Pchar; __mode:longint):pointer;cdecl;external dllib
name 'dlopen';
+function dlclose(__handle:pointer):longint;cdecl;external dllib name 'dlclose';
+function dlsym(__handle:pointer; __name:Pchar):pointer;cdecl;external dllib
name 'dlsym';
+function dlvsym(__handle:pointer; __name:Pchar;
__version:Pchar):pointer;cdecl;external dllib name 'dlvsym';
function dlerror:Pchar;cdecl;external clib name 'dlerror';
type
@@ -19,7 +19,7 @@
dli_saddr : pointer;
end;
-function dladdr(__address:pointer; __info:PDl_info):longint;cdecl;external
clib name 'dladdr';
+function dladdr(__address:pointer; __info:PDl_info):longint;cdecl;external
dllib name 'dladdr';
{ -
Borland compatibility types
@@ -29,5 +29,5 @@
TDLInfo = Dl_info;
PDLInfo = ^TDLInfo;
-function dladdr(__address:pointer; var __info: Dl_info):longint;cdecl;external
clib name 'dladdr';
+function dladdr(__address:pointer; var __info: Dl_info):longint;cdecl;external
dllib name 'dladdr';
Index: libc.pp
===
--- libc.pp (revision 1156)
+++ libc.pp (working copy)
@@ -9,6 +9,8 @@
Const
clib = 'c';
+ dllib = 'dl';
+ cryptlib = 'crypt';
threadslib = 'pthread';
{$i glue.inc} // C to Pascal type mappings
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hups sorry, it's a clear patch, apply only the second one.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpNanoSleep vs Select()
Hello, I'd like to ask why Sleep() function in unix world uses Select() instead of fpNanoSleep()? Is there a particular reason? After a somewhat riggid discussion on the channel yesterday I came up testing threading using sleep() and nanosleep(). The difference in speed is huge. I'm prepared to make a patch for Sleep() to use NanoSleep but I'd like to know if there are any reasons again such approach. Thanks Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Micha Nelissen wrote: Marc Weustink wrote: BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); Or: code type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); /code And: code type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); /code Combining some of the wiki ideas, and has no evil characters :-). Probably TFieldDefs adds functionality to TCollection, but it was first example I came up with. Implementation of TGenericCollection can be compiled as if (T: TCollectionItem) were used. Would this solve the circular dependency ? It seems so to me, because one knows at least as much as in current implementation of these classes, but I'm no compiler engineer. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Are the () required? Why not TSomeList = TGenericList of Pointer; ? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias Sky will reign fire: procedure (var T); begin // generic or not?? end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Threads patch PS
I forgot to mention it's against 2.0.1 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 patch for threads
Florian Klaempfl wrote:
Aplied, also for wince and netware.
Sorry, it seems I broke Unix and all non-stdcall-using platforms. This
patch fixes that(apply after the first one) but it only {ifdefs}
windows, not netware or others, so please add those as necessery.
Ales
Index: rtl/inc/threadh.inc
===
--- rtl/inc/threadh.inc (revision 1652)
+++ rtl/inc/threadh.inc (working copy)
@@ -14,6 +14,12 @@
**}
+{$ifndef win32}
+ {$define cc = //}
+{$else}
+ {$define cc = stdcall;}
+{$endif}
+
const
{$ifdef mswindows}
{ on windows, use stack size of starting process }
@@ -26,7 +32,7 @@
type
PEventState = pointer;
PRTLEvent = pointer; // Windows=thandle, other=pointer to record.
- TThreadFunc = function(parameter : pointer) : ptrint; stdcall;
+ TThreadFunc = function(parameter : pointer) : ptrint; {$cc}
trtlmethod = procedure of object;
// Function prototypes for TThreadManager Record.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Thread REVERT
Please remove ALL of my win32 thread patches(not the stacksize ones tho). Thanks to neli, I now know that ThreadFunc is not called directly by the OS, but my ThreadMain which already IS stdcall. My bug with threads was actualy cause by a -Ct (check stack) switch which in win32 always causes a runtime error 202 (stack overflow) because of the default value for stack size which is 0. So to sum it up, no patches required, bug is not a bug but a feature(the feature should get fixed IMO but I have no idea how stack checking works) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Thread REVERT
What about simply disabling such -Ct compiler switch (with nice error message) under Windows ? Or maybe it should do nothing under Windows ? Regards Boguslaw Brandys I have no idea how -Ct works. It seems there are also report(by Pavel to be more precise) that -Ct causes problems with threads in Linux too(Pavel uses his own thread manager so who knows..). Unless someone can explain to me how the stack checker knows the right size of stack it should be a rule to turn it off with threads. I'm actualy not sure wether -Ct works ok as-is. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Thread REVERT (Ales Katona)
Thomas Schatzl wrote: From: Ales Katona [EMAIL PROTECTED] What about simply disabling such -Ct compiler switch (with nice error message) under Windows ? Or maybe it should do nothing under Windows ? I have no idea how -Ct works. It seems there are also report(by Pavel to be more precise) that -Ct causes problems with threads in Linux too(Pavel uses his own thread manager so who knows..). Unless someone can explain to me how the stack checker knows the right size of stack it should be a rule to turn it off with threads. I'm actualy not sure wether -Ct works ok as-is. Ales Unfortunately the stack checker doesn't know the right size of the stack (yet; due to similar problems I am working on that at atm). It assumes that the stack is of fixed size, stored in the global stacklen (or so) variable. When stack checking is enabled, the compiler generates some extra code in the function prolog which checks whether the current stack pointer, decreased by the amount of stack space this method requires and some safety margin, is below the bottom of the stack (a value calculated at program start from the initial stack pointer, and the stacklen contents). If this is the case, it gives a RTE 202. Problems with that: * the __stacklen variable is a predetermined (at compile time) fixed value * the safety margin is quite high, e.g. 16k, which immediately RTEs in threads, because their default stack size is quite low (= 16k...). I hope this answers your question. Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Thanks, yes it does and it also is a valid point to turn it off with threads. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
[EMAIL PROTECTED] wrote: You stated that we could know already what the delphi-syntax will be, if they add generics over two years. But we can't, since we don't know what 'pascal-styled' way they will choose. I would say that a pascal-way is adding the 'interface' keyword. Like in array's and such. This is already mentioned. The chances that Borland will choose another pascal-styled-syntax is huge. Besides of that, I don't find that delphi-incompatibility is a no-go-area. Especially if we (or they - the core team) are the first ones who implement this feature. And incompatibilities can be solved in Delphi mode. And in general: If we can do something better then Delphi, I choose for loosing the compatibility. Joost. You have my absolutly insignificant voice on that one. I fully agree. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] PR advancement
I think the simplest and perhaps most important change to get better PR for both Lazarus and FPC is the web page. It needs to be more wow style. News have to be a bit propagandistic. A FAQ is IMHO required with first questions like: 1. Is Free Pascal/Lazarus really free? 2. Can I use Free Pascal/Lazarus for commercial development? 3. Are there any real world applications made with Free Pascal/Lazarus? 4. Why should I use Free Pascal/Lazarus? 5. Isn't Free Software equal to crappy software? etc. In other words, FAQ for managers. I'm not saying you should scrap the old one. Just put the technical questions a bit lower. I can write a few FAQ entries in plain text but I can't make a dynamic webpage(perhaps CGI? :) ) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR advancement
Michalis Kamburelis wrote: Ales Katona wrote: 1. Is Free Pascal/Lazarus really free? The freeness of FreePascal is already advertised in a lot of places, including the very name FreePascal. Current FAQ mentions (more than once) that the compiler is GPLed. I don't think there's any need to advertise this more. Perhaps 2. Can I use Free Pascal/Lazarus for commercial development? This is the 4th question of current FAQ. And I assume that you actually wanted to say closed source, this is not the same thing as commercial. If you look at forums and mailing lists, NO people DON'T get it. You need to explicitly tell them YES YOU CAN STATIC LINK WITH OUR ENHANCED LGPL. Honestly the thing in the FAQ is good for lawyers only. 3. Are there any real world applications made with Free Pascal/Lazarus? I guess that even a manager is able to type fpc or lazarus into google. And he'll find a bunch of fanboy websites. 4. Why should I use Free Pascal/Lazarus? Which is horribly outdated and utterly useless. Also it only specializes on comparing FP dialect of Pascal with other languages. One half of currently listed advantages is basicly a pissing contest against C/C++ and the other is saying we got OOP/other features too you know. 5. Isn't Free Software equal to crappy software? Of course it's total crap. But we're just a bunch of poor windoze lusers and we can't do anything better. So we devote our full time to maintain this miserable piece of software, this ugly webpage and this lousy FAQ. I'm sorry, I could not resist to say this. :) Seriously: I think that it's obvious (even to the managers) that if you maintain a FAQ for some software, then you don't think it's crappy. I'll add a FAQ to my page and see. The FAQ on FPC currently is relativly good for technical questions. But some basic questions asked over and over on forums and lists simply aren't there or are answered inapropriatly(for the masses..) Also note I speak for BOTH projects. IMHO they should merge a bit more as Lazarus requires a certain RTL of compiler to be able to produce things. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR advancement
Reading FPC and Lazarus mailing lists, and I don't see such problems. And I understood the FAQ, even though IANAL. There's a text Read again. Lazarus list had a very long discussion about LCL and LGPLv2 It is therefore possible to create closed source or proprietary software using Free Pascal. I think that this is even more explicit (and understandable to non-programmers) than your proposed Yes you can static link with our enhanced LGPL. Perhaps, but people evidently don't get it. So what answer would you propose for the FAQ question Are there any real world applications made with Free Pascal/Lazarus ? A huge list of every program that was ever compiled with FPC ? A short list of chosen projects ? Who will decide and maintain the list of most bright projects developed using FPC+Lazarus ? This selection is done already. See news on main fpc page. Then propose a better text / feature list for Advantages page... I will try my best. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR advancement
So I fully agree to Ales that the FPC homepage needs a wow style. Despite I do like clear, simple homepages I don't think that this gives us good PR. Without offending Michael and others for their effort creating and maintaining the website, I think these pages induce the impression that FPC is a tiny project, has unreliable release cycles and progress, it is just from hobbyists for their own pleasure and FPC is only used by some frugal enthusiasts. I wouldn't say it needs to be complicated or flash-full. I personaly hate the full-of-flash crappy slow sites no matter how cool they look. But the current page simply looks like some 15 year old's homepage made as school project. Nothing personal here, I mean the whole thing is HUGE and there's really nice technical functionality but the look is simply ugh. It needs a bit more edgy and colorful look. I think word can make it better: CSS The main disadvantage of the current website are the bad navigation scheme and the simplistic layout. I'd therefore propose to take the following steps: 1. Collect what information should be on the main page: focus on managers and busy visitors, but do not forget on technicians, enthusiasts, purists. Do not classify this list, don't concentrate on structure, hierarchy, ..., just collect. 2. sort this list, give it a structure 3. work out a navigation scheme of the new website (from the structured list) 4. work out a design and look-and-feel for the new website which is clear, stylish, wow, but not loaded. 5. bring structure, content and design togehter 6. enjoy and watch interrests Ok, this is a very simple path, I'm not sure it if works and if enough man power can be raised. OTOH I'm sure most ideas for the hard part (1) have already been said and/or can be found on the current web site. Any suggestions, comments, ideas? Bye Hansi Agreed to an extent. Some things are good as they are only change required is the style. Some are truly hidden behind not-so-logical paths(links). This is all a huge IMHO ofcourse, by no means do I wish to undermine the works of all people who already did what is done for FREE. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR: What sites to spam for 2.0.2 release?
Don't forget to tell PGD. Why is OSNews and /. out ? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Benchmark for FreePascal
Marco van de Voort wrote: (small post note in this discussion: a customer complained that his app was a lot slower (till 3 times) with D2006/FastMM. I'm still investigating, and it seems that somehow FastMM must more often copy when reallocating than the old MM for large blocks (big as in the 100kbs or even MB size) ) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Did I get it right that the new FastMM in new delphi is 3 times slower than the old delphi one (which is on par with FPC AFAIK)? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch for bug #4641
This isn't exactly a patch but a changed errors.pp file.
It's for all BSDs (AFAIK, it seems even darwin has errors this way) so
someone from rtl maintainers needs to decide how to split errors.pp (the
current one in rtl/unix is Linux specific)
Ales
{
This file is part of the Free Pascal run time library.
Copyright (c) 1999-2000 by the Free Pascal development team.
See the file COPYING.FPC, included in this distribution,
for details about the copyright.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY;without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
**}
Unit errors;
Interface
uses strings;
const
sys_errn=93;
sys_errlist:array[0..sys_errn-1] of pchar = (
'Success', { 0 }
'Operation not permitted', { EPERM }
'No such file or directory',{ ENOENT }
'No such process', { ESRCH }
'Interrupted system call', { EINTR }
'I/O error',{ EIO }
'No such device or address',{ ENXIO }
'Arg list too long',{ E2BIG }
'Exec format error',{ ENOEXEC }
'Bad file number', { EBADF }
'No child processes', { ECHILD }
'Resource deadlock avoided', { EDEADLK was EAGAIN }
'Out of memory',{ ENOMEM }
'Permission denied',{ EACCES }
'Bad address', { EFAULT }
'Block device required',{ ENOTBLK }
'Device or resource busy', { EBUSY }
'File exists', { EEXIST }
'Cross-device link',{ EXDEV }
'No such device', { ENODEV }
'Not a directory', { ENOTDIR }
'Is a directory', { EISDIR }
'Invalid argument', { EINVAL }
'File table overflow', { ENFILE }
'Too many open files', { EMFILE }
'Not a typewriter', { ENOTTY }
'Text (code segment) file busy',{ ETXTBSY Text file busy. The
new process was
a pure procedure (shared
text) file which was
open for writing by another
process, or file
which was open for writing
by another process,
or while the pure procedure
file was being
executed an open(2) call
requested write access
requested write access.}
'File too large', { EFBIG }
'No space left on device', { ENOSPC }
'Illegal seek', { ESPIPE }
'Read-only file system',{ EROFS }
'Too many links', { EMLINK }
'Broken pipe', { EPIPE }
'Math argument out of domain of func', { EDOM }
'Math result not representable',{ ERANGE }
'Resource temporarily unavailable',{ EAGAIN }
'Operation now in progress', { EINPROGRESS }
'Operation already in progress', { EALREADY }
// ipc/network software -- argument errors
'Socket operation on non-socket',{ ENOTSOCK }
'Destination address required', { EDESTADDRREQ }
'Message too long', { EMSGSIZE }
'Protocol wrong type for socket', { EPROTOTYPE }
'Protocol not available', { ENOPROTOOPT }
'Protocol not supported', { EPROTONOSUPPORT }
'Socket type not supported', { ESOCKTNOSUPPORT }
'Operation not supported', { EOPNOTSUPP }
'Protocol family not supported', { EPFNOSUPPORT }
'Address family not supported by protocol family', { EAFNOSUPPORT }
'Address already in use',{ EADDRINUSE }
'Can''t assign requested address', { EADDRNOTAVAIL }
// ipc/network software -- operational errors
'Network is down',{ ENETDOWN }
'Network is unreachable', { ENETUNREACH }
'Network dropped connection on reset', { ENETRESET }
'Software caused connection abort', { ECONNABORTED }
'Connection reset by peer', { ECONNRESET }
'No buffer space available',{ ENOBUFS }
'Socket is already connected',{ EISCONN
[fpc-devel] Errors patch AGAIN
This one is actualy a patch. Apply in root fpc dir. You need to copy
linux-errors.inc and bsd-errors.inc to rtl/linux/errors.inc and
rtl/bsd/errors.inc
NOTE: I have no idea if Linux and BSD encompass all required include
dirs for rtl/unix includes. If not copy the linux one to the others too
(probably not right but someone from those systems will have to change it)
Ales
Index: rtl/unix/errors.pp
===
--- rtl/unix/errors.pp (revision 2114)
+++ rtl/unix/errors.pp (working copy)
@@ -18,140 +18,7 @@
uses strings;
-const
- sys_errn=125;
- sys_errlist:array[0..sys_errn-1] of pchar = (
-'Success', { 0 }
-'Operation not permitted', { EPERM }
-'No such file or directory',{ ENOENT }
-'No such process', { ESRCH }
-'Interrupted system call', { EINTR }
-'I/O error',{ EIO }
-'No such device or address',{ ENXIO }
-'Arg list too long',{ E2BIG }
-'Exec format error',{ ENOEXEC }
-'Bad file number', { EBADF }
-'No child processes', { ECHILD }
-'Try again',{ EAGAIN }
-'Out of memory',{ ENOMEM }
-'Permission denied',{ EACCES }
-'Bad address', { EFAULT }
-'Block device required',{ ENOTBLK }
-'Device or resource busy', { EBUSY }
-'File exists', { EEXIST }
-'Cross-device link',{ EXDEV }
-'No such device', { ENODEV }
-'Not a directory', { ENOTDIR }
-'Is a directory', { EISDIR }
-'Invalid argument', { EINVAL }
-'File table overflow', { ENFILE }
-'Too many open files', { EMFILE }
-'Not a typewriter', { ENOTTY }
-'Text (code segment) file busy',{ ETXTBSY Text file busy. The new process was
-a pure procedure (shared text) file which was
-open for writing by another process, or file
-which was open for writing by another process,
-or while the pure procedure file was being
-executed an open(2) call requested write access
-requested write access.}
-'File too large', { EFBIG }
-'No space left on device', { ENOSPC }
-'Illegal seek', { ESPIPE }
-'Read-only file system',{ EROFS }
-'Too many links', { EMLINK }
-'Broken pipe', { EPIPE }
-'Math argument out of domain of func', { EDOM }
-'Math result not representable',{ ERANGE }
-'Resource deadlock would occur',{ EDEADLK }
-'File name too long', { ENAMETOOLONG }
-'No record locks available',{ ENOLCK }
-'Function not implemented', { ENOSYS }
-'Directory not empty', { ENOTEMPTY }
-'Too many symbolic links encountered', { ELOOP }
-'Operation would block',{ EWOULDBLOCK }
-'No message of desired type', { ENOMSG }
-'Identifier removed', { EIDRM }
-'Channel number out of range', { ECHRNG }
-'Level 2 not synchronized', { EL2NSYNC }
-'Level 3 halted', { EL3HLT }
-'Level 3 reset',{ EL3RST }
-'Link number out of range', { ELNRNG }
-'Protocol driver not attached', { EUNATCH }
-'No CSI structure available', { ENOCSI }
-'Level 2 halted', { EL2HLT }
-'Invalid exchange', { EBADE }
-'Invalid request descriptor', { EBADR }
-'Exchange full',{ EXFULL }
-'No anode', { ENOANO }
-'Invalid request code', { EBADRQC }
-'Invalid slot', { EBADSLT }
-'File locking deadlock error', { EDEADLOCK }
-'Bad font file format', { EBFONT }
-'Device not a stream', { ENOSTR }
-'No data available',{ ENODATA
[fpc-devel] Errors patch, c'est la vie
Ok a bit strange topic.. this is the latest gratest version. The archive contains rtl subdir with added .inc files for platforms I'm sure of and the diff to change errors.pp. Someone who has access to other platforms will have to fill in their .inc files. Ales errors.tar.gz Description: application/gzip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for unit sockets
Marco van de Voort wrote: SocketError should be a threadvar, I think Socketerror is legacy. Use fpgeterrno (or errno) to get the error. 1.0.x had no threadsupport ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I use socketerror on unix still. Altho luckily I don't use threads anymore. The unix fp naming convention is a bit sad. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for unit sockets
I propose to make SocketError a function with hidden OS specific get-ers. This will make it threadsafe and cross-platform. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] using sockets on linux and win32
Stefan Kisdaroczi wrote: Hi, im trying to use sockets in a unit which should work on linux and win32. I use the sockets unit, but for things like SOL_SOCKET, TTimeval (for setsockopt), SO_RCVTIMEO, fpgeterrno I finally had to use unix,unixtype,baseunix. This on Linux. Now I try to compile it on windows: It seems I need SocketError and not fpgeterrno ( there is a thread about that some days old ). But where do I find SOL_SOCKET for windows? using winsock did not help. I searched for a good example using google, searched the fpc docs... there seems to be a lot of outdated information. And now the question: Has someone an uses-clause compatible with linux and windows for an app really using sockets and not only for a simple hello socket? thank you kisda ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Hello, you need to use WinSock in windows and get error with WSAGetError (IIRC) function from the winsock unit. Note that the winsock unit in FFC RTL is winsock1 (deprecated, obsolete). I'd strongly advise for a Winsock2 unit (there are some flying around in the net). Also not ment as an advertisment but I've made a networking library which works cross platform on windows and unix including PPC platform. You can get it at http://members.chello.sk/ales If nothing else you can view the source and see how I coped with cross-platform networking problems. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FreeBSD/kqueue
These files add kqueue to the FreeBSD rtl. the new FreeBSD.pas file will need to be put in rtl/freebsd dir. I think the kqueue.inc files should be in common BSD dir as 3 out of 4 major bsds (darwin being one) now support it. demo-kqueue1.pas is a simple process watching example. Ales P.S: the 2 syscall numbers should be added to freeBSD syscalls freebsd.tar.gz Description: application/gzip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
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? It should be split into include which belong to BSD and specific OS units which belong to specific OS dirs which use those includes. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FreeBSD/kqueue
It will force users into {$ifdefs} anyhow because older versions
(especialy macosX where it's only since 10.3) won't work with it.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [Fwd: Kqueue update + Sendfile support for FreeBSD]
Try 2... ---BeginMessage--- This is an update kqueue and a sendfile support for freeBSD with example. Kqueue will run on all BSDs (I've added other syscall_nrs for it) but sendfile is specific to FreeBSD. Ales kqueue_sendfile.tar.gz Description: application/gzip ---End Message--- ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] lNet in packages
I was wondering if I could put lNet library (for those who don't know, go to http://members.chello.sk/ales ) into packages. What do you think? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] lNet in packages
I'll be honest to say that I don't care much if it's in FCL or Packages/Bare or Extra but the fp is not going to happen. Names are already done and they are used, I can't rename the API. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] samplecfg patch
This patch makes samplecfg use $fpcversion instead of hard versioning. Ales P.S: it works even with primitive /bin/sh on bsd so I guess nothing was broken Index: compiler/utils/samplecfg === --- compiler/utils/samplecfg (revision 2478) +++ compiler/utils/samplecfg (working copy) @@ -65,6 +65,10 @@ echo Found libgcc.a in $GCCDIR GCCDIR=-Fl$GCCDIR fi + +# set right path to FPC with $fpcversion +FPCPATH=`dirname $1`/\$fpcversion + # Write the file echo Writing sample configuration file to $thefile cat EOFCFG $thefile @@ -195,16 +199,16 @@ # path to the messagefile, not necessary anymore but can be used to override # the default language -#-Fr$1/msg/errore.msg -#-Fr$1/msg/errorn.msg +#-Fr$FPCPATH/msg/errore.msg +#-Fr$FPCPATH/msg/errorn.msg # searchpath for includefiles #-Fi/pp/inc;/pp/rtl/inc # searchpath for units and other system dependent things --Fu$1/units/\$fpctarget --Fu$1/units/\$fpctarget/* --Fu$1/units/\$fpctarget/rtl +-Fu$FPCPATH/units/\$fpctarget +-Fu$FPCPATH/units/\$fpctarget/* +-Fu$FPCPATH/units/\$fpctarget/rtl #-Fu~/fpc/packages/base/*/units/$fpctarget;~/fpc/fcl/units/$fpctarget;~/fpc/rtl/units/$fpctarget # searchpath for libraries ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide + MSEgui - FPC Wiki
Looks like a pretty cool widgetset for lazarus to me... Hi, would the FPC team mind if we'd use the FPC Wiki to document the use of the MSEGui library and the Ide ? It is completely written in pascal, voiding the need to endlessly update bindings to gtk/qt etc :-) kind regards, Den Jean ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Type definition
Paul Davidson wrote: If there compelling reason why type definitions cannot be included in class/object definitions? Make it mode FPC to keep folks happy :) Quite often a type is defined in INTERFACE part, but only used within class/object defined in same unit. 1) This means that type is public. This is not always good thing in OOese. 2) Unit must be specified in child's child's USE list. P Davidson Corax Networks Inc. http://CoraxNetworks.com IMPORTANT NOTICE: This message is intended only for the use of the individual or entity to which it is addressed. The message may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify Corax Networks immediately by email at [EMAIL PROTECTED] Thank you. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel I second this request. Throw in const fields too.. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS aware RTL proposal
First: only Linux has the main problem. BSD never renumbers ABI calls, newer abi calls have a different prototype. No even BSD adds new stuff from time to time, like kqueue, altho that's older. As long as only syscall nrs change. This rarely happens. Usually something gets 64-bit, or has an extra param, or different structure etc. Well yes but there are other implications, see winsock1 vs winsock2 problem in windows. That is a nice trick, but IMHO only important for that hand full of problematic calls that are urgently needed but recently added. Yes I agree. ABI compat is way more than using the right syscall nrs. Indeed. That's why I included the libc parts too. It just illustrates some uses. * more complicated, thus more bugprone. * case that this (except libc trick) actually saves anybody is IMHO near zero * All binary compability must be prepared in the binaries that go onto the field. That makes them legacy binaries anyway. So in short: yes, some of the techniques are usefull if there indeed is such huge problem with dynlinking, that can't be solved with some form of lazy linking. But the workaround should be kept to those functions _only_, and only if there is a real chance that anything actually might go wrong. Yes indeed. I should perhaps clearly state that it shouldn't be the standard for all units etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS aware RTL proposal
This is manifestly wrong: Sure, there are new syscall numbers in linux, but the old numbers still work as they always have. Proof: The current set of numbers already works since 10 years. I'm not saying you'll have the latest features with the old numbers, but that is irrelevant. Windows has the same issue. For almost each and every OS XYZ call, there is a XYZex call. It's normal if you want to maintain backward compatibility, but also want to give new version numbers. IMHO all we need to do is to decide which call (number) we want to use, and warn people that some things may not work on older systems. Michael. Yes but this is more than about syscalls. Ofcourse I didn't mean to say that the whole RTL should be done this way but stuff like winsock1/2 and epoll/kqueue calls are a nice example IMO. + it also fixes FPC_USE_LIBC for those things. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS aware RTL proposal
Tomas Hajny wrote: That's the main point, I guess. As it is now, we have to decide and either sacrifice the new features, or compatibility with slightly older platforms. My understanding is that the proposal of Ales was related to exactly this situation. If I understand it correctly, his suggestion basically allows to extend the support for older platforms (i.e. keeping your binaries working properly on those platforms) while still supporting the new functionalities if they are available (i.e. if running on a newer system version). It's obvious that this approach cannot work correctly under all circumstances. In some cases there's just no fallback solution available, so you might end up with an exception while trying to use the binary on some old system version. However, your application can still handle this situation and present it to the end-user in friendly way (e.g. notifying him of this fact, but still allowing him to use the other functionalities not relying on the particular new API call). Tomas Yes that's the idea. IMHO the question is not if such a solution is the right thing to do in these situations but if it's POSSIBLE to do. I've looked at the uname syscall (which logicly cannot be modernized this way and there's no need to either). I must say POSIX sux hard. The people who made this standard could save everybody lots of trouble by not doing it. As it stands out, I don't think there's any reliable way of finding out a version of OS in the unix world. They simply didn't bother with format specification. Even if a parser is made which will fall back to compiled-by-version if the numbers don't make sense, there's still a possibility that you end up parsing it wrong thinking it's right, making the resulting binary malfunction. This is the biggest problem I see. I guess Unix won another round of Stupidity vs ABI compaibility. 10:0 so far. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS aware RTL proposal
Daniël Mantione wrote: I don't like to do the abstraction at the syscall level, but one level higher, i.e. the Tstream implementation. The reason is that the operating system abstraction happens at this level: - OS abstraction wis present here. - Emulating missing system calls is often much more inefficient than a higher level workaround. I never wanted to emulate missing syscalls. Adding an extra layer of abstraction without a good technical reason greatly increases the danger of overdesign and code bloat. The reason is libfprtl.so Daniël ___ 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
Re: [fpc-devel] OS aware RTL proposal
Michael Van Canneyt wrote: How does this make it a reason ? libfprtl will always be specific to the distribution it was compiled on. If tuned, it should be tuned to that system. Just like libc or any library close to the system is. Don't try to copy a binary libc.so from a SuSE to a Fedora system, it won't work. Just like you shouldn't copy kernel32.dll from Windows XP to Windows 2003. I don't think this is feasible. It would be if you'd get it into those distroes but people will want to take their own 1mb libfprtl.so with them rather than copy 30mb fpc on various distroes with their apps. Ofcourse the question is, do we want to utilize libfprtl.so at all? How do we want to cope with new features in OSes? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OS aware RTL proposal
Daniël Mantione wrote: You can safely use the new select; it is at least present since Linux 2.2 and more likely 2.0. Daniël Hmm I'll update the RTL then. Thanks Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unix sockets for Windows
Alexander Todorov wrote: Hello, I have an application that uses TCP sockets nut it is going to be changed with UNIX sockets. Can you point me to some easy and clean approach how to emulate UNIX sockets for Windows. The only thing I can think of is using named pipes and encapsulate the functionality in some class. Any other alternative are welcome. Thanks. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel You could use lNet. It's an asynchronic non-blocking, single-threaded OOP net lib for FPC. You can find it at http://members.chello.sk/ales (svn version is in fpcprojects branch on FPC svn). If nothing else, you can see how I abstracted socket calls to get both windows and unix working. Ales P.S: look in lnet.pas and lcommon.pas. The second one abstracts calls like select and FD_SET stuff. The first one has some ifdefs on recv and send. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gtk1 linklib directive under FreeBSD
On ut , 2006-05-09 at 09:35 +0200, Mattias Gaertner wrote:
I heard that the gtk1 libs under FreeBSD are libglib-12.so, libgdk-12.so and
libgtk-12.so.
But at the moment the linklib directive for FreeBSD defines
{$ifdef FreeBSD}
gtkdll='gtk12';
{$linklib gtk12}
without the '-'.
Can someone with FreeBSD please test if changing
packages/extra/gtk/gtk/gtk.pp
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/glib/glib.pp
fixes the issue.
Mattias
___
A but old I know but I think we should remake the glib and friends
unit to lazy linkers. Anyone using them uses libc anyhow (which = ld in
fBSD) so once they use lazy linking, a simple try the old name, then
the new name in initialization section would fix this and other future
freeBSD-porters fuckups.
I tried converting them, I even talked Loesje into giving me his tool
but I didn't find the time for it yet. If anyone has anything which can
simply do this, or has the time to do it manualy it'd be great.
Ales
P.S: I'm ofcourse willing to test it once it's done/ and or help with
the init part.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
Having same function names as parameter names per se isn't a biggy but
the biggest problem is:
TFirst = class
protected
FFirst: Integer;
public
property First: Integer read FFirst write FFirst;
end;
TTest = class(TFirst)
FSomething: Integer;
public
procedure DoWithFirst(a, First: Integer);
end;
implementation
procedure TTest.DoWithFirst(a, First: Integer);
begin
First:=a; // ???
FSomething:=First; // ???
end;
Ofcourse the intention was setting FSomething to value of argument First
and setting FFirst to value of First. It CAN be achieved with FFirst
or self.First but it's just a stupid example of how easily you can
overlook things especialy if some parts are hidden in another unit
somewhere in an ancestor.
Also notice that in mode delphi there's not a single warning about this.
And believe me things like this CAN happen and will take you 3 days to
find out...
I name my arguments aName since this incident and not because
{$objfpc}...
PS: there are worse cases but I can't remember a better example now
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
Ales, there is _no_ confusion here. Oh believe me there is. Especialy if you're writing just some little overriden method in a class which doesn't even have property visible anymore. You don't think about it and bang, error and a very neatly hidden one at that. It's not that I don't know what the assignments mean, it's that when you write code in haste (and 99% of the time you do, unless you write new original stuff) you don't think much about it and sometimes do these things. I'd atleast like to have warning or at minimum hints point these things out. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
Here's the better example:
TTest = class
protected
FField: Integer;
public
procedure Helper(Field: Integer);
property Field: Integer read FField write FField;
end;
{ TTest }
procedure TTest.Helper(Field: Integer);
begin
with Self do
Field:=Field;
Writeln(Self.Field);
Writeln(Field);
end;
It's rather idiotic but there are implications..
Ales
P.S: the result is:
0
5
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Old sockets stuff and SSockets...
I'm currently about to fix certain issues with old sockets functions. I'm talking about Accept and Connect functions with Text parameters. These are currently only present in win32 sockets and are basicly a leftover from an old idea gone wrong. I want to remove them but if someone feels that that's a real requirement for them to stay (remember, currently they remain only in windows sockets) tell me. Secondly there's some new SSockets bugreps/feature requests come up. I understand MvC made SSockets right? Is the unit to be considered atleast viable? I didn't look much at it but from what I hear it's rather old. I'm not sure what to do about SSockets tbh (wether to update/accept user extentions and features or tell them it's deprecated or even delete the thing) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Threads and alot of crap
I've had the honor of looking at current TThread/pthreads/cthreads
implementation in unix (FreeBSD to be precise) and found it extremely
bad.
Not to criticize, I'm here to ask for permission/toughts on adding a few
standard methods to TThreadManager.
I would like to add semaphore functions to it, to be able to use them in
Classes/TThread implementation. The reason for this is, that Classes is
compiled BEFORE pthreads and as such I cannot use pthreads directly (and
shouldn't for linking issues to libc) to implement threading in TThread.
I see basicly 3 approaches:
1. add semaphore/mutex functions to TThreadManager record
2. add a new semaphores record
3. move the TThread - threading specific functions out of tthread and
into a TThreadTThreadManager kind of thing. Eg: start thread with
this callback and such which are currently used in tthread.inc
Not sure which one is best..
Another thing.
I noticed that FreeBSD has 3 implementations of pthreads.
libpthread, Libc_r (reentrant) and libthr (1:1 kernel threads).
Currently fpc does some sort of automagical descision between libc and
libpthread. I think users should be able to specify this somehow.
I've cleaned up unices I know off old {$IFDEF Linux} but I also want to
add proper threading and remove the idiotic pipe/semaphore hack.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap
I've implemented the semaphores stuff (with a big bad bug, btw thanks Jonas for fixing). Right now I'm thinking about how to go next. The choices I see right now are: 1. Basicly just clean the current pthreads implementation, make sure types are not redefined in baseunix/unixtypes and pthreads etc. and be happy. 2. Add proper interface style pthreads with chosable (how is a question) backend lib (eg: freeBSD has 3 libs to which a pthread interface can link). There's also a choice #3 which is a complete threading design overhaul, but since that'd break old code I don't even consider it to be an option (I actualy do but I know you wouldn't). There's also still the hackish NPTL vs processes linux situation in TThread 2.4 vs 2.6 kernel. Not sure if it's considered clean enough now that pipes are gone or if that should be somehow addressed as well. If the linux tthread.inc could be cleaned, I'm 100% sure that tthread.inc could be merged into one file and put into rtl/unix. Write your ideas on the subject please. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap
On po , 2006-10-16 at 22:21 +0200, Daniël Mantione wrote: Op Mon, 16 Oct 2006, schreef Ales Katona: Write your ideas on the subject please. Short answer: Kick pthreads and use kernel threads. That's a nice idea but there are a few problems. Kernel threads for example in freeBSD require a scheduler in userlevel along with other userlevel stuff which is normaly implemented by one of the pthreads libs. This means we'd have to implement a full blown threading lib. I already added kse_ syscalls in freeBSD, if we want to go this route, these can be used to add proper SMP support to our threads, but I think using pthreads would be more sane. Daniël ___ 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
[fpc-devel] About the new package manager and networking
I've noticed Michael just added a wget package getter to the new packager. We already had a small discussion about using lNet in the new packaging system and it comes down to this: The packager needs pure fpc solution, which lNet now is, but won't be later (eg: when openSSL is added) I'm willing to add the required networking support to the packager if you guys tell me how. I mean, should I add lNet as a choice to package/base or fcl (not sure on which the packager actualy depends), or just inside the packager (eg: not in packages or fcl)? Personaly, I don't give a damn, I'm going to put lNet in packages/extra later and you need a stripped down version anyhow (eg: you don't need no openSSL support which forces a libc inside). Please don't start a flamewar about this, all I need to know if you want to use lNet for it, and how should I integrate it with the packager, no politics. -- Ales Katona [EMAIL PROTECTED] signature.asc Description: Toto je digitálne podpísaná časť správy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
I am already adding lnet and synapse support to fppkg. (to WST too, BTW ;) ) The wget is a fallback and proof of concept implementation. I've got a skeleton lNet/fppkg done localy now, will finish it tomorrow (and hopefuly find a way to test :) ) I've put lNet to fcl for local setup too but am open to suggestion. Btw, do you plan to add support for concurrent downloads and compiling while downloading later? -- Ales Katona [EMAIL PROTECTED] signature.asc Description: Toto je digitálne podpísaná časť správy ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Mutex!
There's no visible mutex interface in fpc right now. ATM all non-windows platforms have semaphores in the ThreadManager but the windows ones afaik don't. I think you can simply use CriticalSection instead of mutex to achieve what you need. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
- lnet (Ales, will you do this or not, I was actually waiting with my implementation?) I mailed you yesterday, I get this error trying to compile fppkg: Target OS: FreeBSD/ELF for i386 Compiling fprepos.pp Fatal: Can't find unit streamcoll Seems it's either not installed with fcl or there's a ppu mismatch so it looks for the source of it, didn't investigate yet (might be related to my lNet makefile changes perhaps). I do however have most things done as far as going without testing can be :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
On so , 2006-11-04 at 18:17 +0100, Marco van de Voort wrote: streamcoll My make all install on freebsd of this morning installed a unit streamcoll, so probably already fixed. I confirm, latest 2.1.1 works. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
Ok I tested it and I got an odd bug. When I writeln the buffer contents before writing them to the Dest stream, they are ok. But the resulting file is a garbage of xterm crap (mostly symbols) with exactly same size as the thing I downloaded (completly different data). I've no idea where to look, since writeln of the buffer looks 100% ok... Any idea what this might cause? I can commit it so you can test. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
Oh DOH thanks, it was the pointer stuff. Sometimes I wished fpc warned if you pass a pointer to untyped var. In any case pkglnet.pas is in now, I tested with the example and it worked. Only HTTP yet, but I'll do FTP ASAP. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] About the new package manager and networking
Wanted to ask, how should I process the URL? Should I also understand : as separator for port eg: http://www.shit.com:3030 ? Shouldn't this be parsed by some common function? Eg: procedure ParseURL(var Host, URI: string; var Port: string); This way we can save the hassle for all the backends and ensure same things will get understood. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
This is how lNet already works, no ? Where's the difference ? Indeed but it's only there because there's no other way, if I could just make it magicly work without CallAction I'd love to. You can't call callbacks in threads (you can but only in one thread, not between threads), and you can't magicly jump into execution if something happens, with the exception of OS signals (which use a hack in hardware afaik). So eg: if you want to do something every 1000ms, you could put a TThread based timer in, and make it Sleep(1000) and then call the code, but you must be sure that your main thread cannot have conflicts if this code is called at any time (eg: variable writes etc.). My point was that making a non-blocking or blocking event based main-loop-hooked mechanism for polling events is IMHO overkill in most cases (there are obvious exceptions but they need obvious specifics anyhow). It's easier for the user to simply check some times and see if the interval is hit and then call the function in his main loop mostly. IMHO ofcourse. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
Of course, because the common concept of a timer is as asynchronous as in multi-threaded or even interrupt. You're not seriously trying to work around that simple fact, do you? Actualy I am, because lNet is single-threaded non-blocking. As for general use, you can't do a Timer this way. You can't just put a TTimer in which works in it's own thread and then calls some callback in it's own thread, unless the users are informed, and-or the thing is locked and protected but you can't do that from within a TThread (because you don't know what the callback code is). Basicly a solution might be a thread which CriticalSections the callback part, but that still doesn't protect from wrong stuff: eg the user is in a loop and the code inside the OnTimer callback modifies something which breaks or loopies the loop. In case of gui TTimer this cannot happen because it's not threaded, so the userloop would first finish, then the user function returns and the main gui loop does it's stuff (this is my oh-so-complicated part, done by the gui). Vinzent. ___ 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
Re: [fpc-devel] CSuspendThread/CResumeThread
On ut , 2006-11-07 at 18:39 +0100, Jonas Maebe wrote: Hello, Does anyone see a problem with the following CSuspendThread/ CResumeThread implementations? function CSuspendThread (threadHandle : TThreadID) : dword; begin result := pthread_kill(threadHandle,SIGSTOP); end; function CResumeThread (threadHandle : TThreadID) : dword; begin result := pthread_kill(threadHandle,SIGCONT); end; Not sure how the signal handling is done per-thread in pthreads, will need to study on this. Those routines are currently empty, and called for *bsd/Darwin in case you try to tthread.suspend one thread from inside another one. FWIW, I guess Linux should be changed to also use the above (it currently uses the regular kill, which may have unintended side effects with NPTL). Indeed, linux should follow this principle too as any unix with pthreads. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
On st , 2006-11-08 at 07:35 +, Vinzent Hoefler wrote: On Tuesday 07 November 2006 16:10, Ales Katona wrote: As for general use, you can't do a Timer this way. Believe me, I can. :) You can't just put a TTimer in which works in it's own thread and then calls some callback in it's own thread, I even call the callback of another thread. :P No you can't. unless the users are informed, and-or the thing is locked and protected but you can't do that from within a TThread (because you don't know what the callback code is). Well, in Turbo Pascal I could write interrupt handlers the wrong way, without locking code/data in question and nobody cared about that simple fact. But if that's so complex: Why don't you use the usual synchronization stuff then to put the asynchronous timer event in a message queue using Synchronized? In case of gui TTimer this cannot happen because it's not threaded, so the userloop would first finish, then the user function returns and the main gui loop does it's stuff (this is my oh-so-complicated part, done by the gui). The problem in a portable general solution is that the may be no main gui loop and you can't just write one and force anyone to use it, right? So why don't you use Synchronized/CheckSynchronize (or whatever it's called) then? If you'd do that, the timer event callbacks would be queued and then executed in the context of the main thread. The user is only required to call CheckSynchronized from time to time, but because the accuracy of the time of execution of any associated handler is in the hands of the user anyway as long as you stick to a synchronous solution to avoid putting the burden of locking data to the programmer. As long as you don't want to implement real-time behaviour, I don't even see a problem in that. If the user decides to not call/execute any provided message event loop, the execution of the timer handler code will be deferred until the end of the universe anyway. This is exactly the oh-so-complex solution I use in lNet, and is basicly the only solution. Vinzent. ___ 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
Re: [fpc-devel] CSuspendThread/CResumeThread
Jonas currently fpc2.1.1 doesn't compile on 2.1.1 with:
rtl/units/i386-freebsd -di386 -dRELEASE ../unix/cthreads.pp
cthreads.pp(252,42) Error: Incompatible type for arg no. 1: Got
LongInt, expected Pointer
Note:
unixtypes thread_t = pointer
pthreads.inc thread_t (BSD and linux) = cInt {linux is Longint but
that's just bug)
pthreads.inc thread_t (Darwin) = pointer
Result of pthread_most = cInt
Result of ThreadManager.Killfunctions = DWord
This is some serious mess. First the threadmanager functions need to
return a signed result, second the pointer vs cInt stuff has to be
properly cleaned, remove thread_t from unittypes etc.
I'd do it myself but am asking for reasons against.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CSuspendThread/CResumeThread
A cleaner naming of problematic parts: 1. TThreadID is defined stand-alone not as a pthread_t, should be fixed. 2. TThreadHandler (the callback for resume, suspend) has result as DWord while posix stuff (pthread_kill etc.) usualy return cInt 3. in linux I saw pthreads functions return longint, I think this is also investigation worthy. Question about #1. How should this be handled? Not sure if I can use unixtypes in sysosh.inc... Question about #2. Well.. this is a tough nut? I suspect it's because of various threading backends, but we need to handle those -1 properly if nothing else but this implies going over by all used pthread functions and seeing all possible values (which might be OS specific) #3 is to be investigated. Will look at it later. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threads and alot of crap continued
You can call a callback in same thread, but since you can't ensure what the callback does from your lib you can't make it threadsafe in any way. Even if you put the callback itself into a criticalsection it might eg: change some variable which was just in use by the main thread, and once the callback finished the main thread booms. This is an old problem, and not fixable by wishing it. If you want a good async. timer, sure make one, but don't expect it to work safely by magic. Make sure to inform users that certain things are simply not a good idea to be done from their callbacks, or tell them to ensure thread-safety in main thread too. That's what I ment, it won't simply just work without implications like TThread SEEMS to. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] CSuspendThread/CResumeThread
Just define an opaque type TThreadResult: TThreadResult = DWord // Windows TThreadResult = cInt // Unices I don't like this solution for several reasons: 1. What if one OS has more backends for threading available, which differ in this? 2. How are we going to handle error states on cross-platform TThreadManager using code? Ofcourse, in a perfect world I'd come up with something nice by now myself.. well surprise surprise I haven't. I don't think there's a 100% clean solution but IMHO we should pick one internal scheme and go with it. For example say we choose to use a signed integer, -1 for error and specific values for specific situations needed. Back-ends which follow it would just be used like now (result:=...) while those which differ would be translated (eg: if ... xxx then Result:=-1) As I said it's far from perfect, but it gives a consistent interface atleast. Ales P.S: I do realize that there might be functions which result value returns eg: something which needs to be taken and passed along, or which value is variable (not constant). In case we abstract the return value, we limit this, so I say we abstract it to something BIG ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] lNet telnet
Whoever first told me about bad input from lNet telnet example, could you please try again to see if it still persists? I did some fixes related to input and certain telnet commands recently which might fix it. Thanks (sorry I forgot who it was and deleted the mail since then) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In FPC written FPC Debugger
Paul Ishenin wrote / napísal(a): 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 I agree 100% on this, unless gdb people don't accept patches at all I think this is the way to go. Writing our own debugger would be an unfinished endless process riddled with bugs anyhow. Of course Marc has more to say about gdb than most of us :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetText's GetLanguageIDs()
Graeme Geldenhuys wrote / napísal(a): I use getText in my game and I strip anything after 2 chars since I consider only the 2 char lang codes to be valid. Depends I guess... Ales Hi I'm working on localization for the fpGUI project. My idea is for the fpGUI toolkit to look for fpgui.%s.po files. Where %s is the language ID. e.g.: 'en' or 'af_ZA' or 'en_GB' etc. Under Ubuntu Linux, if I call GetLanguageIDs() it returns the following two IDs. SystemLanguageID1 = en_ZA.UTF-8 SystemLanguageID2 = en The problem here is the '.UTF-8' part. Normally the translation (.po) files look like the following. 'fpgui.en.po' or 'fpgui.af_ZA.po' etc. It never contains the '.UTF-8' part in the po files. So in the case of the Afrikaans translation (af_ZA), the .po file is never found. Am I supposed to handle that, by maybe looking for the '.UTF-8' part and stripping it, or can we extend GetLanguageIDs() to return 3 IDs instead? SystemLanguageID1 = en_ZA.UTF-8 SystemLanguageID2 = en_ZA (stripping anything from the . onwards) SystemLanguageID3 = en(stripping anything from the _ onwards) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ 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
Re: [fpc-devel] Summer of Code 2008
I've got a goole mail ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 32 and 64 bit fpc.cfg file
Joost van der Sluis wrote / napísal(a): Hi all, On Fedora 64-bit libraries are installed in /usr/lib64 and 32 bit libraries are in /usr/lib. The fedora fpc-packages also use these directories. The fpc.cfg file contains the following: # 32-bits -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl # 64-bits -Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget -Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget/rtl This works, but is not ideal offcourse. Is there a way to detect if the compiler is 32 or 64 bit in the fpc.cfg file? So that it's possible to define these options depending on compiling for 32 or 64 bit? Joost You're making it just specifically for fedora right? Because for example Ubuntu 64bit has it inverted, /usr/lib is a symlink to /usr/lib64. Perhaps 64bit fpc.cfg should have explicit libbits dirs. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 32 and 64 bit fpc.cfg file
Oh wait sorry other way around /usr/lib64 is a symlink to /usr/lib on ubuntu, it's inverted to fedora in any case. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 32 and 64 bit fpc.cfg file
Peter Vreman wrote / napísal(a): You can use: #ifdef CPU64 -Fu/usr/lib64/fpc/$fpcversion/units/$fpctarget ... #else -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget #endif Note that this won't work with /usr/local as prefix, because there's only one lib (by default) there. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] 32 and 64 bit fpc.cfg file
Marco van de Voort wrote / napísal(a): What happens if you have a bunch of 32-bit and 64-bit packages then? Packages go to /usr/lib not /usr/local/lib, and /usr/lib is either symlink or the main one (depends on distro if it's 64 or 32 I guess). /usr/local is completely untouched by all packages (at least on ubuntu). Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
I think this is also same in Delphi, but I agree that passing pure properties (without getter/setter) to var should possibly be reduced to warning or even hint. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetAppConfigDir confusion
It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? Considering the importance of this function to programs, it's changes along versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to document the behaviors per-version so people can decide if it's even viable to use atm. (I got burned). So.. questions are: 1. trailing pathdelims, yes or no? (of course only if there's something to return) 2. can I update the doc with per-version peculiarities info? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetAppConfigDir confusion
Michael Van Canneyt wrote / napísal(a): On Tue, 29 Jul 2008, Ales Katona wrote: It seems that currently, GetAppConfigDir performs rather incosistently. On Unix, it returns path with trailing pathdelim, on windows it returns path with random trailing path delim (depends on which branch, see code). What should it be then? Considering the importance of this function to programs, it's changes along versions (e.g: 2.2.0 vs 2.2.2 vs soon-to-be-trunk) I think we need to document the behaviors per-version so people can decide if it's even viable to use atm. (I got burned). So.. questions are: 1. trailing pathdelims, yes or no? (of course only if there's something to return) What is the most logical according to you ? I think the pathdelim should be there so people can simply add name of their file to it. That's how it currently works in unix, and I think it's the most logical solution. Loesje said he'll look into it but I can help, after someone confirms which way to go :) 2. can I update the doc with per-version peculiarities info? I'll take care of this. Thanks Michael. ___ 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
