Re: [fpc-devel] gdk 2.2 symbols
I'd like to point out that I started a packages/gtk2/src/gtkext/gtk2ext.pp unit which handles gtk 2.8+ additions to Gtk2 in a lazy linked manner with GL-like extension mechanism (each component has Available_componentname_2_x function to check for it's 2.x version availability). The idea is to not force a particular gtk version on people but have the latest gratest available with runtime choice. I'm currently "sweeping down the docs" adding things to it and will merge to fixes once it's fairly complete, anyone who wants to help is welcome of course, but please tell me which components you're adding/filling in so we don't work on the same thing (I usually commit per component or so). Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] update gtk2 package
Paul Ishenin wrote / napísal(a):
Hello, FPC developers' list
I've prepared a patch wich:
- adds missed gtk+2.2 symbols
- moved existed gtk+2.2 declarations into {$IFDEF HasGTK2_2} blocks
Please apply into truck and current fixes branch.
Hi, what exactly does gtk+2.2 mean? Last version (still devel) of Gtk+2
is 2.18 as far as I know, and our version should be based 2.6. Do you
mean 2.20 or 2.2?
If you mean old 2.2 then why the ifdef?
Ales
Best regards,
Paul Ishenin.
___
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] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Note that I'm not trying to do a "who can piss further" thing here. Just saying that IMHO the way C++ does this isn't exactly great. The idea behind it is nice, however apart from pure OOP approach I don't see much choice of how to do this nicely. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): And the same code will work both with normal array and with object implementing iterators ? I am not sure it will. How I can call your sort for a linked list container instead on array? Am I missing something or your code works with arrays only. The STL sort will work with arrays or with STL containers or with any class that implements the concept (I.E. defines iretator and reference types, and has iterator generating function etc.) As the best of my knowledge this is not doable with generics. C++ is doing it, but there is no validation mechanism aside from just plain old testing all possible combinations ;-) . With best regards, Boian Mitov Was just a case example. I looked at their code, and it's full of hacks. Practically, they do what I did for basic types (e.g: arrays) with overloads. For classes they do a runtime detection wether it is a container implementing the interface and then procede that way. I'd be doable in pascal too, but I'm still dizzy from looking at their code :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a):
Sort for example:
It can work with C type array:
int a[7] = {23, 1, 33, -20, 6, 6, 9};
sort(a, a+7);
or it can work with a container such as linked list:
list v1;
sort(v1.begin(), v1.end());
With best regards,
Boian Mitov
Mitov Software
http://www.mitov.com
This you mean?
template
void sort ( RandomAccessIterator first, RandomAccessIterator last );
You can do this with generics. Just use sizeof() to get to next element
and overloaded comparator functions for base types. I don't really see
much new here, it's a bit non-typical generics usage.
Here's a pascal example (OOP, true but that's a current limitation,
afaik "generic function" should be possible):
program Project1;
{$mode objfpc}{$H+}
type
{ TSorter }
generic TSorter = class
public
procedure Sort(var First, Last: T);
end;
{ TSorter }
procedure TSorter.Sort(var First, Last: T);
var
x, y: ^T;
z: T;
begin
x := @First;
y := @First;
while x^ <> Last do begin
while y^ <> Last do begin
Inc(y);
if x^ > y^ then begin
z := x^;
x^ := y^;
y^ := z;
end;
end;
Inc(x);
y := x;
end;
end;
type
TIntSorter = specialize TSorter;
var
s: TIntSorter;
a: array[1..5] of Integer = (5, 4, 3, 2, 1);
i: Integer;
begin
s := TIntSorter.Create;
s.Sort(a[1], a[5]);
for i := 1 to 5 do
Writeln(a[i]);
s.Free;
end.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RussianlocaleinformationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): Generics can't implement conceptual programming. As example for conceptual programming you can perform the same algorithm on simple arrays such as "char Array[ 1000 ]" as you can on any STL compliant container. The integrator concept is implemented different way but since it is concept as Sort algorithm will work. Generics do not allow that. With generics you can do Generics based programming but not concept based programming. With best regards, Boian Mitov Mitov Software http://www.mitov.com I also thought you ment generics. Please provide (for example C++) code example, I still don't get what you mean. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russianlocale informationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): To be honest I hate the Pascal OOP implementation even more, but the lack of Singleton support, good RTTI and AfterConstructor/BeforeDestructor . ;-) . The OOP model is something we as developers implement. We are not talking MFC, or VCL, but the language. There are a lot of fantastic OOP models in C++, and C++ supports conceptual programming (Well kind of), where Pascal does not. To be honest both languages have a lot of issues, but we take them for what they are and use them and love them :-) . I love both C++ and Object Pascal, well maybe C++ a bit more, but is still frustrates me when I can't create a simple singleton :-D . With best regards, Boian Mitov Mitov Software http://www.mitov.com I can't like an OOP model in which you: 1. can't call virtual methods from constructors 2. can't safely do stuff in constructors without using exceptions 3. can't limit the constructors being called (e.g: call order a, b, c) 4. no metaclasses or RTTI These are all language ad-hoc design limitations of C++, I'm sure there are more, but I personaly hit these. Perhaps I'm just spoiled by good OOP tho :P I'm curious however, what do you mean by "conceptual programming"? Can you provide an example? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): To be honest, I used to wonder why people still use Pascal when they have C++ ;-) . I still wonder, but now I am one of those people :-D . With best regards, Boian Mitov Mitov Software http://www.mitov.com Probably because C++ OOP model sucks so much, it could outsuck microsoft in vacuum cleaners :) Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale informationnotcompatiblewithFPClocalevariables
Boian Mitov wrote / napísal(a): Thank you! I agree. To summaries my opinion: 1. Massive multicores are slowly becoming a reality. 2. The modern compilers do little to support them aside from some library support. 3. The need for such support is not urgent, and probably will not be for at least 1-2 more years, but the demand will start to rise. 4. The best approach is to keep an eye on what the other compiler developers are doing, and try to follow the proven path ;-) . 5. In the mean time any good developer an utilize the existing tools and design true multithreading architectures. We have enough tools for that (Well maybe with the exception of a fast "Multi Read Single Write" implementation, but the life is never easy ;-) ) With best regards, Boian Mitov Mitov Software http://www.mitov.com I didn't want to add fire to this discussion, but I think one thing needs to be mentioned, and that is graphics card usage from Threads and possible APIs and their limitations. I was at #opengl channel a few times recently due to work and personal hobby too, and once I asked about doing basic texture loading in threads. It came down to it that the openGL API is completely thread allergic, however after a short discussion it was concluded that with today's cards (and the trend here isn't changing AFAIK), the pipeline would serialize all the calls in the end anyhow. In other words, having a thread-safe API for gfx calls would bring only overhead (e.g: DX 11 or original concept of GL 3.0) Just thought I'd mention this little bottleneck of the future (for games at least.. with 32+ cores, having only 1 doing the graphics I think could be fatal, especially since data throughput probably won't get much better on the main bus, e.g: RAM/Disk/VRAM transfers). As a tidbit, I *heard* (rumor level truthfulness) that the "objective" GL 3.0 threadsafe concept was thrown away in the winter, and that GL 3.0 will be a continuation of GL 2.0, not a rewrite. Take with a pinch of salt, news on this front will arrive soon :) 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
[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] 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
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] 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
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
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 lib dirs. Ales ___ 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] 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] 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
[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] 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
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
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] 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] 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
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
> > 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] 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
I'm not sure I see the value behind these ideas. If you need an event-based loop and callbacks you can make TApplication. If you don't want LCL ok, then make your own, it's generaly needed to be very problem-specific anyhow, eg: the TLEventers I use are ment for handling events on handles (files and sockets atm, sockets only in windows). If you want a "Timer" a "polling" mechanism has to take place which looks if something happened on some timer for example, OnTimer is "ready to be fired" (you can't call callbacks in threads, and if you go single-threaded you have to provide the main loop hooks). So basicly, let's say TTimer is in RTL and there's some event mechanism already too, you'd have to do something like this: procedure init; begin Timer.Timeout:=somenumber; Timer.OnTimer:[EMAIL PROTECTED]; EventHandler.RegisterTimer(Timer); // could be the other way around end; procedure MainLoop; begin EventHandler.HandleEvents; // if eventhandler after polling all timers in it's watchlist find out some has it's interval done, it fires it's callback end; begin Init; MainLoop; end. Apart from asynchronous stuff like watching handles etc. I don't see much use for this relativly complicated program model. Remember you need to call the "HandleEvents" as fast as possible to stay effective (otherwise you lose precision) ___ 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] 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
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
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
> - 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] 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
> 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
[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] 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
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
[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
[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
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
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
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] 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] 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] 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] OS aware RTL proposal
Michael Van Canneyt wrote: We don't. We just make the interface available, that's it. It shouldn't be used by default in libfprtl. Michael. What about Lazarus/binary packages? I think libfprtl.so is required there. If you use syscall version of this lib it's ok. If you use FPC_USE_LIBC however, it will cause linking problems on older distroes for example. I wonder how do you plan to fix this little problem. I've updated the wiki page to clarify what parts of RTL I wanted to be affected etc. There's also the "oldselect" problem for example. Might seem like a triviality but select() is used for many things (sleep, file IO etc.) which might mean FPC binaries would be much slower on 2.6 for example. Ales ___ 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: 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
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
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
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
[fpc-devel] OS aware RTL proposal
http://www.freepascal.org/wiki/index.php/OS_aware_RTL Tell me what you think Ales ___ 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] 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
[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 < $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] 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] 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
[fpc-devel] [Fwd: Kqueue update + Sendfile support for FreeBSD]
Try 2... --- Begin Message --- 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
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
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
[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] 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
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] 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
[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] WinSock error 10106
Alexander Todorov wrote: procedure TTCPClient.Connect; begin FSocket := Socket(AF_INET, SOCK_STREAM, 0); // create socket descriptor if (FSocket <= 0) then raise Exception.Create(IntToStr(SocketError)); . end; It seems like some Winsock1 vs Winsock2 issue to me. If you use unit "winsock" you're linking to winsock1 (which is old and deprecated). Sadly noone in FPC bothered to change it to winsock2. There are many winsock2 units out there so you might try to use those and see if it happens too. Windows is full of surprises when it comes to these things. There are even "reintroduced" bugs just to keep backwards compatibility because they f*cked up. Honestly tho I never got that error. Btw you might want to try LNet ( http://wiki.lazarus.freepascal.org/index.php/LNet ) atleast you can see how I do it and prehraps compary my code with your (you're looking to TLBaseSocket.SetupSocket). If you figure this out, can you let me know please? It's always a good idea to know possible bugtraps. Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Errors patch AGAIN
27;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 }
-'Timer expired',{ ETIME }
-'Out of streams resources', { ENOSR }
-'Machine is not on the network',{ ENONET }
-'Package not installed',{ ENOPKG }
-'Object is remote', { EREMOTE }
-'Link has been severed',{ ENOLINK }
-'Advertise error', { EADV }
-'Srmount error',{ ESRMNT }
-'Communication error on send', { ECOMM }
-'Protocol error', { EPROTO }
-'Multihop attempted', { EMULTIHOP }
-'RFS specific error', { EDOTDOT }
-'Not a data message', { EBADMSG }
-'Value too large for defined data type',{ EOVERFLOW }
-'Name not unique on network', { ENOTUNIQ }
-'File descriptor in bad state', { EBADFD }
-'Remote address changed', { EREMCHG }
-'Can not access a needed shared library', { ELIBACC }
-'Accessing a corrupted shared library', { ELIBBAD }
-'.lib section in a.out corrupted', { ELIBSCN }
-'Attempting to link in too many shared libraries', { ELIBMAX }
-'Cannot exec a shared library directly',{ ELIBEXEC }
-'Illegal byte sequence',{ EILSEQ }
-'Interrupted system call should be restarted', { ERESTART }
-'Streams pipe error', { ESTRPIPE }
-'Too many users', { EUSERS }
-'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 on transport endpoint',{ EOPNOTSUPP }
-'Protocol family not supported',{ EPFNOSUPPORT }
-'Address family not supported by protocol', { EAFNOSUPPORT }
-'Address already in use', { EADDRINUSE }
-'Cannot assign requested address', { EADDRNOTAVAIL }
-'Network is down', { ENETDOWN }
-'Network is unreachable', { ENETUNREACH }
-'Network dropped connection because of reset', { ENETRESET }
-'Software caused connection abort', { ECONNABORTED }
-'Connection reset by peer', { ECONNRESET }
-'No buffer space available',{ ENOBUFS }
-'Transport endpoint is already connected', { EISCONN }
-'Transport endpoint is not connected', { ENOTCONN }
-'Cannot send after transport endpoint shutdown',{ ESHUTDOWN }
-'Too many references: cannot splice', { ETOOMANYREFS }
-'Connection timed out', { ETIMEDOUT }
-'Connection refused', { ECONNREFUSED }
-'Host is down', { EHOSTDOWN }
-'No route to host', { EHOSTUNREACH }
-'Operation already in progress',{ EALREADY }
-'Operation now in progress',{ EINPROGRESS }
-'Stale NFS file handle',{ ESTALE }
-'Structure needs cleaning', { EUCLEAN }
-'Not a XENIX named type file', { ENOTNAM }
-'No XENIX semaphores available',{ ENAVAIL }
-'Is a named type file', { EIS
[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 }
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
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] 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 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
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
[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] 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
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] 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
[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] 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] 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
[fpc-devel] win32 patch for threads
This patch fixes a bug in win32 threads. Warning: created in win32 :)
(no idea about lineendings)
Ales
Index: rtl/win32/tthread.inc
===
--- rtl/win32/tthread.inc (revision 1647)
+++ rtl/win32/tthread.inc (working copy)
@@ -97,7 +97,7 @@
{ TThread }
-function ThreadProc(ThreadObjPtr: Pointer): Integer;
+function ThreadProc(ThreadObjPtr: Pointer): Integer; stdcall;
var
FreeThread: Boolean;
Thread: TThread absolute ThreadObjPtr;
Index: rtl/inc/threadh.inc
===
--- rtl/inc/threadh.inc (revision 1647)
+++ rtl/inc/threadh.inc (working copy)
@@ -26,7 +26,7 @@
type
PEventState = pointer;
PRTLEvent = pointer; // Windows=thandle, other=pointer to record.
- TThreadFunc = function(parameter : pointer) : ptrint;
+ TThreadFunc = function(parameter : pointer) : ptrint; stdcall;
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
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
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: type TGenericCollection = generic(T: TCollectionItem) class(TComponent) ...implement TCollection and use T end; TCollection = TGenericCollection of (TCollectionItem); TFieldDefs = TGenericCollection of (TFieldDef); And: type TGenericList = generic(T: PtrInt) class(TObject) ...implement TList and use PtrInt size for code generation end; TList = TGenericList of (Pointer); 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
[fpc-devel] TThread.Create patch
This patch adds an implicit StackSize argument to TThread.Create (fixed for all platforms) which enables users to create threades with various stack sizes. Default stack size is preserved if no argument is passed (old code is not broken). The diff was made against FPC 2.0.1 latest Ales P.S: Tested on PPC/Darwin/MacOSX and x86/Linux-32bits diff.tar.gz Description: application/gzip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The slice function and bug #2856
Peter Popov wrote:
Hi All
As you now, the Slice function (internal to the Delphi compiler) is
not currently implented in fpc (see bug
http://www.freepascal.org/bugs/showrec.php3?ID=2856). I am wondering
how easy it is to implement/circumvent this problem. In these regard,
can someone shed light on the following two things:
1. Are open array parameters in fpc functions and procedure
implemented in the same way as in Delphi. That is,
procedure MyFunc(x: array of integer)
is actually compiled as
procedure MyFunc(count: Integer; x: ^Integer)
and inside MyFunc, x is treated as a zero based arrays of size count,
and count is only accessible through High(x).
Are fpc open arrays done in the same way?
2. What is the internal structure of a dynamic array/open array in
fpc. Maybe, given a pointer and a array size, one can hack a
temprorary dynamic array structure (probably without typecasting) and
pass it as an open array parameter. Even without typecasting, this
will let me compile existing delphi code.
Thanks
Peter
Array slicing is already possible with the use of absolute eg:
program Project1;
{$mode objfpc}{$H+}
procedure Crap(var A: array of Integer);
var
b: array[1..3] of Integer absolute A[2];
i: Integer;
begin
for i:=1 to 3 do b[i]:=0;
end;
var
a: array of Integer;
i: Integer;
begin
SetLength(a, 6);
for i:=0 to 5 do
a[i]:=i + 1; // 1 to 6
Crap(a);
for i:=0 to 5 do
Write(a[i], ' ');
Writeln;
end.
Output is 1 2 0 0 0 6
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] 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] 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
[fpc-devel] LibC patch for 'dl' methods
This fixes dynamic link methods in libc unit. thanks to scamp for
pointing it out.
Ales
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,7 @@
Const
clib = 'c';
+ dllib = 'dl';
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
[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] 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] 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] 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 (I___
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] OpenGL patch, final(I hope)
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 opengl.diff.tar.gz Description: application/gzip ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OpenGL patch
I don't like this patch. Some years ago we didn't abort when no e.g. no glut.dll was found and we get a lot of bug reports like 2969 and 3100 where people complained that they get runtime errors when using opengl code. Yes I also tought about that. Ok I'll make it just "exception out" on error. The way it is now is not acceptable because for windows users it will simply crash. 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
[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
