Re: Re[2]: [fpc-devel] LocalReferenceFixup
Zitat von José Mejuto : Hello FPC, Friday, October 8, 2010, 1:41:39 PM, you wrote: Creation order -- 1) Create main form MS> application.createform() or t*form.create() 2) Create data module MS> application.createdatamodule(); 3) Wait in main form for user input 4) Create second form MS> application.createform() or t*form.create() MS> Such a scenario works in MSEgui. Application.Initialize; Application.CreateForm(TfrmWorkbench, frmWorkbench); Application.CreateForm(TdmCharting, dmCharting); Application.Run; procedure TfrmWorkbench.BitBtn5Click(Sender: TObject); var r: TfrmReportByFile; begin Application.CreateForm(TfrmReportByFile,r); r.Show; end; Does not work in Lazarus almost up to date SVN, and fpc 2.5.1 July 2010 Please provide an example. Either you are misusing the sql components or there is a bug in the sql components. But if my memory serves me, it does not work at least since Lazarus 0.9.26 and the related fpc version. I had not reported it before because I think that the problem was the missing datamodules, so I converted everything to use datamodules, but the problem remains. Database components should work independent of the owner class. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Zitat von Florian Klaempfl : Am 30.09.2010 14:15, schrieb Mattias Gärtner: Zitat von Jonas Maebe : On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? No. But I don't consider it that bad: most of the memory is released even in case of an error. The overlefts shouldn't add up that much. When it is used for quick syntax check the compiler is invoked several times a minute - several thousand times a day. Is that a problem? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Zitat von Jonas Maebe : On 30 Sep 2010, at 13:32, Mattias Gärtner wrote: Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? As far as allocated memory is concerned: yes. It does free a bunch of stuff when an error occurs, but not everything, and what is not freed depends on the error. Ok. Thanks. And I guess there are currently no plans to fix this, right? So the proper way to integrate FPC is to run it as separate process or in a dyn lib with its own memory manager. Correct, or ? This means, in order to share some caches an IDE must use some IPC/shared memory. Right? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RIP NoGlobals
Zitat von Jonas Maebe : On 30 Sep 2010, at 11:29, Hans-Peter Diettrich wrote: Lazarus allows to switch targets on the fly, what currently prevents an incorporation of the compiler into the IDE. There are more things that prevent that, not in the least that almost any source code error will result in lots of memory leaks from the compiler. Ehm, are you saying, that the compiler must be restarted when there were errors, because it does not clean up properly? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - first round finished
Zitat von Hans-Peter Diettrich : Marc Weustink schrieb: While I can use Lazarus to debug the compilation of a single source file, no such feature exists for Makefiles. I even don't know how to translate an error address to a source code position. In Delphi I had a "jump to address..." menu item... Use make all as "Execute before" step in Lazarus, check all 3 checks and uncheck the compiler "Call on" checks in the last page of the project options (Compiler options -> compiler). After these changes I get an error: Unable to run the tool "Executing command before": Program make not found Under windows the program is called 'make.exe'. If you do not specify a path the IDE searches it in the PATH. But make.exe is correctly entered in the environment options (the one that came with Lazarus 0.9.28). If you want to use that make, use the macro $(make). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Purpose of "uses ... in"?
Zitat von Zaher Dirkey : On Sun, Jul 11, 2010 at 11:21 PM, Jonas Maebe wrote: On 11 Jul 2010, at 15:47, Hans-Peter Diettrich wrote: > I know that the "in " is part of the Delphi syntax, but what is it really good for? > > AFAIK it's not allowed to "rename" units this way, and since (currently) only absolute filenames are implemented, That is incorrect. Relative file names do work. They are resolved relative to the current working directory of the compiler. It is more useful if relative to same directory of the current file, i can move or copy my projects/lib easly without need to change the .cfg or my project options. Even then: If you move/rename a directory with target units, you have to adapt all 'in' of using units. If you use search paths you only have to adapt one. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Zitat von Michael Schnell : On 07/19/2010 12:52 PM, Mattias Gärtner wrote: About converting global variables for threads: What are the advantages/disadvantages of using ThreadVar versus member variables? I don't see what you are trying to compare here. If I understood the mail thread correct, the goal was to change some global variables, so that each thread has its own. This can be achieved with Threadvar or one object per instance. I don't know how ThreadVar is implemented by the compiler on the various systems. Threadvars are addressed by a dedicated register (I suppose a segment register with on X86) that is different for each thread ant points to a memory area that is dedicated to each thread. Can some compiler guru confirm this? After a quick glance on the rtl sources it seems ThreadVar works under some platforms internally pretty much the same as an object instance: it allocates some memory on the heap. Member variables are addressed using the self pointer of the object and thus they are located on the heap and different for each instance of the Object but common for all threads. I suppose the speed difference is very small but the function is very different. If you want an instances of a class for each thread you need to have each thread create it's own instance (on the heap) and and hold the self-Pointer (the "instance"-variable ) in a threadvar. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] OO rewrite - technical questions
Zitat von Hans-Peter Diettrich : [...] These handler procedures need further information, that currently resides in global variables. In an OO approach these variables become class members, so that an additional reference to a concrete object is required in the directive handlers. About converting global variables for threads: What are the advantages/disadvantages of using ThreadVar versus member variables? Did someone test the speed differences? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Compiler bottlenecks
Zitat von Jonas Maebe : Michael Schnell wrote on Thu, 15 Jul 2010: Did somebody take a look at FastMM for Delphi ? ( http://sourceforge.net/projects/fastmm/ ) Same seems to use a nice paradigm doing the Memory management for threaded applications. Then please explain that paradigm, since apparently you already looked at it. In return, I will explain the FPC heap manager's paradigm: per thread, there is a separate heap manager so that in most cases no synchronisation is required. Only if memory is allocated in one thread and freed in another, then it will be added to a global locked structure. When a thread runs out of memory in its pools, it will first check this global (synchronised) structure before asking for more memory from the OS. Does that mean, if I let a worker thread create strings, pass them to the main thread, free the worker thread and unreference the strings in the main thread the global structure will grow and grow? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc content syntax suggestion
Zitat von Graeme Geldenhuys : Op 2010-07-09 09:32, Mattias Gaertner het geskryf: +1 Although I don't know how attributes like /var should look like. Can you create a full list of supported tags? For which syntax? The square bracket one, Creole, WikiText, AsciiDoc? A list of fpdoc xml tags that needs to be supported. Michael already started a list of all tags in the short and descr fields. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Another bug with spaces in fpc (windows)
Zitat von Hans-Peter Diettrich : Mattias Gärtner schrieb: The 'in' modifier works here. It didn't work for me with relative pathes, like uses myUnit in '..\myUnit.pas'; (Windows, obviously ;-) Hint: Both compiler and lazarus automatically changes the path delimiter and searches exact/lower/upper case for the file name (not path). In the concrete case the filename was all lowercase, and the Windows filesystems are case-insensitive. Yes, it was a hint how 'in' works platform independent. There might be a problem with "uses" in the project file, where "in" is allowed, and with uses of the same file in other units? The 'in' modifier is troublesome and is always the inferior solution compared to search paths. Unfortunately I have to replace some files in the compiler directory, what suggests *not* to add that directory to the searchpath - otherwise I suspect that a used unit could be found in the wrong directory. How do you replace units with the 'in' modifier? Perhaps somebody has a better solution? Replacing units can be done with the search path. Lazarus searches relative to the unit, the compiler relative to its working directory. The reason is that the IDE has not a single working directory, but each project, each package and each tool have their own working directories, so units can have 0..n different working directories. I understand the complications in Lazarus, but not in FPC with a single (unique) working directory :-( That's why I ask in the FPC list. Maybe start another mail thread for this? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Another bug with spaces in fpc (windows)
Zitat von Hans-Peter Diettrich : Mattias Gaertner schrieb: Lazarus sets the working directory to the project directory when calling the compiler. Fine :-) The 'in' modifier works here. It didn't work for me with relative pathes, like uses myUnit in '..\myUnit.pas'; (Windows, obviously ;-) Hint: Both compiler and lazarus automatically changes the path delimiter and searches exact/lower/upper case for the file name (not path). While Lazarus could find that unit, FPC could not :-( There might be a problem with "uses" in the project file, where "in" is allowed, and with uses of the same file in other units? The 'in' modifier is troublesome and is always the inferior solution compared to search paths. Lazarus searches relative to the unit, the compiler relative to its working directory. The reason is that the IDE has not a single working directory, but each project, each package and each tool have their own working directories, so units can have 0..n different working directories. Delphi uses the 'in' modifier mostly to mark units as part of the project. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
Zitat von Graeme Geldenhuys : Op 2010-06-09 16:06, Henry Vermaak het geskryf: * Because it would be idiotic to change something based on a point of view of one person. It's not just one person. Lets just take the Rectangle type/structure. * Delphi has it's own (based on Windows TRect - how original) left,top,right,bottom * fpGUI has it's own: TfpgRect tell us * MSEgui has it's own: rectty left,top,width,height * AggPas has it's own: rect_ptr, rect_d, rect_i doubles and C int type. Aggpas is a C port. C people are used to reinvent the wheel. * KOL probably has it's own too no * ... pretty sure there are more As far as I can see, every one of the above has a good reason to use their own type. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Slight calculation error in Bounds() procedure in Classes unit.
Zitat von Aleksa Todorovic : On Wed, Jun 9, 2010 at 11:30, Graeme Geldenhuys wrote: Op 2010-06-09 11:02, Florian Klaempfl het geskryf: interpretation of bounds, the current behaviour is perfectly valid for any other uses. Not as I see it, and described in the bug report. Think of the pixel screen/grid like the grid of a spreadsheet (as as a magnified look of the top corner of your screen) 0 1 +---+---+--- 0 | x | | +-+-+---+--- 1 | | | +-+-+---+--- 2 | | | +-+-+---+--- x is at (0,0). A pixel is always 1x1, you don't get smaller (we are not using sub-pixels like on LCD screens, because they don't apply to all screens). It's correct that a pixel is an area, usually of size 1x1. So when you say it is at 0,0, then you are really saying: the left,top corner of the pixel is at 0,0 and the right, bottom corner is at 1,1. With the Bounds function: Bounds(0,0,1,1) Math: Right-Left=Width Graeme: Right-Left=Width-1 For example: Let's say you have a position 3. The math says it is the left edge of pixel 3 (usually the fourth pixel). Graeme says: If it is a Left, then it is the left edge of pixel 3, if it is a Right then it is the right edge of pixel 3. Graeme's definition is useful for drawing a pixel based rectangle (with line width of 1). When computing with coordinates the math definition is easier as you don't have to know if it is a left or right. [...] 0 1 +---+---+--- 0 | x | x | +-+-+---+--- 1 | x | x | +-+-+---+--- 2 | | | +-+-+---+--- In this example we have a rectangle. Top/Left = (0,0) and Bottom/Right = (1,1). This means Width = 2 pixels and Height = 2 pixels. Clearly visible in the image above. That's only correct for a line width of 1. The rectangle has a line width of 1 pixel, 0.5 pixel around the four x. This means the rectangle has Width=1 and Height=1, but including the thickness of the line the total rectangle has Width=2 and Height=2. The difference can be seen when using libraries that supports sub pixel rendering like aggpas. But if we call Classes.Bounds(0,0,2,2) it reports Bottom/Right as (2,2) which is wrong (again looking at the image above as reference). This is my point. Bounds() cannot be used in this case in a graphical environment. Yes, it can. If you want the rectangle including the line width of 1, you must add 1. If you use a line width of 5 you must add 5. Maybe you want a Bounds function like this: function RectangleHull(Left, Top, Width, Height: integer; LineWidth: integer = 1): TRect; Actually, everything works fine here :-) You just have to change your point of view regarding coordinates. You assume that integer coordinates represent center of pixel, but they actually represent top-left corner of pixel. In other words, think of coordinate 0 as 0.0, not 0.5 and the math will work perfectly fine :-) The math works with 0.0, 0.5 and 0.9. But if you don't use sub pixel rendering you won't see the difference. [...] Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message(); in Linux
Zitat von Michael Schnell : On 03/01/2010 10:36 AM, Mattias Gaertner wrote: You need lazarus 0.9.29. I might try to get this running some day soon Try that on "PostMessage". I get a method in unit InterfaceBase and a procedure in unit LCLIntf. Obviously you want the last. I've not yet been able top find the Linux definition of same. Keeping on trying Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message(); in Linux
Zitat von Juha Manninen : Hi, What gave no feedback? Ok, I tested again with a non-typical situation. I worked with lazarus.lpi and built Lazarus from tools -> Configure Build Lazarus. The error messages show up just like when compiling a "normal" project but "search identifier" does nothing. I tested with lazarus.lpi: It works. Do you have english messages? Now I tested with a "normal" project and it works. It is a cool feature actually. I noticed a minor bug: the Scope combobox gets "Project" by default. If I click the down-arrow to see a list then the first "Lazarus IDE" gets selected automatically. I guess you forgot to set Combobox.ItemIndex and only set its text. It didn't matter for me. I now set the ItemIndex. Does that fix it? BTW, what does the Scope do? If I comment out SysUtils in my source, it always finds the missing function under FCL, whatever scope I select. That's the interesting difference between the codebrowser and a find declaration. Find declaration will search only via the uses sections and search paths. The codebrowser searches in whole packages and projects. That's why it can tell you in which unit an identifier is defined. If you set scope to 'project' it will search in all units of the project. If you check the 'with packages' it will search in all packages required by the project too. This normally includes the FCL package, so it will search in all units installed by FPC. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure ... message(); in Linux
Zitat von Michael Schnell : Can't anyone answer the question if in Linux the legal and compilable construct procedure... message; either is not supposed to be working or how I can have such a procedure be executed (e.g. by posting a message from a thread or another application, what I successfully did in Windows. Maybe if you provide a more complete example, some Linux users can help you. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Correlation between TFPColor and RGB values (possible inconsistencies)
Zitat von Luiz Americo Pereira Camara : Mattias Gaertner escreveu: On Wed, 17 Feb 2010 06:52:25 -0300 Luiz Americo Pereira Camara wrote: fpimage is not documented at all AFAIK. It's not loosing bits if your information, in previous mail, about TFPColor format is correct. Defining colGray, and related, as TFPColor = (Red: $8080; Green: $8080; Blue: $8080; Alpha: alphaOpaque) would make it work. ... would make it work with a 24bit color image that uses one pixel color conversion *$101, div $100. It won't work on a 24bit color image that uses color conversion *$100, div $100 or on any other format. Are you saying that TFPColor is just a container for any 48bit format and has not a defined format? It is defined as a RGBA format. AFAIK there is no definition how TFPCustomImage.Get/SetColor map this to 24bit RGB. The point is that the TFPColor constants are inconsistently defined. $8000 is exactly the middle. It is the right value for gray. OK. If i understand correctly, you are saying that in TFPColor format $ means black (no color in the channel) $ means white (full color in the channel) and between them you get the remaining intensity. Assuming that, giving a color in 24bit RGB (one byte per channel) where $00 means no color $FF full color, if a channel is on the middle ($80 = 128) it would be equivalent to $8000 in the 48bit format, right? LazIntfImage is returning $8080. The LCL uses the $101 to get full 16bit white/black, and full alpha/opaque, so you can use Colors[x,y]=colWhite and Colors[x,y].Alpha=alphaOpaque. This makes porting many algorithms easier. About gray: gray is the middle between black and white. But the middle between black (0) and white (255) is 127.5 which does not fit into 8bit. So a gray of $80 is somewhat to bright. The LCL converts $80 to $8080 which is also somewhat above the real gray in 16 bit: $7fff.8 (32767.5). If channel is $40 (=64) in 24bit, it should not map to $4000 in 48bit? LazIntfImage is returning $4040 If channel is $2 (=2) in 24bit, it should not map to $0200 in 48bit? LazIntfImage is returning $2020 If channel is $1 (=1) in 24bit, it should not map to $0100 in 48bit? LazIntfImage is returning $1010 AFAIK, it should not be difficult to fix that (assuming is broken). All in all, this is not an issue for me and i won't take any longer if other agree that there's nothing broken. IMO nothing is broken, just gray is a rounded value and converting a rounded value between various precisions creates rounding errors. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [arm] tStream.position
Zitat von Dariusz Mazur : Hi there is problem with something like that var ts : tStream; begin ts:=tStream.create; ouch. TStream is an abstract class. Maybe the keyword 'abstract' should be added, so that the compiler warns. ts.position:=2; // here arm write ERange Error // on trace setPosition // is very big number, like 153000 ts.free; end; platform : ARM with soft float It is wrong on every platform. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Save the current FPC UnicodeString!
Zitat von Martin Schreiber : On Friday 13 November 2009 13:26:29 Graeme Geldenhuys wrote: Michael Schnell wrote: > Martin Schreiber wrote: >> On Linux xlib and xft have utf-16 interfaces. > > What exactly are xlib and xft and why does MSE-GUI seemingly use those > while LCL seemingly uses something else ? Martin answered this already. But just to be clear, xlib and xft have both utf-8 and utf-16 interfaces. fpGUI uses the utf-8 interfaces, whereas MSEgui uses the utf-16 interfaces. Often strings are converted to UCS4 somewhere in the chain anyway so it doesn't matter. utf-16->UCS4 can be a little faster maybe. For graphic apps the text conversion is hardly measurable. UTF-16 is not sufficient under linux for file names, because Linux uses UTF-8 and allows invalid characters. This happens often when transferring files from Windows. That's why the RTL file operations must use the system encoding under Linux and not UTF-16. Afaik Mac OS X does not allow invalid UTF-8 characters for filenames. Windows has its codepages, with characters that have no unicode equivalent. But afaik this is a rare case, so for almost all programs UTF-16 is sufficient. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TObject differences between fpc and delphi
Zitat von Michael Van Canneyt : On Tue, 27 Oct 2009, Florian Klaempfl wrote: Paul Ishenin schrieb: I have compared what d2010 TObject has and found a few differences: 1. Dispatch method is virtual 2. new method: class function UnitName: string; 3. new method: function Equals(Obj: TObject): Boolean; virtual; 4. new method: function GetHashCode: Integer; virtual; 5. new method: function ToString: string; virtual; Documentation: http://docwiki.embarcadero.com/VCL/en/System.TObject.Dispatch http://docwiki.embarcadero.com/VCL/en/System.TObject.UnitName http://docwiki.embarcadero.com/VCL/en/System.TObject.Equals http://docwiki.embarcadero.com/VCL/en/System.TObject.GetHashCode http://docwiki.embarcadero.com/VCL/en/System.TObject.ToString Which of that changes are welcome for FPC? Since we opened the d2010 can of worms anyways, I think all would be accepted. I was going to say the same :-) Although I think that TObject.ToString will give a lot of problems for things like tiOPF... On the other hand, UnitName may come in handy for the Lazarus IDE. Lazarus already reads the unitname from the RTTI (see propedits.pp) and I guess MSEgui uses that too. There are no classes yet without RTTI in lazarus where the unit name is needed. Maybe it can be useful for debugging? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] class abstract, class sealed implementation. please review.
Zitat von Vinzent Höfler : Florian Klaempfl : Marco van de Voort schrieb: > In our previous episode, Florian Klaempfl said: >>> This is exactly my point about sealed classes. When you design the >>> product or class, you have NO way of know what will come in the >>> future. So you need to stay flexible to change! Yet another OOP >>> principal that "sealed" tries to prevent! >> This might be true, but what's the difference with private etc.? > > Private is typically used in nearly every class, sealed in exceptional > cases. At best. I meant regarding "flexibility". Declaring a member private makes things also less flexible. The main difference is that "private" restricts visibility, whilst "sealed" restricts extensibility. The former is usually a good thing, the latter not. True. But as already mentioned: It does not hurt. Granted, the compiler became somewhat bigger and slower, in fact all pascal parsers became somewhat bigger and slower (fcl, codetools, highlighters, ...), a new modifier bites some existing code, the documentation becomes more complex, newbies have more to learn, it allows to create dead end code and all this has to be maintained. That's all. That's nothing. It does not hurt. Many a mickle makes a muckle. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Michael Schnell : Mattias Gärtner wrote: The @ operator is more than "address of". Hmm "Address of" is not that simple in itself. :) With a "Procedure of Object", "@" of course handles the Self pointer, too. I suppose to find the address of a function "@" uses the Virtual Method Table found with the Self pointer. So in fact there are (at least) two ways of implementing a compare between two pointers to "Procedure of Object" variables, that IMHO both make sense: 1) Simply compare the Self and the Address part (the same function of two implementations of a class are different) 2) Compare only the address (the same function of two implementations of a class are identical, unless overloaded by a child's function). I think it's a matter of taste (I do vote for (2) ). No. It is a matter of consistency. The current comparison is not intuitive. This is proven by the many places where it used wrong and the almost zero places where it is used right (Is there any one at all?). The problems are: 1. It exists for years, so there might be code depending on this. I doubt this. 2. It is Delphi/TP compatible. So it can not be done in mode delphi/tp. That's why I propose to change it in mode objfpc. If the compiler team refuses to change it, can at least a "hint" be given? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Vincent Snijders : Jonas Maebe schreef: On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case "code address", the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than "address of". The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). It is delphi compatible, not really intuitive, so I would welcome a change in the objfpc mode. See: http://bugs.freepascal.org/view.php?id=9228 http://bugs.freepascal.org/view.php?id=11868 To draw the whole picture: var a,b: TNotifyEvent; a=b compares only Code, not Data a=nil compares only Data, not Code Assigned(a) compares only Code, not Data n.a.compares both I wonder how many programmers know this. Even the FCL contains code, where this leads to wrong code. More important: I don't know a place, where a=b and a=nil are used right. But I have seen a lot of code where it was used wrong. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Jonas Maebe : On 10 Sep 2009, at 14:01, Mattias Gärtner wrote: Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case "code address", the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than "address of". The current behaviour has been there since svn revision 1, so it's quite old and established at least (and Delphi/TP-compatible, afaik). Yes, and since the beginning I was wondering why. Years ago I thought, there are probably cases where this is useful. But since today I hardly saw one. OTOH I saw several times code that misused it. If it is only for delphi/tp compatibility, then maybe it can be changed in mode objfpc? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Thaddy : Mattias Gärtner wrote: Zitat von Michael Schnell : Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case "code address", the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than "address of". Nope, it is: although there is some vmt work involved : the data part is for the new instance, not the global instance. Assigning a new method to one of the two instances your example gives makes them unequal because the instances are deep copies or rather new instances of the same class with different addresses. Hopes that helps. Not at all. But thanks for trying. If you assign to an empty variable, like var a,b:TMyClass; begin b:= TMyClass.Create; a:=b; end; You will get the result you expect. The 'a,b' above are pointers to mem areas. a=b compares the pointers. If a,b would be records then a=b would compare the mem. If a,b would be 'procedure of object' then a=b compares only half of the mem. This is different to both cases above. Hope this helps. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] comparing methods
Zitat von Michael Schnell : Mattias Gärtner wrote: Can someone explain why in mode objfpc comparing methods only compares the address, but not the instance? Seems perfectly logical to me (@ = Address of, in this case "code address", the code is the same for all instances of a class). OnClick:=...@myclick; The @ operator is more than "address of". Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] comparing methods
Hi,
Can someone explain why in mode objfpc comparing methods only compares
the address, but not the instance?
For example:
a:=TMyClass.Create;
b:=TMyClass.Create;
if @a.test = @b.test then writeln('the same method');
This results in strange behaviors, when using the following code (from
the FCL):
property AfterConnect: TNotifyEvent read FAfterConnect write SetAfterConnect;
procedure TCustomConnection.SetAfterConnect(const AValue: TNotifyEvent);
begin
if FAfterConnect=AValue then exit;
FAfterConnect:=AValue;
end;
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] How to search units reported by gdb? (fpc and mseide devels please participate)
Zitat von Jonas Maebe : > > On 27 Feb 2009, at 15:17, Paul Ishenin wrote: > > > We have a trouble in lazarus. We need to open units and include > > files wich gdb returns to us. The problem is that gdb repors them > > without full path. > > It's because there is no path information in the debug information. > > > What solution fpc team can suggest? > > Use DWARF :) > > I don't know where the decision comes from to not include any path > information in the stabs debug information that FPC generates (gcc > does include it by default). It is possible to specify a full path for > each file in stabs. That path would obviously be invalid if you copy > the program to another machine though (or if you access it from > another machine over a network share). True, but a /bla/bla/rtl/objpas/classes/lists.inc is much better than a lists.inc. > Maybe you cannot tell gdb to > search elsewhere for the source if you include a full path? A command > line option could be added to make FPC store full paths in the stabs > debug info though. Feel free to file a feature request Thanks for the advice. Paul, will you do that? > In case of DWARF, the path is split in two parts: a base directory, > and then paths to files relative to this base directory. That makes it > easier to specify full paths and still be portable to other file > system layouts, I guess (although I don't know how gdb handles this > either). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Vincent Snijders <[EMAIL PROTECTED]>: > Florian Klaempfl schreef: > > Mattias Gärtner schrieb: > >> Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > >> > >>> [...] > >>> This is the problem: At which point should this be done ? > >>> > >>> Can you point at the statement where it should be raised in the following > >>> code: > >>> > >>> try > >>>... > >>>DoParallel(...); > >>>... > >>> except > >>> end; > >>> > >>> There is only 1 possible location: in a waitloop which should be after > the > >>> DoParralel. This loop must check for the exceptions... > >> Not after, but at the end of DoParallel. > > > > What happens if more threads throw an exception? They are ignored. If you want to handle more than the first exception then you can put a try..except into AMethod. Note: The thread pool should simplify some parallelizations. It does not solve the problems of multi threading. > A new exception is thrown, which has a List of InnerExceptions, instead > of just a single InnerException ;-) ... and a tree is created for recursive DoParallel calls. ;) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: >[...] > This is the problem: At which point should this be done ? > > Can you point at the statement where it should be raised in the following > code: > > try >... >DoParallel(...); >... > except > end; > > There is only 1 possible location: in a waitloop which should be after the > DoParralel. This loop must check for the exceptions... Not after, but at the end of DoParallel. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>: > Mattias Gärtner schrieb: > >> raised ? > > > > It should be raised in the starter thread. The question is how to > > - stop an exception in a thread (try..except) > > - give it to another thread - the starter thread (giving the object is > easy, but > > ...) > > - continue the helper thread (this will normally free the exception object, > I > > need a way to avoid this automatism) > > This is why I told you to have a look how Synchronize works ;) Hint: > AcquireExceptionObject/ReleaseExceptionObject which implement simply > ref. counting which is respected by the exception handling code. Wow, I didn't know that Synchronize catches exceptions and gives them back to the calling thread. That's exactly what I needed. :) It works. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > In our previous episode, Mattias Gärtner said: > > > > What should happen when an exception occurs? > > > > > > AFAIK any unhandled exception in a thread will cause it to silently die > > > > Yes, and that should never happen. At least not for normal exceptions like > out > > of memory, index out of bounds, io error - anything that does not corrupt > the > > heap. > > I'm catching any exception. But somehow the exception must be delegated to > the > > group's starter thread. (which is not necessarily the process' main > thread). > > I do not get this? Why is this so logical to route this to the starters > thread? > > There are two problems with that: > - the starter thread can be pretty much everywhere in its codepath. Not > necessarily the place where the thread was started. When the exception occurs, the starter is somewhere in the AMethod or in the wait loop (= somewhere in DoParallel). The starter will eventually come back to the wait loop where it checks the helper threads. The stacktrace is not that important, but the type and message of the exception object is. IMO it would be very helpful, if DoParallel could work with try..except. > - It assumes some form of polling/synchronization and essentially > event-driven behaviour. Yes. > > > > It would be nice if the exception can be transfered to the main thread. > > > > Is this possible? How? > > > > > > I don't know, set a flag in the thread and check it periodically from > > > the main thread? > > > > I do that already. > > My current idea is to simply pass the exception object to the other thread > and > > raise it there. But I'm not sure if this works always. Maybe I have to set > some > > more RTL values to do that cleanly. > > More logically, have a tthread.onexception that can handle the exception, if > not already there. It can then pass it to whatever thread or subsystem > necessary using custom synchronization. Yes, that is an alternative. > > > (Florian's suggestion does the reverse: raise in a thread an exception > > > occurred while executing in the context of the main thread) > > > > Yes, but 'synchronize' is only for the process' main thread. > > Yes, and that might not be event-driven either (that is not a requirement > for using tthread, only for synchronization), so IMHO that is false, and > never should be default behaviour. Yes. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Thu, 11 Dec 2008, Mattias Gärtner wrote: > > > Zitat von Florian Klaempfl <[EMAIL PROTECTED]>: > > > > > Mattias Gärtner schrieb: > > > > I'm writing a unit to simplify parallel methods/procedures. > > > > > > > > For example: > > > > DoParallel(@AMethod,StartIndex,EndIndex,Data); > > > > > > > > The AMethod is executed with several threads in parallel. > > > > > > > > What should happen when an exception occurs? > > > > It would be nice if the exception can be transfered to the main thread. > > > > Is this possible? How? > > > > > > See synchronize/checksynchronize implementation. > > > > Sorry, I misused the term 'main thread'. > > > > DoParallel starts AMethod with several threads in parallel and waits until > all > > threads finished. DoParallel can be called by any thread (e.g. the main > thread > > of the process *or* any other sub thread). Even the threads of the pool can > > call again DoParallel. This is only limited by the memory, as each call > creates > > a threadgroup object. > > > > The goal is to simplify parallelizing procedures so for the user DoParallel > > should work like a normal procedure call. > > That's why it would be nice if the following could work: > > > > try > > ... > > DoParallel(...); > > ... > > except > > end; > > > > The exception can occur in any of the subthreads including the starting > thread > > (which I named 'main thread', because it is the main thread of the group. > Maybe > > I should call it 'group thread' or 'starter thread'). > > > > When an exception occurs, the group waits for all other threads of this > group to > > finish and then the exception should happen 'as if the exception occured in > the > > starting thread'. > > The way I uderstand threads this can never work, because then there should > be a synchronization wait loop after the doparallel. Without the wait loop > it'll never work, because where (at which statement) should the exception be > raised ? It should be raised in the starter thread. The question is how to - stop an exception in a thread (try..except) - give it to another thread - the starter thread (giving the object is easy, but ...) - continue the helper thread (this will normally free the exception object, I need a way to avoid this automatism) - raise the exception in the starter thread (raise FetchedException). > To make it operable, the thread should catch the exception, and then do a > synchronize with a procedure that raises the exception, so that when > synchronize is called, the exception is raised. I don't see how this is possible. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Luca Olivetti <[EMAIL PROTECTED]>: > En/na Mattias Gärtner ha escrit: > > I'm writing a unit to simplify parallel methods/procedures. > > > > For example: > > DoParallel(@AMethod,StartIndex,EndIndex,Data); > > > > The AMethod is executed with several threads in parallel. > > > > What should happen when an exception occurs? > > AFAIK any unhandled exception in a thread will cause it to silently die Yes, and that should never happen. At least not for normal exceptions like out of memory, index out of bounds, io error - anything that does not corrupt the heap. I'm catching any exception. But somehow the exception must be delegated to the group's starter thread. (which is not necessarily the process' main thread). > > It would be nice if the exception can be transfered to the main thread. > > Is this possible? How? > > I don't know, set a flag in the thread and check it periodically from > the main thread? I do that already. My current idea is to simply pass the exception object to the other thread and raise it there. But I'm not sure if this works always. Maybe I have to set some more RTL values to do that cleanly. > (Florian's suggestion does the reverse: raise in a thread an exception > occurred while executing in the context of the main thread) Yes, but 'synchronize' is only for the process' main thread. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Exceptions in threads
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>: > Mattias Gärtner schrieb: > > I'm writing a unit to simplify parallel methods/procedures. > > > > For example: > > DoParallel(@AMethod,StartIndex,EndIndex,Data); > > > > The AMethod is executed with several threads in parallel. > > > > What should happen when an exception occurs? > > It would be nice if the exception can be transfered to the main thread. > > Is this possible? How? > > See synchronize/checksynchronize implementation. Sorry, I misused the term 'main thread'. DoParallel starts AMethod with several threads in parallel and waits until all threads finished. DoParallel can be called by any thread (e.g. the main thread of the process *or* any other sub thread). Even the threads of the pool can call again DoParallel. This is only limited by the memory, as each call creates a threadgroup object. The goal is to simplify parallelizing procedures so for the user DoParallel should work like a normal procedure call. That's why it would be nice if the following could work: try ... DoParallel(...); ... except end; The exception can occur in any of the subthreads including the starting thread (which I named 'main thread', because it is the main thread of the group. Maybe I should call it 'group thread' or 'starter thread'). When an exception occurs, the group waits for all other threads of this group to finish and then the exception should happen 'as if the exception occured in the starting thread'. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Exceptions in threads
I'm writing a unit to simplify parallel methods/procedures. For example: DoParallel(@AMethod,StartIndex,EndIndex,Data); The AMethod is executed with several threads in parallel. What should happen when an exception occurs? It would be nice if the exception can be transfered to the main thread. Is this possible? How? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Multithreading wait for
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: > Mattias Gaertner wrote: > > On Wed, 03 Dec 2008 19:41:12 +0100 > > Vinzent Höfler <[EMAIL PROTECTED]> wrote: > > > > If I understand RTLEventWaitFor correct, then it waits until another > > thread calls RTLeventSetEvent. > > Unless it's already signalled, then it should run right through. Yes, that works under Linux. But the documentation does not mention it, so I'm not sure if this works under all platforms. Maybe some other OS users can try if the following code runs through: var e: PRTLEvent; begin e:=RTLEventCreate; RTLeventSetEvent(e); RTLeventWaitFor(e); RTLeventdestroy(e); end; If this is guaranteed then my problem is already solved and the code work as it is. But then the documentation must mention it. Who knows if this is a documentation bug or a linux bug? > > So I must check *before* calling RTLEventWaitFor, that some other thread > > is running, must I not? > > No, assuming RTLEvent implements a persistent signal, not a transient > one. I am not 100% sure here (so someone should check the source), but I > remember that there were two versions (mimicking the Windows-Events), > depending on how one would set them up. I implemented my own versions > some time ago (fpc2.0.0), but that was due to some bugs and quirks in > fpc's implementation, so I'm not really up to date if those are fixed > now for all platforms. > > >>> The problem is the gap between LeaveCriticalSection and > >>> RTLeventWaitFor. During this time the other threads may finish. So > >>> there is no one left to wake up the waiting thread. > >> So your asking the wrong question. You don't want an efficient wait > >> loop, you want a wait loop free from race conditions. > > > > :) > > I know how to do a race condition free loop inefficiently using a spin > > lock. My question is, if it can be done race condition free and > > efficiently, to allow switching thousands of times a second without busy > waiting. > > That's what it should do (although the term "efficiently" may depend on > some other factors like number of processing units, threads waiting, > average wait time and such). > > >> Well, depending on what your checks do, you may not even need the > >> critical section if you reverse the logic. Either all checked threads > >> are finished or they aren't. If the state changed during the check, > >> the check code will be invoked immediately, because the event will > >> already be signalled again. > > > > The critical section is needed, because after a thread finished some > > work it starts some other work. > > Well, in that case... Another solution would be to provide specific > events for the waiting threads, but this requires quite some more amount > of administrative work, so in the end it may even turn out to be less > efficient. ;) > > > Vinzent. > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel > -- Powered by NetMail ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Multithreading wait for
Hi all, I'm looking for a high performance 'wait-for'. The situation: There are m threads working in parallel on n chunks of work (n>=m). The n chunks are indexed 0..n-1. Sometimes one thread needs the result of some of the lower indexed chunks. For example the chunk number 5 needs chunks 0..2. So I have a function WaitForIndex(LowerIndex: integer) which should wait until all chunks with less or equal to LowerIndex have finished. My current approach is this: EnterCriticalSection (try..finally) Check if all lower chunks have finished, if yes then exit LeaveCriticalSection RTLeventWaitFor(AnEventOfTheCurrentThread); And each time a thread has finished a chunk, it wakes all corresponding threads. The problem is the gap between LeaveCriticalSection and RTLeventWaitFor. During this time the other threads may finish. So there is no one left to wake up the waiting thread. Moving the RTLeventWaitFor into the CritialSection creates a deadlock. I can use the timeout of RTLeventWaitFor and check in intervals, but criticalsections and low response times don't fit together. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > For me, these attempts to make compiler do everything automatically sound > > like getting yet another typing saver. > Maybe I am just being lazy, but it's not a typing saver but regarding > the previous not-Unicode aware versions it's more a "preventer of a > typing enhancer" :) . > > OTOH it's not just the typing but to work with commonly used things that > "just work" in other programming systems (including previous versions of > FPC/Lazarus) - like doing a "case" of a character type - ... and some things that "just don't work" like i18n. > the user > programmer needs to learn about the internal encoding of Unicode text. I > think this should be avoided. Tell the unicode consortium. My guess: they know already. > Pascal has been a great language for > programming newcomers up till now. Simple things - like characters and > strings - should just work (unless you explicitly need extended handling). > > I don't suggest that there is a simple solution for this (other than not > doing Unicode at all) but it's worth discussing. IMHO it has been already discussed too often. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > The point is: if everybody takes care of the fact that ansistrings can > > be multibyte, having utf-8 in ansistrings (if it's the locale encoding), > > is no big deal at all. > > > I do understand. But (in a real world) do you know anybody who does. > > If it would be "appropriate" for ANSI code handling to take care of > Multi-byte encoding we would not need locale-based code tables and en > effect Unicode would not have been invented. UTF-8 is unicode and it is the system encoding on linux, OS X, some BSDs and Solaris. So ansistrings are UTF-8 there. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>: > Mattias Gaertner schrieb: > > You can optimize for one encoding or optimize for one per platform. I > > know how to optimize for widestrings, for ansistring and for UTF-8 > > strings, but I have no experience in optimizing for multiple > > encodings. > > Don't forget that the ansistring type is actually multiple encodings and > even multi byte (even not considering UTF-8). The point is: nobody took > care of it. Yes, they did. They ran their programs only on systems with ansi encoded strings or simply passed the strings unchanged. That's why the lazarus solution even work with broken UTF-8 strings. But now a lot of implicit conversions will be added so all strings must have valid encodings. You can no longer pass unknown encoded strings through the functions. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and Lazarus
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>:
> On Fri, Nov 21, 2008 at 11:45 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
> >
> > In fact it should automatically convert ("as correctly as possible")
> between
> > all available string types (ANSI, UTF8, UTF16).
>
> And the compiler should produce a warning if you assign UTF8 or UTF16
> string to a ANSI string. Mentioning that conversion is not 100%
> possible and you stand a chance to loose data.
... and a possibility to tell the compiler 'Thanks, I know. Don't bark about
this place any longer'.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support - for the 20th time... ;-)
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On Thu, Nov 20, 2008 at 1:22 PM, peter green <[EMAIL PROTECTED]> wrote: > > > > The thing is we can't reasonablly provide functions based on what a user > > would see as a character because doing so would require huge lookup tables > > (one user visible character != one code point) so the best we can do is > code > > point based which isn't really much better for most tasks than code unit > > I think basing those functions on code points should suffice. I also > think as soon as strings are assigned or loaded from file, they should > be normalized. So two code points like the A and Umlaut code points > would become one. > > The .SaveToFile() methods could take an optional parameter to decide > if the normalized version of the string gets saved, or if it must be > split again - which I think Mac OS-X prefers. Mac OS X (or better: HFS) auto normalizes. SaveToFile just needs unicode. Normalization is only important when comparing filenames. That's why lazarus code always uses CompareFilenames. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Unicode and Lazarus
Zitat von Felipe Monteiro de Carvalho <[EMAIL PROTECTED]>: > if a real utf8string would be a solution for Lazarus (I am not saying > it is, but it could be), we need to have a directive to change the > default string into utf8string. To avoid a huge amount of code to need > to be suddenly changed. Then only "ansistring" needs to be changed. Compiler support for a unicode string is not enough for the LCL. As long as base classes like TStrings uses ansistrings, the LCL must use a string type, that does no conversion. For example: Items[i]:=Caption; As long as Items[i] is treated as ansi, any automatic conversion can loose unicode characters. So the roadmap from LCL pov is: - compiler support for some unicode string on every platform: done in fpc 2.3, thanks to Florian - a RTL using unicode strings - changing the string types in the lazarus code - a fpc release with the unicode RTL Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Mysql without macros
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Fri, 14 Nov 2008, Mattias Gärtner wrote: > > > Hi, > > > > The mysqlconn.inc uses macros. This is unnecessary and has some > disadvantages. > > Namely, the lazarus codetools get confused :-) ... and the users, that (mis)uses this code as example for coding. I think it is a great FPC feature, that the most native and platform independent language allows to code without macros (not only in theory). > > Here is a patch that replaces the macros with simple type aliases. > > Good idea... > > > As far as I can see mysqlconn.inc is the same for fpc 2.3.1 and fpc 2.2.x, > > so the patch should work for both. > > Applied, and will merge to 2.2.3 so it gets included in 2.2.4. > > That is, after I finished merging all my other patches... thanks, Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Mysql without macros
Hi,
The mysqlconn.inc uses macros. This is unnecessary and has some disadvantages.
Here is a patch that replaces the macros with simple type aliases.
As far as I can see mysqlconn.inc is the same for fpc 2.3.1 and fpc 2.2.x, so
the patch should work for both.
Mattias
Index: packages/fcl-db/src/sqldb/mysql/mysqlconn.inc
===
--- packages/fcl-db/src/sqldb/mysql/mysqlconn.inc (revision 12078)
+++ packages/fcl-db/src/sqldb/mysql/mysqlconn.inc (working copy)
@@ -1,6 +1,5 @@
{$mode objfpc}{$H+}
-{$MACRO on}
interface
@@ -8,30 +7,14 @@
Classes, SysUtils,bufdataset,sqldb,db,dynlibs,
{$IfDef mysql50}
mysql50dyn;
- {$DEFINE TConnectionName:=TMySQL50Connection}
- {$DEFINE TMySQLConnectionDef:=TMySQL50ConnectionDef}
- {$DEFINE TTransactionName:=TMySQL50Transaction}
- {$DEFINE TCursorName:=TMySQL50Cursor}
{$ELSE}
{$IfDef mysql41}
mysql41dyn;
-{$DEFINE TConnectionName:=TMySQL41Connection}
-{$DEFINE TMySQLConnectionDef:=TMySQL41ConnectionDef}
-{$DEFINE TTransactionName:=TMySQL41Transaction}
-{$DEFINE TCursorName:=TMySQL41Cursor}
{$ELSE}
{$IFDEF mysql4} // temporary backwards compatibility for Lazarus
mysql40dyn;
- {$DEFINE TConnectionName:=TMySQLConnection}
- {$DEFINE TMySQLConnectionDef:=TMySQL40ConnectionDef}
- {$DEFINE TTransactionName:=TMySQLTransaction}
- {$DEFINE TCursorName:=TMySQLCursor}
{$ELSE}
mysql40dyn;
- {$DEFINE TConnectionName:=TMySQL40Connection}
- {$DEFINE TMySQLConnectionDef:=TMySQL40ConnectionDef}
- {$DEFINE TTransactionName:=TMySQL40Transaction}
- {$DEFINE TCursorName:=TMySQL40Cursor}
{$EndIf}
{$EndIf}
{$EndIf}
@@ -149,6 +132,33 @@
EMySQLError = Class(Exception);
+{$IfDef mysql50}
+ TMySQL50Connection = TConnectionName;
+ TMySQL50ConnectionDef = TMySQLConnectionDef;
+ TMySQL50Transaction = TTransactionName;
+ TMySQL50Cursor = TCursorName;
+{$ELSE}
+ {$IfDef mysql41}
+TMySQL41Connection = TConnectionName;
+TMySQL41ConnectionDef = TMySQLConnectionDef;
+TMySQL41Transaction = TTransactionName;
+TMySQL41Cursor = TCursorName;
+ {$ELSE}
+{$IFDEF mysql4} // temporary backwards compatibility for Lazarus
+ TMySQLConnection = TConnectionName;
+ TMySQL40ConnectionDef = TMySQLConnectionDef;
+ TMySQLTransaction = TTransactionName;
+ TMySQLCursor = TCursorName;
+{$ELSE}
+ TMySQL40Connection = TConnectionName;
+ TMySQL40ConnectionDef = TMySQLConnectionDef;
+ TMySQL40Transaction = TTransactionName;
+ TMySQL40Cursor = TCursorName;
+{$EndIf}
+ {$EndIf}
+{$EndIf}
+
+
implementation
uses dbconst,ctypes,strutils;
@@ -349,7 +359,19 @@
function TConnectionName.AllocateCursorHandle: TSQLCursor;
begin
- Result:=TCursorName.Create;
+ {$IfDef mysql50}
+Result:=TMySQL50Cursor.Create;
+ {$ELSE}
+{$IfDef mysql41}
+ Result:=TMySQL41Cursor.Create;
+{$ELSE}
+ {$IFDEF mysql4} // temporary backwards compatibility for Lazarus
+Result:=TMySQLCursor.Create;
+ {$ELSE}
+Result:=TMySQL40Cursor.Create;
+ {$EndIf}
+{$EndIf}
+ {$EndIf}
end;
Procedure TConnectionName.DeAllocateCursorHandle(var cursor : TSQLCursor);
@@ -957,7 +979,19 @@
class function TMySQLConnectionDef.ConnectionClass: TSQLConnectionClass;
begin
- Result:=TConnectionName;
+ {$IfDef mysql50}
+Result:=TMySQL50Connection;
+ {$ELSE}
+{$IfDef mysql41}
+ Result:=TMySQL41Connection;
+{$ELSE}
+ {$IFDEF mysql4} // temporary backwards compatibility for Lazarus
+Result:=TMySQLConnection;
+ {$ELSE}
+Result:=TMySQL40Connection;
+ {$EndIf}
+{$EndIf}
+ {$EndIf}
end;
class function TMySQLConnectionDef.Description: String;
@@ -965,8 +999,30 @@
Result:='Connect to a MySQL '+MySQLVersion+'database directly via the client library';
end;
-initialization
- RegisterConnection(TMySQLConnectionDef);
-finalization
- UnRegisterConnection(TMySQLConnectionDef);
+{$IfDef mysql50}
+ initialization
+RegisterConnection(TMySQL50ConnectionDef);
+ finalization
+UnRegisterConnection(TMySQL50ConnectionDef);
+{$ELSE}
+ {$IfDef mysql41}
+initialization
+ RegisterConnection(TMySQL41ConnectionDef);
+finalization
+ UnRegisterConnection(TMySQL41ConnectionDef);
+ {$ELSE}
+{$IFDEF mysql4} // temporary backwards compatibility for Lazarus
+ initialization
+RegisterConnection(TMySQL40ConnectionDef);
+ finalization
+UnRegisterConnection(TMySQL40ConnectionDef);
+{$ELSE}
+ initialization
+RegisterConnection(TMySQL40ConnectionDef);
+ finalization
+UnRegisterConnection(TMySQL40ConnectionDef);
+{$EndIf}
+ {$EndIf}
+{$EndIf}
+
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel Computing
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > There is almost no speed difference from one thread or two threads on > > a two core machine. :( > > I will soon test on a 2 x quad core with 8 threads. > > > Great example. Thanks for sharing the results with us ! > > You said "less than expected", so you did expect a better result. Yes, I expected more, because the filters were not yet optimized. I thought the filters were still below the memory throughput and that's why multi threading should give a good speed gain. Both cores are at 100% and the critical sections are only called between big blocks. I will investigate this further, but it is already a good example, that 'simply' adding "parallel" keyword does not necessarily accelerate programs, even those with loops that look like perfect OMP examples. > Do you have an idea what the technical reason could be ? I guess Florian gave a reason. Although I think there must be more than that. I will tell, when I find out. > I tool a look at the C code of one of the example projects in the ALIOTH > test. Here they seemingly used SIMD vector operations via "typedef int > v4si __attribute__ ((vector_size(16))); // vector of four ints". Maybe > this helps more with such calculations, but I have no idea how this > could be done using FPC. I did some tests with MMX vectors and the results were surprising: Adding two 4xsingle vectors can be done with one single MMX command. FPC already uses MMX instructions, but is not clever enough to combine the four additions into one. But todays cpus are smart enough to do that themselves. And because assembler functions can not be inlined by FPC yet, while pascal functions can be inlined, the pascal function runs at top speed, while the assembler function with the SIMD opcode is much slower because of the call/ret. Conclusion: Multithreading and multi cores could accelerate lots of things, but the above examples (mt and simd) show that contrary to popular believe simply adding 'parallel' or using MMX does not accelerate. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Re[2]: [fpc-devel] Unicodestring branch, please test and help fixing
Zitat von Joost van der Sluis <[EMAIL PROTECTED]>: > Op vrijdag 12-09-2008 om 13:22 uur [tijdzone +0200], schreef JoshyFun: > > > A> Thanks for pointing me to the Lazarus thread about this and the bug > > A> report. Checked them. > > A> But as I understand there is no solution available at the moment for > this. > > > > I had partially solved the problem using the handler "OnGetText" ? > > (I'm not sure about the name) for each field which is somehow dirty > > forcing a codepage to UTF8 conversion (in Lazarus you will find some > > codepage<->UTF conversions available). > > I think that the original poster didn't looked very well in the > archives, this solution is told here quite often. > > > A> I have a database that is not encoded utf8 (and it will never be because > > A> other client programs are accessing it and their users do not want/need > > A> to be converted to unicode). How do I get the field values into > > A> FPC/Lazarus into a string variable? Right now the non-unicode strings > > A> are returned as empty from a database field due to FCL conversion > functions. > > > > If you will need this as a fixed solution for this project maybe you > > can think in create a new database unit file based in the current one > > (change the name of course) with hardcoded UTF8 encoding from codepage > > for each string once retrieved from the database. Take care about > > string length as UTF8 ones will be equal or longer than the original > > ones. > > You can just override one single method to do this. This is also told a > few times on this list. Maybe it is not documented at the right place? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Zitat von listmember <[EMAIL PROTECTED]>:
>[...]
> You have multilanguage text as data. Someone has asked you to search it
> and see if a certain peice of string (in a given language) exists in it.
>
> This search needs to be NOT case-sensitive.
>
> How can you do this?
>
> Is it doable if TCharacter (or wahtever you call it) has no 'langauge'
> attribite?
>
> [Note that, here 'TCharacter' isn't necessarily an object; it might as
> well be a simple record structure.]
AFAIK for most programmers this is not a common task. Most programs need less
(one language or codepage) or more (phonetic, semantic, statistical search).
Can you explain, why you think that this particular problem requires compiler
magic?
> []
> Is there, in Unicode, start-stop markes that denote 'language'?
Is it needed?
Are the any unicode characters, that upper/lower depend on language?
>[...]
> Comparing is a lot more important an operation than collating --or,
> rather, collation is achieveable only if you can do proper comparisons.
>
> Take this, for example:
>
> "if SameText(SomeString, SomeOtherString) then do ..."
>
> For this to work properly, in both 'SomeString' and 'SomeOtherString',
> you need to know which language *each* character belongs to.
Comparing texts can be done with various meanings. For example: byte comparison,
simple case insensitive comparison, not literal comparison, compare like this
library,
Which one do you mean?
>[...]
> Here is a simple example for you:
>
> "if SameText('I am on FoolStrasse', 'I am on FoolStraße') then do ..."
>
> Now.. how are you going to decide that SameText() function here returns
> true unless you have information that the substring 'FoolStraße' is in
> German?
The two strings have the same language, but are written with different
Rechtschreibung. You need dictionaries and spelling systems to implement such
comparisons. This is beyond a compiler or a RTL.
> I know that this is a very simple example --that 'ß' exists only in
> German, and that you could infer that when you met that char.
>
> But, this hightlights the problem --and there are times when you cannot
> infer.
>
> > In any case, I can write up several different algorithms how to do that.
>
> Please do. SameText(), for one, will need all the help it can get.
>
> > What I can not do (or what I do not want to do) is to decide which of
> > them other people do want to use.
>
> But, isn't this just that: IOW, you're deciding what other people will
> NOT want to use if you throw the 'language' attribute (for each char)
> out of the window..
What about loan words?
> > Or, if this is not what you think of, please clarify by example..
>
> Here is another typical example:
>
> SameText('Istanbul', 'istanbul') can only return true when both
> 'Istanbul' and 'istanbul' are *not* in Turkish/Azerbeijani.
>
> Otherwise, the same SameText() has to return false.
I doubt that it is that easy.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicodestring branch, please test and help fixing
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On 9/10/08, Micha Nelissen <[EMAIL PROTECTED]> wrote: > > > TCharacter and TString to be more intelligent with what encoding it > > > represents etc... And if you have an application with many strings, it > > > might actually save memory, because flyweight objects are used from a > > > pool. > > > > > > > Save memory? > > 1) storing information for each character > > 2) pool retains old classes I assume, so consumes unused memory; how can > > this ever save memory? > > Please read the following... > > http://exciton.cs.rice.edu/JavaResources/DesignPatterns/FlyweightPattern.htm > > http://en.wikipedia.org/wiki/Flyweight_pattern > > Design Patterns - Elements of Reusable Object-Oriented Software > (aka GOF book) > "Most contemporary document editors don't use an object for every > character, presumably for efficiency reasons. Calder demonstrated that > this approach is feasible in his thesis [Cal93]. Calder's glyphs can > be shared to reduce storage costs, thereby forming directed-acyclic > graph structures. We can apply the Flyweight pattern to get the same > effect." â A Case Study (chapter) This is about glyphs, not values of characters. > [Cal93] - Paul R. Calder. Building User Interfaces with Lightweight > Objects. PhD thesis, Stanford University, 1993. > > > Also related to your point (2). Reference counted objects can be used. > So "old" objects get freed automatically. The reference will need at least a UTF18 sized value, which for speed reason will probably result in 3 bytes. So for human readable texts the memory will be comparable to non class based unicode strings. It does not safe memory, but it does not cost more neither. But IMO it costs a lot of speed. This is not so important for text editors, where the glyphs, unicode, rtl, tabs, ... processing takes the biggest part of the time. For all other string algorithms I need the speed of arrays and base types. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Michael Schnell <[EMAIL PROTECTED]>: >[...] > > There are already some examples in the docs. So the system is there and > > _only_ > > needs to be filled. > > > So an _easy_ way to have the users provide examples might be helpful. Well, it is not a one click action, but it is not difficult neither: Create the example, save it under docs/xml/lcl/unitname/something.pas and set the filename in the fpdoc editor. For instance the example of TRadioGroup points to extctrls/radiogroup.pas. >[...] > >> With Lazarus it would be best if the Delphi help could be linked in by > >> the users (of course it can't be shipped :) ). This could be used as a > >> nice starter and everybody can obtain it legally with Turbo Delphi, > >> unless he is a legal Delphi owner anyway. > >> > > Maybe doable. Needs investigation. > > > Another goody would be that the decent Delphi 3rd party packets come in > sorcecode and with help files that can be linked in the Delphi help system. > Using this would greatly help (legal owners) porting such packets to > Lazarus I have no information about the Delphi help system and how to use it platform independent. Maybe you can provide some links? >[...] > This is exactly what had been discussed in the German Lazarus Forum. > Enhancing the German F1 help. Can you give me the link to the thread? >[...] > I (maybe) see. So "context" does not only mean "word under cursor", but > in fact it evaluates the context of same (the Delphi help does not seem > to do that.) Yes. This way the help does not only show help for the identifier itself, but for every ancestor. For example the help for TMyFormDescendant automatically shows the help for TForm. And it shows comments as well. > But why not enhance the "context" help in a way that it offers a lost of > available topics with that keyword if no topic that fits the "context" > is found (or if the user requests a list ). Time. I first worked on the tools to create help content. The next steps are to improve the presentation and context insensitive search functions. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > This works perfectly for me in Lazarus. Perhaps I missed something but > > unless you mean "offline help" > NO I did test "offline help" by d/lding the help file and setting the > path to same. This of course is no difference to the online version (if > the internet connection works). > > or "out of context help" (e.g: trying to > > get help on TForm without using unit Forms with proper paths set) then > > it works 100% in lazarus (you get browser opened with given topic in > > online help as target). > > > > Perhaps your help/browser is misconfigured? See help/configure help. > > > > Hmm. I don't think so. > > Wen I do a test application and press F1 o TForm in the line > TForm1=class(TForm) I do get a help screen > > But when I type TForm in some empty line (e.g. outside of any > procedures) I get "no help found for" TForm is out of context, so the context sensitive help does not find TForm. > So I do need to know where something is allowed to be typed before I get > any help on it. :( You want to search context insensitive. Me2. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On 8/25/08, Mattias Gärtner <[EMAIL PROTECTED]> wrote: > > > In the German Lazarus forum there recently has been a discussion on > > > improving the (German) help. There had been a suggestion to use a Wiki > > > to update / enhance the help texts. > > > > The online help already uses the wiki for the IDE windows and dialogs. You > are > > all welcome to help improve the pages with examples that newbies > understand. > > For me as developer many things are obvious and so I often can't imagine > the > > problems of newbies. That's why we need the help of users - hint, hint. > > Which reminds me of another bug in Lazarus. > > Change the Lazarus IDE default language to German. Restart the IDE. > Now open the Compiler options and click the 'Hilfe' (help) button. > The English help is displayed and not the German wiki help. > > http://wiki.lazarus.freepascal.org/index.php/IDE_Window:_Project_Options > > instead of the German... > > http://wiki.lazarus.freepascal.org/index.php/IDE_Window:_Project_Options/de > > > PS: > I have no idea how you would test if the translated (non-english) > version exists in the wiki or not. Yes, that's why and we don't know how up2date they are. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > Do you mean the fact that an external browser is started or the fpdoc html > pages > > or the wiki pages? > > The search functions are bad in all three of them. > > > I did not want to start a long winded discussion here :( Yes, noted. But some points you mentioned I don't understand. So I wonder if you spotted a bug. > IMHO the context-sensitive online-help (in Lazarus) is simply not usable > (while the context-sensitive help in (also free of charge) Turbo-Delphi > is not perfect but a lot better). > - You should get a decent result when hitting F1 on any keyword (of the > language, the RTL or the LCL: language-keyword, type, class, function, > procedure, property, public variable, variable, ...) Yes. As I said: pascal keywords are a problem because they are only in latex docs. > - there should be examples for the use of the topic There are already some examples in the docs. So the system is there and _only_ needs to be filled. > - there should be cross references to related and to similar topics For example the LCL docs already have 485 links to related topics. Not counting the automatic and ancestor links. Again: system is there and _only_ needs to be be filled. > - ... :) > > > Yes, Delphi had always a very good help with lots of examples. > > > > Writing a good help is a lot of work. > > FPC and Lazarus have more than 200.000 identifiers in more than 1000 units. > > > With Lazarus it would be best if the Delphi help could be linked in by > the users (of course it can't be shipped :) ). This could be used as a > nice starter and everybody can obtain it legally with Turbo Delphi, > unless he is a legal Delphi owner anyway. Maybe doable. Needs investigation. > > The online help already uses the wiki for the IDE windows and dialogs. You > > are all welcome to help improve the pages with examples that newbies > > understand. > > > If this is not included in the context-sensitive online-help this is no > fun at all ;) . Huh? I'm only talking about the context sensitive online help. The F1 function of lazarus. Maybe you are talking about fpide? > > For the source documentation fpdoc is used and the fpdoc editor is one > > click away. So every user can edit the help ad hoc. The only problem is to create > > a patch and send it. Maybe someone can write a gui tool for creating patches > > to make this easier. > > > Yep. Does the system support multiple languages ? Some parts yes. AFAIK fpdoc has, the wiki too. But the context sensitive help of the IDE does not yet support that. The problem with the wiki is that the IDE does not know, if a page has already a translation. The problem with fpdoc is my free time. > > A wiki for the source documentation is a bad idea, because of the > > update/rename/delete issues. > > > Seems like you are right here. But regarding the translations this might > be not as critical as with the original text. > > What 'context-sensitivity' needs improvement? F1 is context sensitive. > > > Right, but in many (or most) cases it does not work. It seems (much more > than the Delphi help) to try to prevent offering a topic that is not the > correct one, so it seems to analyze the context of the word under the > cursor. That means it only works if the source code already is quite > correct (which the user often only can do after reading the help, so we > have a deadlock, so that is a very bad idea, IMHO). > > In Delphi I simply type a word (i.e. "TForm") in an empty line and press > F1 to get help on TForm. This is the usual way I learn about new > components I'd like to use. This does not seem to work for me in Lazarus. I typed TForm, pressed F1 and got: http://lazarus-ccr.sourceforge.net/docs/lcl/forms/tform.html The help for identifiers only works, if the IDE can find the declaration. It does not yet search in the registered classes, nor in the whole documentation. If you want help for an identifier without proper declaration, then you want a context *insensitive* search and as I said: this is missing. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > Lazarus context sensitive help shows documentation of the fpdoc files and > > comments from pasdoc (similar to javadoc, DelphiCodeToDoc) and it browses > > through the class hierarchy to show ancestor help. The help content can be > > edited in the IDE context sensitive or via lazde and Kirk is doing a great > job > > here. > > > Sounds good. But nonetheless whenever I talk to a Lazarus newbie he says > is learning curve is bad because of the much little information is and > the bad usability of the help system. Do you mean the fact that an external browser is started or the fpdoc html pages or the wiki pages? The search functions are bad in all three of them. > I recommend installing the free > Turbo Delphi start it, type a code word in it's Editor Window and press > F1. With this they in fact do learn to use Lazarus, while they would > give up otherwise. Yes, Delphi had always a very good help with lots of examples. Writing a good help is a lot of work. FPC and Lazarus have more than 200.000 identifiers in more than 1000 units. > In the German Lazarus forum there recently has been a discussion on > improving the (German) help. There had been a suggestion to use a Wiki > to update / enhance the help texts. The online help already uses the wiki for the IDE windows and dialogs. You are all welcome to help improve the pages with examples that newbies understand. For me as developer many things are obvious and so I often can't imagine the problems of newbies. That's why we need the help of users - hint, hint. For the source documentation fpdoc is used and the fpdoc editor is one click away. So every user can edit the help ad hoc. The only problem is to create a patch and send it. Maybe someone can write a gui tool for creating patches to make this easier. A wiki for the source documentation is a bad idea, because of the update/rename/delete issues. Some docs needs improvements: - the fpc keywords like 'procedure' (they are described in latex documents) - fpc messages (too short and no links to related information) - translations - the bigger picture (tutorials and books) > But an automated system to update > the online help files would be needed to make this useful. (Moreover the > usability (e.g the "context-sensitivity") of the Lazarus help system > needs a great improvement, but this of course has to be discussed > elsewhere). What 'context-sensitivity' needs improvement? F1 is context sensitive. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc and fv
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > Michael Van Canneyt wrote: > > Someone else generates the pdf classchart from a OpenOffice spreadsheet. > > > Would it not be appropriate to base a help system (for the RTL > functions) on something like "DelphiCodeToDoc" and do an automation for > the process ? > > With this the Lazarus hopefully could display a decent context sensitive > help and use the same help generation scheme for the LCL. Lazarus context sensitive help shows documentation of the fpdoc files and comments from pasdoc (similar to javadoc, DelphiCodeToDoc) and it browses through the class hierarchy to show ancestor help. The help content can be edited in the IDE context sensitive or via lazde and Kirk is doing a great job here. The html content like formatting and links is currently only shown on the html pages or the chm help files. I already started a html viewer using tpipro for the IDE. This should show the formatting and hyper links. The information for the class chart can be easily extracted via lazarus and codetools in seconds. If someone provides a tool to browse a class chart of thousands of classes, I can help you getting the data. Of course for fpdoc as command line utility independent of lazarus something else is needed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to make the compiler message "PPU Invalid Version" a fatal error.
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > In our previous episode, Mattias Gärtner said: > > > > Any progress? > > > > > > IIRC, we once had the idea to feed the compiler an error message file > > > with only error numbers as error "messages" so parsing would be easier. > > > > The error number is needed, yes. > > But without text debugging becomes harder. > > So you would need a dual system, all info in the beginning of the line > easily (and safely) parsable, and the text version behind it to pass through > to the user? Yes. I know, I can do that simply by sed-ing the errore.msg. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to make the compiler message "PPU Invalid Version" a fatal error.
Zitat von Marc Weustink <[EMAIL PROTECTED]>: > Mattias Gaertner wrote: > > On Wed, 13 Aug 2008 23:12:25 +0200 (CEST) > > Daniël Mantione <[EMAIL PROTECTED]> wrote: > > > >> [...] > The text mode IDE can display statisics while compiling. Why can't > Lazarus? > > There is the compiler unit, which *is* available, and this is the > only officially supported compiler interface. We are not against > other officially supported interfaces, but parsing messages is > definately not an offical interface and recommended against. It is > not the first time we have this discussion, we discussed possible > protocols before. > >>> Can you give a link? > >> http://lists.freepascal.org/lists/fpc-devel/2006-May/007788.html > > > > Thanks. > > The thread did not discuss all problems, but it has one good idea: > > We need a machine readable output format for fpc. > > Any progress? > > IIRC, we once had the idea to feed the compiler an error message file > with only error numbers as error "messages" so parsing would be easier. The error number is needed, yes. But without text debugging becomes harder. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal to make the compiler message "PPU Invalid Version" a fatal error.
Zitat von ik <[EMAIL PROTECTED]>: > On Wed, Aug 13, 2008 at 6:58 PM, Micha Nelissen <[EMAIL PROTECTED]> wrote: > > Bernd Mueller wrote: > >> > >> I think, the proper way could be, that fpc makes this message fatal, if > >> the unit source is not present. > > > > The proper way is probably for Lazarus to parse also other messages in case > > of Fatal, to give more context :-). > > The problem is that there are multiple languages for FPC's error > messages, so it's not that simple. Maybe each error message will start > with the error code ? FYI: Because there are several tools to parse FPC/Make/whatever output it is planned to tell fpc to always give english output and show the translated text in the messages window. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Zitat von Henri Gourvest <[EMAIL PROTECTED]>: > 2008/8/8 Mattias Gärtner <[EMAIL PROTECTED]>: > > Correct me if I'm wrong, but this seems not very comfortable. > > - No custom sort function (unless you override) > ... > > > - A node does not know its parent. So with First or Search you can not get > to > > the next node. You need always an iterator (iterators should be optional). > it is your own opinion, personnaly I need more than one cursor on the tree. I meant: I can not use the First to get to the second. I must create an iterator. The current avl tree has a 'parent' of each node, so you can have as many 'cursors' as you want without iterators. I know this costs an extra pointer memory per node, which might be bad in some cases. But I was talking about comfort. > > - no function to resort the tree > the tree is autobalanced .. with a compare function. If you want to change the compare function, you need to create a new avl tree and add manually all nodes. The current FPC avl tree has a simple property for the compare function which can be set any time. > > - no functions to reorder nodes with same keys > it is useless, you can do everything in the same compare function if > you have more than one key. I meant: For example: two different items with Compare(Item1,Item2)=0. The order between those two is free and the avl tree does not care. So I can reorder them. This is needed in some algorithms. You can work around this, but it is comfortable to have the ability. > > - You have to override to actually store some data > > You are describing an avl tree, it do exactly what it expected to do > regardless of data type. I meant the default tree can not even store a pointer. You have to create a descendant. > it is usefull for me, I hope it will be usefull for someoneelse. No offense meant. I just pointed out, that it misses some nice-to-haves. > > - it's not 64bit save > 8-| why do you say that ? Because of this: AVL_MAX_DEPTH = sizeof(longint) * 8; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Zitat von Henri Gourvest <[EMAIL PROTECTED]>: > I made 2 AVL tree for different kind of problems > > this one is generic (32/64+all platformes) > http://uib.svn.sourceforge.net/viewvc/uib/trunk/source/uibavl.pas?view=markup > it is based on http://www.geocities.com/wkaras/gen_c/cavl_tree.html Correct me if I'm wrong, but this seems not very comfortable. - No custom sort function (unless you override) - A node does not know its parent. So with First or Search you can not get to the next node. You need always an iterator (iterators should be optional). - no function to resort the tree - no functions to reorder nodes with same keys - You have to override to actually store some data - it's not 64bit save > this one only index string and use both Hash and AVL tree for better > performances (32/64+all platformes) > http://jsontoolkit.svn.sourceforge.net/viewvc/jsontoolkit/trunk/superobject.pas?view=markup > I use it to store JSON data This seems to have the same limitations. ? Mattias > You are free to use them > > Henri Gourvest > > > I think too, that we need a fast, lightweight tree and a slower, but > > customizable tree. Something like TFPList and TList. One without virtual > > methods and one with virtual methods and definable node class. > > > > > > Mattias > > > > ___ > > 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 > -- Powered by NetMail ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Zitat von Marc Weustink <[EMAIL PROTECTED]>: > Marco van de Voort wrote: > >> Marco van de Voort wrote: > Inoussa OUEDRAOGO wrote: > > - TAVLManagedTree that uses a node mem manager provided in the > constructor. > >The developer using this one is _aware_ of the thread safety issue > and can > >then provide a thread safe node mem manager for an instance exposed > What is exactly the add-on value for the node mem manager? > >>> I can only think of heap fragmentation and reduction of creation > overhead. > >> Yes, but fpc's memory manager also already does this (at least if the > >> allocation size is less than 512 bytes or so). > > > > But fpc's memory manager won't be always used. There is cmem, and a future > > sharemem as options too. And sharemem-likes are known to be slow. > > > > The "memmanager might also do this" might be a reason to not enable it by > > default, but not a reason to eliminate the possibility all together. > > I'm pro having a manged and an unmanaged avltree. One (big) disadvantage > of the current implementation (with a shared node manager for all trees) > is that you cannot add custom derived treenodes since they will be > released in the pool too. I think too, that we need a fast, lightweight tree and a slower, but customizable tree. Something like TFPList and TList. One without virtual methods and one with virtual methods and definable node class. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Zitat von Burkhard Carstens <[EMAIL PROTECTED]>: > Am Mittwoch, 6. August 2008 21:37 schrieb Sergei Gorelkin: > > Since this topic is touched, I would like to vote for removing > > avl_tree dependency from the DOM altogether. The reason is that the > > avl tree of child nodes is useless for any real-world XML data > > because it does not handle duplicate names. The tree is useful only > > for the one particular case of XML configs where each node name is > > unique. OTOH, it causes considerable performance penalties (each > > insert results in two searches, first one for checking the existence, > > second one for insert itself; each search is a number of calls to > > Node.GetNodeName, which, in case of Windows, is a Widestring copy, > > etc.) The widestrings version is slow under linux too. Last time I tested (a few months ago) it was about 2 to 10 times slower than the ansistring version. Mainly because of the parser. > > Therefore I'd suggest to remove the avltree from DOM. > > This would be great to have in 2.2.2. > > > In order to > > keep configs at the reasonable speed, it is possible to implement > > indexing within TXMLConfig class itself, preferably hashmap-based. > > This would be a performance tweak which (from my POV) does not need to > be in 2.2.2, although it would be nice. The performance penalty without the trees can be quite big for things like txmlconfig. For example for lazarus project files it can be a hundred times slower without the trees. Note: lazarus itself uses its own ansistring version of xml parser, so this not a direct problem for lazarus. > > Alternatively, it is possible to use Registry-like access > > (OpenKey/CloseKey methods) that I had already implemented in newer > > xmlconf.pp unit. The advantage is that the searches are done starting > > from the 'opened key', not from the root, so linear search isn't too > > slow. > > If I understand correctly, this would change the usage of xmlconfig > which would require changes to any existing code using it? If so, it's > probably not an option for 2.2.2, maybe even not for 2.2.4 .. I second that. The main advantage of TXMLConfig is it's easy usage. I guess you can gain some speed by implementing some kind of caching for paths. Maybe I will do that for the lazarus ansistring version. But IMO this is too risky for fpc 2.2.2 which is released soon. About avl tree: For thread safety I guess the best thing is to not use the node mem manager. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Zitat von Joost van der Sluis <[EMAIL PROTECTED]>: > Op woensdag 30-07-2008 om 11:33 uur [tijdzone +0200], schreef Florian > Klaempfl: > > Marco van de Voort schrieb: > > > > > > Read this and the reactions, and weep: > > > > > > > http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voort+multicore#289008199451755a > > > > I don't agree on the point that good mt support is a matter of the > > framework. _Really_ good multithreading support is a matter and must be > > a matter of the language as well and in several years and must be as > > common as while or for loops. Currently, multithreaded programming is > > like programming spaghetti basic. A good framework is comparable to at > > least the try to program structured with line numbered basic but it is > > not forced by the language. The compiler must know about parallism. > > I'm not really into paralel-computing. But it does interest me. > > Just to test some ideas/opinions. Could something like this be usefull? > > Function DoSomething(const astring : string) : boolean; parallel; > begin > .. > end > > So that the 'parallel' keywords means that if you call this procedure, > it's started in a separate thread. (maybe just a compiler hint, like in > inline. So that the compiler can decide) > If you actually use the result somewhat further in you program, the > compiler detects this and waits for the other thread to finish, before > it continous. > > Ofcourse, of someone uses some globa-vars in an 'parallel' procedure, he > could be doomed, if he don't know what he does. But maybe the compiler > can even forbid this. > > Would this be usefull at all? Doable? There is a wiki about that discussion: http://wiki.freepascal.org/OpenMP_support Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > If this was true, Java would have taken that market already. There is > > nothing new to that aspect of CIL, and specially with only one minor vendor > > supporting it. > > > Basically you are right, but > - In fact Java is very widely in use (even though there are lots of > shortcomings regarding Java ) Which is mostly due to the garbage collector. There are already java coprocessors boosting java to native speed. > - AFAIK, CIL seems to improve some of the Java shortcomings I'm curious. Has someone evidence for that? > - CIL defines concepts for multi-treading and multi-processing > - every year the processing performance and available memory resources > improve and thus creating "economical" object code is less critical Same for java. I have some doubts about the increases of processing performance. The speed ups of the last years were mainly due to multiple cores. The increase of speed of a single core decreased. In fact many recent computers like the eeepc are pretty slow to get longer run times. And writing multithreaded code is economically more expensive than single threaded. So I see a strong need for native compilers like FPC. > - While (AFAIK) there are no (or only very few and rarely used) > languages besides Java that can create byte code for the just-in-time > compiling Java Framework, There are a lot languages with compilers form > different brands usable with CIL (several C# compilers, C++, Pascal, > (Oxygen and Delphi), Visual Basic, Iron-Python, .., Java->CIL compiler ?> ) Yes, but I didn't test it. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC boost features
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > [...] > If FPC didn't worry > to much about compatibility and instead implemented Unicode support > long ago like it could have, it might just have boosted FPC usage, > beating Borland to the punch by about 7 years. FPC could have > attracted and converted more Delphi developers... > [...] I wonder, what the next 'boost' feature of fpc is, that Delphi does not have yet: Automatic parallelization, language extensions for parallelization, fpc as scripting language, fpc as browser plugin, packages like cpan, jit compiling? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I get duplicate GUIDs under Linux
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/5/29 Mattias Gärtner <[EMAIL PROTECTED]>: > > > > It would hurt a lot *not* installing the patch. The bigger problem is that > the > > other distributions including windows, Mac OS X, BSD, ... server must now > > install the blacklist too. I guess non debian systems now have bigger > problems > > than debian. > > Yeah, I google'd the debian fiasco to get a better understanding. > It's a *huge* screw-up! > > >> I gather that you can reproduce the issue and also get stuck on 1021? > > > > Yes. 1019 > > > > And then pango gave: > > (testproject:27449): Pango-WARNING **: error opening config file > > '/etc/pango/pangorc': Too many open files > > Apparently CreateGUID is buggy and should not be used under Linux. > > I need to convert existing data to our new system, so I am in need of > a lot of GUID's quickly. At least in the interim I have a workaround > via the 'libuuid' unit, otherwise I would be in big trouble. > > How can I force my fpc to use the 'random' option, instead of > '.../random/uuid'? Or must I copy and paste the code from RTL into my > own function? If the GUID are used in security contexts, then you *must* wait and gather some real random numbers. Otherwise you can simply call Randomize once at the start of the program and use: Procedure GetRandomBytes(Var Buf; NBytes : Integer); Var I : Integer; P : PByte; begin P:[EMAIL PROTECTED]; For I:=0 to NBytes-1 do P[i]:=Random(256); end; Randomize; // call this only once every few seconds for i:=0 to 500 do begin GetRandomBytes(GUID,SizeOf(Guid)); This gave me 5 mil unique guids. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I get duplicate GUIDs under Linux
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/5/29 Mattias Gärtner <[EMAIL PROTECTED]>: > > > > Sorry. Openssl has *nothing* to do with the CreateGUID function. > > I thought that much, but then thought it wouldn't hurt installing the > patch anyway. It would hurt a lot *not* installing the patch. The bigger problem is that the other distributions including windows, Mac OS X, BSD, ... server must now install the blacklist too. I guess non debian systems now have bigger problems than debian. > >> What is really weird is that once I hit the 1021 limit, I can't run > >> that method again. I get a duplicate after 1 add! It seems to behave > >> exactly like random() without calling randomize(). It seems to > >> remember the last "position" it it's seed or something and tries to > >> continue where it left off. The same pattern, over and over. > > > > Maybe the 1021 is the limit of /dev/random. > > I gather that you can reproduce the issue and also get stuck on 1021? Yes. 1019 And then pango gave: (testproject:27449): Pango-WARNING **: error opening config file '/etc/pango/pangorc': Too many open files Apparently CreateGUID is buggy and should not be used under Linux. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I get duplicate GUIDs under Linux
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/5/29 Mattias Gärtner <[EMAIL PROTECTED]>: > > > > Sounds like the Debian openssl key fiasko. > > I saw Ubuntu had some updates to resolve this issue on my system. Got > the updates, rebooted, recompiled my application and still 1021 is my > limit before I get duplicates. Sorry. Openssl has *nothing* to do with the CreateGUID function. But the CreateGUID calls the kernel function and if this does not work it calls Randomize and calls 16 times random(256). But Randomize only work from time to time, so don't call it often - Bug in GetRandomBytes. IMO GetRandomBytes needs to check if Randomize has been called. Or even better: Randomize should not reset the sequence if no random number is available. > What is really weird is that once I hit the 1021 limit, I can't run > that method again. I get a duplicate after 1 add! It seems to behave > exactly like random() without calling randomize(). It seems to > remember the last "position" it it's seed or something and tries to > continue where it left off. The same pattern, over and over. Maybe the 1021 is the limit of /dev/random. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] I get duplicate GUIDs under Linux
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>:
> Hi,
>
> I'm trying to do performance testing in Firebird RDBMS using GUID's
> and primary keys. I constantly got PK violations. I then wrote the
> code show below to create 50,000 GUID's and add them to a StringList
> (no duplicates allowed). Every time I run this I get a duplicate GUID
> at iteration 1021. My original test is supposed to create 5mil
> records, but I can't get past 1000! :-(
Sounds like the Debian openssl key fiasko.
Add it to the list:
http://xkcd.com/424/
Mattias
> Actual program output:
>
> [EMAIL PROTECTED]:index_performance$ ./index_performance.elf
> Duplicate value detected: {FD3DF19D-A878-F8BA-F9D1-108658451E05}
> List.Count = 1021
>
> GUID's are supposed to be very unique! Wikipedia says something like:
> Create a billion every second for 10 years or something before you
> deplete the range.
> So what is wrong with my code or maybe the Free Pascal implementation?
>
> [ code ]--
> procedure TMainForm.btnTestClicked(Sender: TObject);
> var
> sl: TStringList;
> s: string;
> i: integer;
> d: integer;
> guid: TGUID;
> begin
> sl := TStringList.Create;
> try
> try
> sl.Sorted := True;
> sl.Duplicates := dupError;
> for i := 1 to 5 do
> begin
> CreateGUID(guid);
> s := GUIDToString(guid);
> sl.Add(s);
> end;
> writeln('Created 50,000 GUIDs');
> except
> on e: EStringListError do
> begin
> writeln('Duplicate value detected: ' + s);
> writeln(' List.Count = ', sl.Count);
> end;
> on e: Exception do
> writeln('Unknown error: ', e.Message);
> end;
> finally
> sl.Free;
> end;
> end;
> [ end ]
>
>
> Changing the line that adds the GUID to the StringList by prefixing
> the counter, all is fine. So I can't see a problem in my code.
>
>sl.Add(IntToStr(i) + s);
>
>
> 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
>
--
Powered by NetMail
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: > > On Fri, 4 Apr 2008, Martin Schreiber wrote: > > > The next problem is childpos handling: > > > http://bugs.freepascal.org/view.php?id=11102 > > > > I've never understood what this is about, so some additional information > > would be welcome... > > > It is used in order change the widget stacking order in an inherited form for > example: > In ancestor form streaming- child- and creation-order is twidget1, twidget2, > twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over > twidget1, twidget3 is over twidget2. > Now you do 'Bring to Front' for twidget1 in a inherited form which changes > the > child order to twidget2, twidget3, twidget1. > The new child order must be written and read back while streaming the > descendent. It is done with ffChildPos filerflag and a following integer. > Repositioning of the inherited children is done by TComponent.SetChildOrder > IIRC. Same for lazarus. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Fri, 28 Mar 2008, Micha Nelissen wrote: > > > Michael Van Canneyt wrote: > > > It is used in streaming in the classes unit; the streaming mechanism > checks > > > the actual > > > value against this value: if it is the same, the value is not streamed. > > > > FYI: so before streaming, the "streamer" has to reset the values to their > > defaults to stream properly. Unfortenately, there is no function to do > this, > > and it's usually done in constructor. Therefore streaming twice does not > work > > properly. > > This is not correct. > > The default value is the value at create time and remains fixed during the > lifetime of the component. It has no influence on the number of times you > stream a component. Theoretically yes. Practically it works this way: TWriter writes a value if it differs from the 'default'. The 'default' is 1. if there is a stored function, and it returns false, then the current value is a default. 2. if there is an ancestor, then the current value of the ancestor 3. the 'default' constant of the property. So, it is not always possible to find out if _a_ value is default. You can only find out if the _current_ value is default. And even worse: This is only true for normal properties. The DefineProperties can do nearly anything. Conclusion: In general you can not 'reset' an arbitrary component. Graeme's SetDefaults could be extended to apply all ancestor streams. Then it would probably set the defaults for 99% of all properties correct, assuming that the properties define good stored functions, good constructor values and good default constants. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] suggestion: AllFilesMask constant
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On 25/03/2008, Mattias Gaertner <[EMAIL PROTECTED]> wrote: > > On Tue, 25 Mar 2008 10:30:28 +0200 > > "Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > Could FPC add a new 'all files' constant (eg: AllFilesMask) to the > > > RTL. Same as what we have PathDelimiter etc.. > > > > > > Please do a find declaration. AllFilesMask is in the system unit. > > > I just did, using Lazarus's 'Find in files' and found nothing in FPC > 2.2.0 source directory. I'll do another search. Yes, it was recently added, that's why all mentioned projects still have their own. > Lazarus also didn't code navigate (Ctrl+Click) after I typed > AllFilesMask in my source code. > > > ...searching > > > Ah, it's not defined in FPC 2.2.0, but is in FPC 2.3.1. I better wrap > my defines with a FPC version then. It is in fpc 2.2.1 too. Does '*' work under windows too? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc inherited entries
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: >[...] > > > The problem is that you may or may not have the definition (and > > > corresponding page) in memory. If the parent def (and doc) is not > > > in memory, you don't know whether a page is available or not. > > > > How do the links to the ancestor classes work? > > Through a complicated search mechanism :-) Ok. > > > > If yes, then it might be possible to traverse through all ancestors and > > > find the > > > > next existing short description, right? > > > > > > In theory, yes. > > > > :) > > > > > > > Then you need to decide what to do: > > > - Create a page for TChild.Property and simply refer to TParent.property > > > (a braindead solution imho) > > > - do not generate a page but In the 'Property/methods/Class overview' of > > > TChild, > > > refer to TParent.property whenever TChild.Property is not documented. > > > > > > In the latter case, pressing F1 on TChild.Property will refer to a > > > non-existing page. > > > > The final presentation whether fpdoc creates a 'see also' link OR copies > the > > content OR refers directly is a second step. First fpdoc must gather some > data: > > > > It should only refer, iff the TChild.Property is not documented (= has no > short > > description) and iff there is a documented TParent.Property, where TParent > does > > not need to be the direct ancestor. For example TButton.Caption should not > refer > > to TCustomButton.Caption nor TWinControl.Caption, but to TControl.Caption. > > I am more in favour of adding a new attribute to allow more control by the > documentor: > > > > It has the advantage of being faster as well: the documenting process can > use some speedup, it gets slower by the day. The disadvantage is that you > must fill it in manually - although a simple button in the editor can take > care of that: > - fill this property for the current element, > or > - for all elements with fill the closest > ancestor. Ey, I thought I do the proposal and you do the implementation!? Now it seems I have to implement this 'for all elements' function in the editor. Will you implement the fpdoc part, that means the 'link' attribute, so that fpdoc does not create the TChild.Property pages and instead directly links to the linked page and update the fpdoc docs? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc links
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Mon, 18 Feb 2008, Mattias Gärtner wrote: > > > fpdoc allows links of the form: > > > > #packagename.unitname.identifier.identifier... > > > > Are the packagename and/or unitname case insensitive? > > Yes, normally we use comparetext everywhere. > > > Or is it recommended to lower case them? > > For example: > > #LCL.Controls.TControl.Caption > > > > In the html output it seems fpdoc is clever enough to auto lowercase > everything. > > It does. Good. So it does not matter if the package name is a mix of #LCL or #lcl. Thanks. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpdoc links
fpdoc allows links of the form: #packagename.unitname.identifier.identifier... Are the packagename and/or unitname case insensitive? Or is it recommended to lower case them? For example: #LCL.Controls.TControl.Caption In the html output it seems fpdoc is clever enough to auto lowercase everything. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc inherited entries
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Mon, 18 Feb 2008, Mattias Gärtner wrote: > > > Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > > > > > > > > > On Sun, 17 Feb 2008, Mattias Gaertner wrote: > > > > > > > > > > > In the LCL there is documentation for TControl.Caption which is useful > > > > for all descendant classes like TButton.Caption too. It would be nice > > > > if fpdoc shows the content of TControl.Caption if TButton.Caption does > > > > not have a value or at least show a link to the inherited entries. > > > > > > > > Comments? > > > > > > This is in mantis as a feature request, but it is not easy to implement. > > > > I added a button to the IDE built in fpdoc editor to automatically create a > 'see > > also' link to the next documented ancestor entry. > > > > > > > Feel free to do a proposition. I'll then do the implementation :-) > > > > That's an amazing offer. > > > > fpdoc already knows the ancestor classes. So it should be possible to find > out > > the ancestor property/method/variable, right? (It's ok if the overridden > method > > search is not 100% perfect) > > The problem is that you may or may not have the definition (and > corresponding page) in memory. If the parent def (and doc) is not > in memory, you don't know whether a page is available or not. How do the links to the ancestor classes work? > > If yes, then it might be possible to traverse through all ancestors and > find the > > next existing short description, right? > > In theory, yes. :) > Then you need to decide what to do: > - Create a page for TChild.Property and simply refer to TParent.property > (a braindead solution imho) > - do not generate a page but In the 'Property/methods/Class overview' of > TChild, > refer to TParent.property whenever TChild.Property is not documented. > > In the latter case, pressing F1 on TChild.Property will refer to a > non-existing page. The final presentation whether fpdoc creates a 'see also' link OR copies the content OR refers directly is a second step. First fpdoc must gather some data: It should only refer, iff the TChild.Property is not documented (= has no short description) and iff there is a documented TParent.Property, where TParent does not need to be the direct ancestor. For example TButton.Caption should not refer to TCustomButton.Caption nor TWinControl.Caption, but to TControl.Caption. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc inherited entries
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Sun, 17 Feb 2008, Mattias Gaertner wrote: > > > > > In the LCL there is documentation for TControl.Caption which is useful > > for all descendant classes like TButton.Caption too. It would be nice > > if fpdoc shows the content of TControl.Caption if TButton.Caption does > > not have a value or at least show a link to the inherited entries. > > > > Comments? > > This is in mantis as a feature request, but it is not easy to implement. I added a button to the IDE built in fpdoc editor to automatically create a 'see also' link to the next documented ancestor entry. > Feel free to do a proposition. I'll then do the implementation :-) That's an amazing offer. fpdoc already knows the ancestor classes. So it should be possible to find out the ancestor property/method/variable, right? (It's ok if the overridden method search is not 100% perfect) If yes, then it might be possible to traverse through all ancestors and find the next existing short description, right? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > Just press Ctrl+Shift+F1 and the help context editor of the IDE opens, > where you > > can set the wiki page for every control of the current window. > Is there a standard procedure to suggest such links as a "patch" ? How to create a patch: http://wiki.lazarus.freepascal.org/Creating_A_Patch If you are unsure that the patch might be rejected, then ask on the lazarus list or the lazarus-ide IRC channel. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > There are two widgetset setting because you can use two different > > widgetsets: design time / IDE and runtime / project. > > > I found that when changing the widget set at one of the pages it is > changed accordingly at the other page. So in effect there seems to be > only one setting. Both use as default the widgetset used for building the IDE. So when you rebuild the IDE with another widgetset and restart it, then yes, the default changes. Otherwise they are independent. > > I setup the 'nogui' widgetset. > What does this mean ? Did you just try my "diff" or did you add some > functionality > > But I'm not sure if the gain is big > > enough to add it as a standard widgetset to the laz sources. > Please see my post to Micha for an explanation of what I think this is > useful for. Once I might have a truly embedded target architecture for > FP (Linux/NIOS) the significance will be obvious. Well, then start coding. :) > > Every > > extra widgetset confuses users. > > > IMHO, that is just a problem of documentation. I disagree. If there is a button, then the user expects, that the button actually does something useful and not that somewhere is written, that the feature is not yet implemented. I'm thinking about either showing the button only when the IDE is compiled with a flag or to implement 'registering widgetsets via design time packages'. > Of course I'll write some > Docu for this once it in fact should be included in the standard > distribution. In fact I don't understand fpGUI right now (but it does > not confuse me at all). Maybe I should read the Docu on that one. IMHO > it's a pity that the menus in Lazarus don't have "Help" buttons that > link to the appropriate documentation or Wiki pages (similar as LCL > components do with F1), so that documentation on those topics can be > provided. Some dialogs have a Help button. They do the same as pressing F1. Just press F1 and the wiki page for the currently focused control is opened. Just press Ctrl+Shift+F1 and the help context editor of the IDE opens, where you can set the wiki page for every control of the current window. If you find an undocumented window or if you think that a control should have a wii entry of its own, then use this editor and create a svn patch. Patches are welcome. > I did try to understand the "CGIApplication" but failed to create a > testing example due to lack of Docu (and some bigs that I did report to > the bugtracker). Yes. But Michael has created an example in the mean time. > > Probably you forgot the Makefiles. > > > I'm sure you are right with that. I did modify two Makefile.fps's > accordingly. I suppose I additionally need to create a Makefile.fpc in > the new nogui directory. > > But I don't know how to create the Makefiles form these (supposedly > using fpcmake ???) See the new wiki page. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > Some comments / questions: > > > "rebuild the IDE with the LCL. > > Does that mean just using "Tools -> Buid Lazarus", or should we use the > "Build"-Button in "Tools -> Configure Build Lazarus", with once or > multiple times with different options (e.g. "build LCL and build IDE, or > just "Build All") ? I meant: It is not sufficient to only rebuild the IDE. Maybe it is better to say: rebuild all lazarus parts. Feel free to improve this, so that a non laz devel understands it. > "fpmake" step > > I suppose this can be done in Windows as well yes > I do hope this does not rebuild the Free Pascal compiler (which I don't > suppose to be updated to using a new widgetset) Don't worry. fpmake is only the Free Pascal Makefile generator. >[...] > "Compile your new widgetset in the IDE" > > Does this mean > - go into "Tools -> Configure Build Lazarus" > - select "Build LCL" > - select the your new widget set as "Target" > - hit Build Target is only needed when cross compiling to other operating systems and/or processor types. I forgot: To use the new widgetset in the project you need to change the project / compiler options / widgetset. This is already mentioned several times in the wiki, but some things should be told again and again. Can you write the above in the wiki, so that a non lazarus devel understands it? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > There are some information about the widgetsets in lazconf.pp, > > definetemplates.pas and the Makefiles. > > > Sorry, I don't find any information on how to make the compiler aware of > the newly created directory with the "directory"-name given in > lazconf.pp where interfaces.pp is to be found. Can you send me the patch so far? Then I can take look. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus: A new widgest set
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > I know this is not the Lazarus developers list but I also know that the > experts are here, so I ask here and maybe I just need a hint to get going. > > For a special purpose (maybe to released publicly later) I want to > create a new widget set in Lazarus. > > I could easily add the new Name and directory to the lazconf.pp file and > recompile Lazarus. > > Now I can select the new widget set in compiler options. > > I created an appropriate directory under "interfaces" and for a first > test just moved interfaces.pp file in there. > > I hoped that this directory would be used and I would get a compiler > message from compiling the dummy interface.pp file. > > But I just get "can't find unit interfaces". So seemingly the directory > is not scanned. > > Does anybody know the additional implications to meet when adding a new > widget set ? There are some information about the widgetsets in lazconf.pp, definetemplates.pas and the Makefiles. Maybe you can give me some information about the new widgetset. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] more descriptive parameter names for C translated headers
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > Hi, > > I use the xlib.pp unit a lot. As far as I understand it and many > others like it was created with a automated tool. As I use the > functions, I thought I could start changing the para1, para2... to > more descriptive parameter names. This makes it much easier to code > if you use something like Lazarus that gives function declaration > hints etc.. > > It will not affect/break anybody's code if I start making those > changes, but I would like to get the correct naming convention > going... I'm only doing this once! :) > > Here's the original declaration: > > function XSetSelectionOwner(para1:PDisplay; para2:TAtom; > para3:TWindow; para4:TTime):cint;cdecl;external libX11; > > > what should the new parameters look like > > Delphi / standard Object Pascal style: > > 1) > function XSetSelectionOwner(ADisplay:PDisplay; ASelection:TAtom; > AOwner:TWindow; ATime:TTime):cint;cdecl;external libX11; > > or maybe > > 2) > function XSetSelectionOwner(display:PDisplay; selection:TAtom; > owner:TWindow; time:TTime):cint;cdecl;external libX11; > > > > My preference is 1). What's your thoughts? Parameter names are needed by many headers. Why not write a tool, that does it semi-automatically? Give it the c file with nice parameter names and the pascal unit and it replaces para* with the c names. This tool could be useful here: http://wiki.lazarus.freepascal.org/Creating_bindings_for_C_libraries#Future_work_.2F_Missing_stuff Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FP 2.4 questions
Zitat von Michael Van Canneyt <[EMAIL PROTECTED]>: > > > On Wed, 2 Jan 2008, Mattias Gärtner wrote: > > > Zitat von Marc Weustink <[EMAIL PROTECTED]>: > > > > > Mattias Gaertner wrote: > > > > On Wed, 2 Jan 2008 11:08:27 +0100 (CET) > > > > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > > > > > Then I don't get why people refuse that lazarus is recompiled and > > > see dyn. loaded packages as _the_ solution to this "problem" :) > > > > > > >>> Is there another solution that makes it possible to compile and > > > >>> test a (future) visual component before installing it and with a > > > >>> simple click-click action add it to the component library (even if > > > >>> this involves waiting some minutes). > > > >> No. Not even Delphi has that. The property editors and component > > > >> registrations must be known to the visual environment. > > > > > > > > It depends on how much IDE stuff the package needs. > > > > > > > > Property Editors can be tested without the IDE by using the RTTI > > > > controls. > > > > > > > > New codetools features can be tested without the IDE. > > > > > > > > Some IDE parts can be tested with the SimpleIDEIntf package > > > > components/simpleideintf/simpleideintf.lpk. This package simulates a > > > > simple IDE to allow testing IDE experts at command line. It fills > > > > several objects and functions of the IDEIntf. > > > > > > > > Experts and Component Editors need the whole IDE. > > > > > > Properties (and I think component editors too) can also be tested with > > > the ObjectInspector example. > > > > Right. > > Component editors are the menu items for the designer. These can not be > tested > > without the designer. But if the menu item only starts a dialog to edit a > > control, then you can test that dialog in a simple project. > > Hmm, maybe an article can be written about that. > > Is this a hint for me ? :-) Naah, just thinking loud. ;) Will you write it? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FP 2.4 questions
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > I developed several visual components for Lazarus and usually you > > install once and as you develop is not necessary to recompile the IDE, > > but are some exceptions: > > > > 1) The installed version crashes the IDE designer > > 2) You added a published event/property and wants to make a demo app > > that uses it through designer > Thanks, I'll take care. > > BTW. I always searched for a way to extend an existing visual component > by some new properties or functionalities and move same into the palette > and after this easily replace the old one by the new one in (multiple > instances) an existing application. > > Dis not find a n easy way in Delphi nor in Lazarus. Create a descendant: Package Editor / Add / New component / ... Test it and install it. Change class of one control: Designer / popup menu / Change Class There is no dialog/option yet to apply Change Class to all controls of a class on a form or on all forms of a project/package yet. Although if the class was only extended, then probably this will work: Close all designers and use Search / Find in Files / Replace on .pas/.lfm files. The .lrs files will be automatically updated by the IDE on compile. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FP 2.4 questions
Zitat von Marc Weustink <[EMAIL PROTECTED]>: > Mattias Gaertner wrote: > > On Wed, 2 Jan 2008 11:08:27 +0100 (CET) > > [EMAIL PROTECTED] (Marco van de Voort) wrote: > > > Then I don't get why people refuse that lazarus is recompiled and > see dyn. loaded packages as _the_ solution to this "problem" :) > > >>> Is there another solution that makes it possible to compile and > >>> test a (future) visual component before installing it and with a > >>> simple click-click action add it to the component library (even if > >>> this involves waiting some minutes). > >> No. Not even Delphi has that. The property editors and component > >> registrations must be known to the visual environment. > > > > It depends on how much IDE stuff the package needs. > > > > Property Editors can be tested without the IDE by using the RTTI > > controls. > > > > New codetools features can be tested without the IDE. > > > > Some IDE parts can be tested with the SimpleIDEIntf package > > components/simpleideintf/simpleideintf.lpk. This package simulates a > > simple IDE to allow testing IDE experts at command line. It fills > > several objects and functions of the IDEIntf. > > > > Experts and Component Editors need the whole IDE. > > Properties (and I think component editors too) can also be tested with > the ObjectInspector example. Right. Component editors are the menu items for the designer. These can not be tested without the designer. But if the menu item only starts a dialog to edit a control, then you can test that dialog in a simple project. Hmm, maybe an article can be written about that. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel Computing
Zitat von Michael Schnell <[EMAIL PROTECTED]>: > > > Think about the alternative: It is much harder to implement the same > > parallel loop with TThread. So OpenMP makes parallel loops much easier > > to implement. For me this is the 'Delphi' way: Makes things easy and > > readable. > > > Of course you are right. In the example of "parallel" loops It's _a_lot_ > easier to to use for the programmer. "Lightweight-threaded" stuff like > parallel loops was not the original aim of ThreadEvents. The original > target was a more "standard" use of threads. But it _can_ be used for > parallel loops, too, and it follows the "Delphi-language-paradigms" a > lot tighter than using TThread. > > I don't suppose that anybody will start implementing real parallel loops > like suggested on the wiki page any time soon. The examples are very artificial to demonstrate the problems. Some real world examples / tutorials should be added on a new page. Parallel algorithms are seldom taught in books/schools/university, so programmers are not used to them. This is slowly improving. > But TEventThread and "Thread Events" is quite easy to do. > > > The 'of thread' is a language change, not just an RTL enhancement. > > > Sorry if I have been vague here. Of course it is (as is the alternative > to enhancing the meaning of "of object"). But this is only another > enhancement that can be done as a second step. Most of the functionality > can be used (or at least tested) by just implementing TEventThread (and > TMainEventThread) in the RTL (and maybe LCL). > > That's why you must add links pointing to the page. > > > Of course. But where to add them ? Everywhere. :) For example search for 'thread' and add at the bottom or in between a short sentence with a link, like 'Another approach is ...' or 'Threads can communicate via TEventThreads too, see ...'. > > About search optimization: The page is called OpenMP and this is what > > users see. They don't see Eventhreads. > > > Of course you are right again: It's a good idea to do a separate page. > I'll do that ASAP, Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus IDE searching units overwiev inquire (issue#10176 successor)
Zitat von Andrey Gusev <[EMAIL PROTECTED]>: > Some units cannot be found by IDE (in editor), as earlier. > --- (from message box) > C:\Works-FContr\Contracts\gen\gen2\WaybillG.pas(13,50) Error: unit not > found: darrInt > --- > but, corresponding directory is correctly prescibed to both compiler and > IDE paths > (first and third boxes in compiler options window, paths tab). The IDE uses the first plus the third box. So, no need to add it to both. See http://wiki.lazarus.freepascal.org/index.php/IDE_Window:_Compiler_Options What shows Source Editor / Popup menu / Unit Info as "unit paths" and "source paths" for the WaybillG.pas? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
