Re: [fpc-pascal] Re: Is this if /else syntax wrong?
Zitat von Frank Church : I will be upgrading to 2.4.0 soon. It shouldn't be an error then. 2010/7/1 Guillermo Martínez Jiménez > procedure TfrmHometel.SetSplitterSizes; > var > i: integer; > begin > for i:=3D 0 to ComponentCount - 1 do > begin > if Components[i] is TSplitter then > begin > with TSplitter(Components[i]) do > begin > if Cursor =3D crHSplit then >Width :=3D 7 > else if Cursor =3D crVSplit then >Height :=3D 7; > ; // <-- removing this semicolon results in a syntax error. Is it > syntax error some kind of extra strict compiler check. > Color :=3D clBlue; > end; > end; > end; > end; Compare with next: if Cursor =3D crHSplit then Width :=3D 7 else if Cursor =3D crVSplit then Height :=3D 7; // <-- This semicolon is for the "if". ; // <-- This semicolon is for the "else". No. A semicolon ends *all* open if/if-else/do statements. The second semicolon is an empty statement - a 'no operation'. Is like this: IF ... THEN BEGIN ... END ELSE BEGIN IF ... THEN BEGIN ... END; // <-- This END is for the "IF". END; // <-- This END is for the "ELSE". I recommend to use "BEGIN ... END" blocks in nested "IF" always to prevent this kind of mistakes. In general I agree, but in this case there are no nested ifs, so it won't help here. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode characters in source code
Zitat von Tomas Hajny : On Wed, April 21, 2010 10:47, ik wrote: Hi, If I want to use Unicode characters in my source code, but without actually typing in the Unicode character - I rather want to define it similar to ASCII chars or Hex values: eg: Char(65)or 'test'+#65+'me' or similar to what hex values are defined with a dollar prefix: $30 Any idea how I can do this? I don't want to mess with the -Fcutf8 compiler parameter if I can avoid it. I also want the ability of the source code Caption:=#$C3#$A4; // a umlaut . What do you mean by "messing with the -Fcutf8 parameter"? If you include some character constants outside the us-ascii set, you should always tell the compiler how to evaluate them, because the evaluation depends on the used encoding; especially if you intend to use those for Unicode specific types (characters or strings). The only alternative not requiring the compiler to evaluate the constants using certain encoding would be something like using the internally expected format and putting the values there directly as sequence of bytes using e.g. an absolute construct mapped to the same memory area, but that is probably neither efficient nor very wise considering necessity to rely on compiler internals... Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus Snapshots Intel Mac with FPC 2.4.1?
Zitat von Jonas Maebe : On 19 Apr 2010, at 15:23, Tobias Giesen wrote: Which bugs? I'm sorry but it was a few months ago. Before trying again I wanted to make sure I had the best version of FPC available. I had problems with units not being found although they were on the search path allright. This usually means that they were compiled by a previous compiler, or that they use units which have been changed and recompiled since the previous compilation. In that case, the compiler will ignore the precompiled unit and try to recompile it. If it then doesn't find the sources, you'll get an error about the unit not being found. Another common reason: You added too many search paths. Lazarus compiles each package separately. Each run needs distinct search paths. Otherwise you create duplicate ppu files. Also installing packages into Lazarus caused all kinds of unit conflicts (Recompiling XYZ.pas because the checksum changed although it didn't). These things won't change if you update FPC. If anything, you'll probably get more such problems because mixing units compiled by different compiler versions can also cause such issues. See also: http://wiki.lazarus.freepascal.org/Unit_not_found_-_How_to_find_units#Quick_list Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Creating text files with TFileStream
Zitat von Graeme Geldenhuys : 2009/10/23 Graeme Geldenhuys : Did you try writing with WriteBuffer(Atext[1], length(AText)? That works exactly like I intended. Thanks Gerard. I spoke to soon! :-( I can view the resulting output.txt file with Midnight Commander (Linux console file manager), but if I try and open that file with Gnome gEdit or Lazarus IDE, it says the file does not look like a text file and refuses to open it. :-( It means your AText string contains special characters (#0..#8,#11,#14..#31) How difficult could it be to write a damn text file! :-) It's damn simple. Use TFileStream if you want write one string. Use a TStringList if you want to write several strings. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Zitat von Florian Klaempfl : Jürgen Hestermann schrieb: Yes, but you cannot avoid it, if you work with dynamic arrays. You are not even told that it's a pointer. That's just the problem. Same for classes and strings. Classes are pointers and I'm happy that I can write A.B instead of A^.B. About pointer arithmetic: IMO memory is an array. So for me it is quite natural that P^ and P[0] are the same. I think this is a great feature of FPC, which I don't want to miss. It's simple, unambiguous and readable - like pascal. The only disturbing is the automatic dereferencing of pointer to record/object in Delphi mode, where you can use PtrRect^.Left and PtrRect.Left. But that only works in delphi mode, which I avoid. The problem is that one is playing with stuff he doesn't understand. Explict use of pointers is always dangerous and one should really know what he does especially on object pascal dyn. arrays which are much more than a simply pointer to the data else one wrecks anyways havoc. Great power comes with great responsibility. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Who said Pascal isn't popular
Zitat von Rainer Stratmann : Am Montag, 12. Oktober 2009 11:02 schrieb Jürgen Hestermann: > Remember, Pascal is merely a TEACHING language, unsuitable for commercial > software development, which is why we have C. :) And why should that be the case? What are the outstanding feature of C that make it so supperiour? It's illogical and hard to maintain syntax? Or is it just that it was available for free on all unix systems? Yes, it is available everywhere. And it is easier to copy unix code then. Remember that it is still not easy to come to freepascal. You have to configure a debian testing system and apt-get lazarus and so on... Nearly nowhere the lazarus package is preinstalled. Standard user distributions do not install any development software. This is how linux distros work and is the same for every devel software, not only lazarus. Some distros allow to create your own custom install CD/DVD. This is used for network installs or for pools. Maybe it is possible write a linux "installer", which analyzes your system and downloads and installs all needed packages. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to free this memory and avoid memory leak
Zitat von Graeme Geldenhuys : [...] * ntoc = number of entries in the array. Each entry is a LongWord (or Int32 in the code below) * tocarray is my local array that gets populated with information from the file, using the Move() procedure. * tocoffsetsstart is the starting offset of the TOC array in the file. * I then simply look through the number of entries in the array - position p to file offset as specified by each entry of the array - extract my data, and continue with the next item in the array At the end I try to free / dispose of the memory used by my local array: tocarray ...but whatever I try, heaptrc keeps telling me I have a memory leak in this code. -- procedure THelpFile.ReadContents; var Topic: TTopic; EntryIndex: longint; pEntry: pTTOCEntryStart; tocarray: array of Int32; p: PByte; begin _Topics.Capacity := _Header.ntoc; SetLength(tocarray, _Header.ntoc); p := _Data + _Header.tocoffsetsstart; Move(p, tocarray, SizeOf(tocarray)); if _Header.ntoc>0 then Move(p^,tocarray[0],SizeOf(Int32)*_Header.ntoc); for EntryIndex := 0 to _Header.ntoc-1 do begin pEntry := _Data + tocarray[EntryIndex]; Why not simply: pEntry := _Data + PInt32(p)[EntryIndex]; Topic := TTopic.Create(_Data, _Header, _Dictionary, pEntry ); Topic.HelpFile := Self; Topic.Index := EntryIndex; _Topics.Add(Topic); end; // Finalize(tocarray);<--- doesn't work not needed: Finalize(tocarray, _header.ntoc); <--- doesn't work tocarray := nil; <--- doesn't work end; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why is cthreads unit not included by default
Zitat von Henry Vermaak : 2009/8/27 Graeme Geldenhuys : Michael Van Canneyt wrote: Why is threading enabled by default under Windows and not under other platforms? Because it creates a dependency on the C library, which is not always wanted. For Lazarus programs, the dependency exists anyway, so it does not make a lot of sense to have the define. But surely that c library is available on all unix-type systems? To why is that dependency a bad thing? The linux threading support is part of glibc. See `man pthreads`. That's why Mattias says that including it by default in lazarus is o.k., since all the widgetsets depend on libc, anyway. Not me, but Michael said that. I would say, that using cthreads under Linux in an LCL app is ok. I didn't test yet a LCL app under OS X, *BSD or Sparc, so don't know if cthreads has a performance penalty there. Threading on Windows works with Windows API functions. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Switch Endian
Zitat von luca_mangane...@comune.trento.it: Hi, there's a pascal function to switch endian (for a 32 bit integer)? Note that it should work on 64 bit systems... There are many in the system unit: SwapEndian leton beton Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
Zitat von Zaher Dirkey : Hi, - "Use setup to define the link", i am compile Lazarus from the source not install the by setup. Is it bad idea to make Lazarus read ini/config file in same Lazarus dir, if the file exists then read the path to config directory from it, if not leave Lazarus as is. I'm not sure what you mean. Can you explain this in other words/with examples? Eclipse IDE ask to workspace in first run. Lazarus does not have the concept of 'workspace' as eclipse. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
Zitat von Florian Klaempfl : Mattias Gärtner schrieb: Zitat von Florian Klaempfl : [...] A network file system is too slow for developing. Compiling anything via nfs or smb is a nightmare speedwise. NFS over gigabit is not that bad. For example compiling 94k lines of codetools on a network share and on local disc makes no difference. Compiling whole lazarus on a network share can be even faster than compiling locally, because saving a big chunk like the IDE executable is faster than the local disk. Lazarus itself had some performance problems with network shares in the past, because of its many file stat calls. I implemented a caching some years ago, which accelerated it by orders of magnitudes. My conclusion: I agree with Jonas, you can use network shares for development machines. Roaming profiles using auto copy/delete are not the best choice for that. incremental syncs, dfs, ...). Indeed, sources etc. are just stored on the local harddisk being checked out from the vcs. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus settings and roaming profiles in Windows
Zitat von Florian Klaempfl : Mattias Gaertner schrieb: On Thu, 16 Jul 2009 10:30:23 +0200 Jürgen Hestermann wrote: Jürgen Hestermann, how often do you change your working machine? Well, I seldom change it [...] If I log off, the local profile is saved (partely) to the (Novell) home dir and then the local Windows user is deleted completely (including the profile!) IMO: This type of sharing does not sound very suitable for a development machine. I think roaming profiles are something very common in a commercial environment? It is a very good solution for the typcial professional use case where you use most of the time the same machine but sometimes you switch the machine. During your daily work you don't have the bottleneck of network/server access and when logging out, all data is stored again on the server so backups can be easily made. It combines the advantages of a networked home/profile directory and a fat client. Sorry for the confusion. Of course this type of sharing makes perfect sense for office computers, stores and thin clients. The user settings are *normally* only a few MB and are machine independent, so they can be easily shared in whatever way you prefer (copy/delete, network file system, etc...). But development easily creates hundreds or thousands of MB. Sharing this with with auto copy/delete on log on/off is not the best idea. That's why I think there are better network sharing systems for development machines (network file systems, incremental syncs, dfs, ...). just my 2 cents. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetPropValue and Unknown property
Zitat von "Leonardo M. Ramé" : How are you filling the ASortProps array? if it is by hand, you have to take care of Case Sensitivity of property names. You can use this function to know the published properties of any class. Try it inside your DoCompareProps, passing TFTPListRec(AItem1).ClassType as param, if AItem1 is an instance it should list all its properties: procedure GetClassProperties(AClass: TClass); (* get published properties into a list *) var PropList: ppropList; ClassTypeInfo: PTypeInfo; I: Integer; lProps:Integer; begin (* Get properties and a pointer to class *) lProps := GetTypeData(AClass.ClassInfo)^.PropCount; if lProps <> 0 then begin (* Properties list to be analyzed *) for I := 0 to GetPropList(AClass.ClassInfo, PropList) -1 do writeln(PropList[I]^.name); end; end; This will create a mem leak. Call GetPropList only once and FreeMem the PropList at the end. Mattias -- Powered by NetMail ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake: output directories
Zitat von Michael Van Canneyt : On Tue, 2 Jun 2009, Michael Van Canneyt wrote: On Tue, 2 Jun 2009, Vincent Snijders wrote: Michael Van Canneyt schreef: On Mon, 1 Jun 2009, Mattias Gaertner wrote: Hi fpmake devels, fpmake uses as ppu output directory for example: units/i386-linux/ And there is no way to change this. Right? Some LCL packages have different PPUs per widgetset, so they need an output directory per widgetset. At the moment they use for example: units/i386-linux-gtk2/ Another example is to distinguish between release and debug version. What is the best/recommended way to solve this with fpmake? You can't in this way. So, no debug and release version on one computer? Not in this way, at least. Hi, Peter Vreman reminded me that we had this discussion on core about a year ago. The solution we came up with was a 'subtarget' or 'configuration'. This was simply an option to fpmake, which would alter the output path and search paths. It was needed to discern between debug and non-debug, PIC and non-PIC code etc. So there would be fpmake --subtarget=debug Which would send output in units/i386-linux-debug So maybe this can be used for the widgetsets, debug-non debug etc. Beware: AFAIK it has not yet been implemented, but that was the initial idea. Thanks. Maybe this can be used for debug/release. I don't see how this can be used for the widgetsets. My dream is this: User opens a project and/or package and the IDE uses fppkg to download and install automatically the missing packages. Some packages like the LCL are already installed via lazarus. So somehow fppkg needs to know, that some packages don't need be downloaded from the repositories. Maybe lazarus can register a local repository? Mattias -- Powered by NetMail ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake dependencies
Zitat von Michael Van Canneyt : >[...] > > The single parameter Options is a show stopper for the LCL, because I use > often > > flags like -gh plus a few -d flags for the experimental features. > > I understand. > Maybe we should change it to tstrings, and say that there should be one > option per line ? That avoids the hassle of having to parse the Options string for > quoted params. Sounds good. > > >[...] > > > > That's where I looked. Should I copy the SearchFile procedure? > > > > > > Can't you use it instead of copy it ? > > > > It has no interface. > > No comprendo ? SearchFile in fpmkunit is only defined in the implementation. I can of course use it via linker tricks, but I don't like that. > > And btw, I don't understand why it uses: > > if FindFirst(SearchDir+'*',faAnyFile and faDirectory,Info)=0 then > > > > faAnyFile and faDirectory = faDirectory. > > Indeed, > 1) it should be or instead of and > 2) anyfilemask should be used instead of '*' :-) Don't know. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake dependencies
Zitat von Michael Van Canneyt : >[...] > > Hint: File "units/i386-darwin/allcodetoolunits.o" was already deleted > > It should maybe be reduced to a debug message, just to see what the > clean command is actually trying to do. I created a bug report. > > > > > > Is there a tool to create them automatically? > > > > > > > > > > Not yet. This is planned. > > > > > > > > Come on. You didn't add the 14 thousand filenames manually, did you? > > > > > > The unit source names were added from the Makefile.fpc (there is a > > > conversion > > > mode) but the rest was added manually. > > > > You call yourself a programmer? Shame on you. ;) > > Ah, but for the RTL, adding them manually was less job than > writing a tool. Basically, I'm lazy :) It's hard to believe that this was easier, but I try. :) > > > I realize that for the LCL, this will be a rather largish job :-) > > > > I will rather write a tool than add them manually. > > I was hoping someone would volunteer :-) > > For the LCL, writing the tool is probably less work (given the codetools) > than adding them manually, so basically, you're just lazy too. This way > I don't need to feel too ashamed about myself :) Before I can write such a tool I have to understand fpmake, its features, its goals and its bugs. The single parameter Options is a show stopper for the LCL, because I use often flags like -gh plus a few -d flags for the experimental features. >[...] > > That's where I looked. Should I copy the SearchFile procedure? > > Can't you use it instead of copy it ? It has no interface. And btw, I don't understand why it uses: if FindFirst(SearchDir+'*',faAnyFile and faDirectory,Info)=0 then faAnyFile and faDirectory = faDirectory. This works under Unix, because FindFirst ignores the attribute. But I wonder, why it works under windows. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake dependencies
Zitat von Michael Van Canneyt : >[...] > > On Tue, 14 Apr 2009, Mattias Gärtner wrote: > > > Zitat von Michael Van Canneyt : > > > > > > On Tue, 14 Apr 2009, Mattias Gärtner wrote: > > > > > > > > I saw that the fpmake programs of the fpc sources contain the > unit/include > > > file > > > > dependencies. > > > > Why? > > > > (fpc finds the unit/include file dependencies automatically.) > > > > > > For the zip archive creation. All files are needed. > > > > Apparently for the 'clean' too. > > > > Why does it warn, when the files to be cleaned are already cleaned? > > > > Warning: File "units/i386-darwin/allcodetoolunits.o" does not exist > > Warning: File "units/i386-darwin/allcodetoolunits.ppu" does not exist > > Under normal operation, this should not happen ? IMO this is a normal operation: svn up && fppkg clean build Questions: Why a warning instead of a hint? Why not explain why it was searched? Newbies will get confused by such warnings. If you think that the message is needed, then maybe use this: Hint: File "units/i386-darwin/allcodetoolunits.o" was already deleted > > > > Is there a tool to create them automatically? > > > > > > Not yet. This is planned. > > > > Come on. You didn't add the 14 thousand filenames manually, did you? > > The unit source names were added from the Makefile.fpc (there is a conversion > mode) but the rest was added manually. You call yourself a programmer? Shame on you. ;) > I realize that for the LCL, this will be a rather largish job :-) I will rather write a tool than add them manually. > > > > Can I use file masks? > > > > > > I think yes ? > > > > I only found a mask for Sources. Somewhere else where I can look? > > packages/fpmkunit/src/fpmkunit.pp :-) That's where I looked. Should I copy the SearchFile procedure? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake dependencies
Zitat von Michael Van Canneyt : > > > On Tue, 14 Apr 2009, Mattias Gärtner wrote: > > > > > I saw that the fpmake programs of the fpc sources contain the unit/include > file > > dependencies. > > Why? > > (fpc finds the unit/include file dependencies automatically.) > > For the zip archive creation. All files are needed. Apparently for the 'clean' too. Why does it warn, when the files to be cleaned are already cleaned? Warning: File "units/i386-darwin/allcodetoolunits.o" does not exist Warning: File "units/i386-darwin/allcodetoolunits.ppu" does not exist > > Is there a tool to create them automatically? > > Not yet. This is planned. Come on. You didn't add the 14 thousand filenames manually, did you? > > Can I use file masks? > > I think yes ? I only found a mask for Sources. Somewhere else where I can look? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake custom options
Zitat von Vincent Snijders : > Mattias Gärtner schreef: > > Is the tracker online? I can't reach it. > > I can reach it without problems. I can reach it only every third reload. I created the bug report. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake custom options
Zitat von Michael Van Canneyt : >[...] > > > > I tried a simple example: > > > > T.Options:='-gl -vh'; >[...] > Please do, that way it won't be forgotten. Is the tracker online? I can't reach it. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake custom options
Zitat von Michael Van Canneyt : > > > On Tue, 14 Apr 2009, Mattias Gärtner wrote: > > > How to add custom options? > > > > The wiki of fpmake gives: > > T.Options:= '-dSOMEDEFINE'; > > T.Options:= T.Options + ' -xyzAnythingYouNeed'; > > > > I tried a simple example: > > T.Options:='-gl -vh'; > > > > And I got: > > Executing command "/usr/local/bin/fpc -Tdarwin -FUunits/i386-darwin > > -Fu/usr/local/lib/fpc/2.2.4/units/i386-darwin/rtl "-gl -vh" > > allcodetoolunits.pp" > > Error: Illegal parameter: -gl -vh > > > > Apparently the Options are passed in "" which is read by FPC as one > parameter. > > Hm. That is a bug, we'll have to change that. Should I create a bug report? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake unit output directory
Zitat von Michael Van Canneyt : > > > On Tue, 14 Apr 2009, Mattias Gärtner wrote: > > > How can I change the unit output directory in fpmake? > > You are not supposed to do so. > > You can only set the install dir. Ok. I thought so looking at the code. I will add that to the wiki. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpmake custom options
How to add custom options? The wiki of fpmake gives: T.Options:= '-dSOMEDEFINE'; T.Options:= T.Options + ' -xyzAnythingYouNeed'; I tried a simple example: T.Options:='-gl -vh'; And I got: Executing command "/usr/local/bin/fpc -Tdarwin -FUunits/i386-darwin -Fu/usr/local/lib/fpc/2.2.4/units/i386-darwin/rtl "-gl -vh" allcodetoolunits.pp" Error: Illegal parameter: -gl -vh Apparently the Options are passed in "" which is read by FPC as one parameter. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpmake dependencies
I saw that the fpmake programs of the fpc sources contain the unit/include file dependencies. Why? (fpc finds the unit/include file dependencies automatically.) Is there a tool to create them automatically? Can I use file masks? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpmake unit output directory
How can I change the unit output directory in fpmake? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating code form xmi files
Zitat von Michael Van Canneyt : > > > On Fri, 3 Apr 2009, Graeme Geldenhuys wrote: > > > On Thu, Apr 2, 2009 at 10:05 PM, Philippe Martinole > > wrote: > > > > > > xmi files (not xml) are used to save uml models : > > > http://en.wikipedia.org/wiki/XML_Metadata_Interchange > > > and I want to gererate my data structures from my uml diagrams > > > I would be suprised if nothing already exists > > > > I've been looking for something like this for a long time and haven't > > fond anything for Free Pascal / Lazarus. You can obviously use Model > > Maker and simply tweak the generated object pascal code to make sure > > they are compilable with FPC. But I believe Model Maker is quite > > pricey. > > Well, Umbrello (Open source, comes with KDE) can generate code from XMI > for various languages (C,C++,PHP, Java) except pascal. All you need to > do is write an output engine for pascal. > > It is on my todo list, item no. 132.458 :-) I just tested Umbrello and I got the impression it is very C++-centric - the dialogs, the options, the code. For example I don't see how to setup free pascal properties - it seems to have only basic variables as attributes. Is this a shortcoming of UML in general? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Lazarus Resource...
Zitat von "papelhigien...@gmail.com" : > Hi all! > > An stupid question... A resource file (lrs) can have 2 resources with the > same name? The last counts. Which means: no. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Profiling
Zitat von Jonas Maebe : > > On 26 Jan 2009, at 22:49, Mattias Gaertner wrote: > > > I need to profile lazarus applications under linux. > > I tried gprof, but it is broken since years and shows no record. > > Neither does the bug repository show any record of open bugs against - > pg on Linux. Sorry. I thought the problem is known and the fpc team prefers valgrind. I saw that Michael created a bug report, with major urgent priority - wow. > > I found the following page, but it does not help here: > > http://wiki.lazarus.freepascal.org/Profiling > > > > How can I profile under linux? > > I've used qprof successfully in the past (not for FPC programs, but > for other things). It's a sampling-based profiler, so it shouldn't > slow down things too much. Yes, that's why I prefer gprof and used it a lot in the past. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unexpected duplicate identifiers
Zitat von Mark Morgan Lloyd :
> dhkblas...@zeelandnet.nl wrote:
>
> >> FPC 2.2.0 is giving me duplicate identifier errors for "sort" and
> >> "strings" above.
>
> > Add {$mode delphi} to the top of your unit. ObjFPC mode is more strict.
>
> Thanks, I think that fixes it although I'm still working through the
> affected unit.
fix <> workaround ;)
> I presume I'm correct in assuming {$mode delphi} operates strictly on
> the syntax of the current unit without affecting cross-unit operations.
>
> Are there cases where it can't be used? Specifically, can it be put in a
> Lazarus .lpr file where this is a transcript of a Delphi .dpr?
Yes.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetAppConfigDir but for temp data?
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On Wed, Dec 3, 2008 at 6:56 PM, Mattias Gärtner > <[EMAIL PROTECTED]> wrote: > >> > >> :-) Like I said, Linux has a long way to go for desktop friendly apps. > > > > desktop friendly <> mono culture > > I don't understand? What I meant by "dekstop friendly apps" is > Take a simple example. Under Windows you are guaranteed that if you > want to show a user a readme.txt file, you can call notepad.exe and > the filename (yes I know you can do it in other ways too, but I did > say this example is simple.). notepad.exe has problems with non windows line ends. > Under linux, how do you know the users > favorite text editor? To show a readme.txt you don't need to open the favorite text editor. A browser could do the same. > You can't assume 'gEdit', because they might run > KDE. Oh, you can't even assume 'kate' because they could be running > FVWM. When writing desktop applications there are lots of such cases > under Linux. That's why I welcome any standardization under Linux, > which desktop app developers can use. eg: xdg-open but clearly xdg > is not on all distros. :-( Some don't even have X. > I'm clearly not the only one thinking like this. That's also why Gnome > and KDE themes are more interchangable. You can run KDE apps under > Gnome, and they blend in quite nicely. Years ago, they didn't. We had this discussions already. So, yes and no. ;) Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetAppConfigDir but for temp data?
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On Wed, Dec 3, 2008 at 6:36 PM, Michael Van Canneyt > <[EMAIL PROTECTED]> wrote: > > >> I don't know which applications actually adhere to these locations > >> though, but I'm willing to start. :-) > > > > On a KDE system: none. > > :-) Like I said, Linux has a long way to go for desktop friendly apps. desktop friendly <> mono culture > [...] Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpImage resample via interpolation
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > On Fri, Nov 28, 2008 at 3:14 PM, Michael Van Canneyt > <[EMAIL PROTECTED]> wrote: > > > > On Thu, 27 Nov 2008, Mattias Gaertner wrote: > > > >> As far as I can see, fpImage has for StretchDraw only the > >> TMitchelInterpolation. > > > > This is not correct. This is the standard interpolation used. > > But you can use other interpolations. The extinterpolation.pp > > unit contains other interpolations (6 or 7) that can be used > > with the StretchDraw implementation. Thanks. Impressive list. But they have all the same problems. They create an unnecessary temporary image and have a fixed max support. Maybe I misunderstand the computation. I would expect a mapping of a linear distribution 0..1 to a mitchel, gauss, bilinear, ... distribution 0..1. Something like diff:=Filter(diff*MaxSupport); I will extend my function, so that you can use any of the other interpolations. > > But additional interpolations are always welcome. Ok. I will extend it and you can add it to this unit. > fpGUI doesn't use fpImage yet, but I did borrow the StretchDraw() code > from there. And yes, you can specify a whole bunch of other > interpolations to use. If memory serves me well, fpGUI has a few more > interpolations than fpImage. When I start implementing fpImage support > in fpGUI, I will contribute those to FCL. I'm curious: who needs more than 13 different image interpolations? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpimage glow effect
How can I create a glow effect around text with fpimage? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to auto create the $fpctarget directory
Zitat von Henry Vermaak <[EMAIL PROTECTED]>: > On 01/10/2008, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote: > > Hi, > > > > How can I auto create the $fpctarget directory? Just specifying > > ../lib/$fpctarget/ and then compiling the project doesn't create the > > needed directory, and I get the following build error. I gather the > > compiler itself doesn't create directories at all. Could this become > > an option? Which output directory do you mean? The unit output directory of the project is auto created by the IDE since 16284. Do you mean the output directory of the binary? > > Alternatively, is there some why I can query the $fpctarget > > and then in the build scripts for Linux, Windows and *BSD create the > > correct output paths, because I actually start the compile? > > echo `fpc -iTP`-`fpc -iTO` gives the same string for $fpctarget, i > think. i also think the compiler should auto create the output > directories. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DateTimeToFileDate
Zitat von Carsten Bager <[EMAIL PROTECTED]>: > When I do this > > Free Pascal Compiler version 2.2.2 [2008/07/29] for i386 Which OS? > - > Program tt; > uses dos, > sysutils; > > function strPackTime(t:longWord):shortstring; > var > dt:Datetime; > begin > UnpackTime(t,dt); > strPackTime:=intToStr(dt.day)+'/'+ > intToStr(dt.month)+'-'+ > intToStr(dt.year)+ > intToStr(dt.hour)+':'+ > intToStr(dt.min)+':'+ > intToStr(dt.sec)+' '; > end; > > Begin > WriteLn(strPackTime(DateTimeToFileDate(now))); > > WriteLn(DateTimeToStr(FileDateToDateTime(DateTimeToFileDate(now > ; > End. > - > > I get this result > > 9/6-20160:28:22 > 11-9-08 13:39:55 > > What am I doing wrong. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Install FPC/Lazarus for Win CE
Zitat von Felipe Monteiro de Carvalho <[EMAIL PROTECTED]>: > Downloading the sources and building Lazarus is trivial. It requires > pasting 3 commands into the console: > > svn co http://svn.freepascal.org/svn/lazarus/trunk lazarus > cd lazarus > make bigide LCL_PLATFORM=carbon OPT="-k-framework -kCarbon > -k-framework -kOpenGl" AFAIK you don't need the framework options anymore and carbon is the default under OS X: make clean all bigide > Then you can navigate to the place where you put the sources and start > from the bundle, or drag it to your dock. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Installing on Mac OS X
Zitat von Paul <[EMAIL PROTECTED]>: > Ok, > > placing it all in the /Developer/ folder seems more logical to me. > FPC should do the same imho (for Mac OS X). I don't know. I have to read Mac guide lines and see how similar projects solved it. > Are you writing this installer or is this a joint effort ? It's a joint effort with the other lazarus developers. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Installing on Mac OS X
Zitat von Paul <[EMAIL PROTECTED]>: > Ok Jonas, > > that solved at least a few items. > Lazarus is complaining about fpcsrc files, which I didn't install. > I installed FPC2.2.2 and Lazarus only. > So I guess I have to go and install the source now. FYI: I want to improve a few things in the lazarus installer to make paths and defaults more convenient. I hope to find some time this week. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do I add a TComponent to TPanel dynamically?
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > In our previous episode, Danie said: > > I hope this the right forum for this question (gtk on > > lazarus-0.9.24-1.fc8 rpm on fpc-2.2.0-10.fc8 rpm)(but I know there are > > people here that can help me %^). > > I would like to add a special TShape (descendant or TComponent) to a > > panel. > > I tried the following but must be missing something. > > I only looked quickly, but it seems you create the tshape with the > parent of the controlvolume class as owner (..create(sender)), but you > destroy it manually. Don't. Why not? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: > Mattias Gärtner wrote: > > Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: > > > >> [...] > > a: record end; > >>> Thanks. I will use that. > >> What for? The C statement is empty, it's not a variable and not even a > >> type. So before translating that into an empty Pascal-record, you should > >> rather look at what the actually used structur in the C-code is. > > > > Actually the C-Code does what C can do really good: obfuscating. > > Yeah. > > > If I understand the code correct, the 'struct a;' itself is never used > directly. > > It always uses 'struct a* foo'. So foo is a pointer to an empty struct > > a, which probably is the C equivalent of a typed pointer. To get strong > type > > checking, I guess, it is ok to follow Felipe's advice: > > > > type a = record end; pa=^a; > > Well, I guess so, but it still doesn't make a lot of sense. > > That "struct a" is not empty (storage size = 0), it is even non-existant > (storage size = unknown). So the C-code may shuffle around the pointers, > but unless this "struct a" (the "a" not even being a type here) is > instantiated somewhere (internally in some library code?) such pointers > are merely typed "void*". The c compiler does not need the internals, so should the pascal bindings. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Translate C to Pascal
Zitat von Vinzent Höfler <[EMAIL PROTECTED]>: >[...] > >>> a: record end; > > > > Thanks. I will use that. > > What for? The C statement is empty, it's not a variable and not even a > type. So before translating that into an empty Pascal-record, you should > rather look at what the actually used structur in the C-code is. Actually the C-Code does what C can do really good: obfuscating. If I understand the code correct, the 'struct a;' itself is never used directly. It always uses 'struct a* foo'. So foo is a pointer to an empty struct a, which probably is the C equivalent of a typed pointer. To get strong type checking, I guess, it is ok to follow Felipe's advice: type a = record end; pa=^a; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello All, > > Does anybody have any idea, what I can do with this problem? >[...] I never saw this problem. > >> > Compiling ./unit/ResConf.pas > >> > Assembling resconf > >> > An unhandled exception occurred at $00148A20 : > >> > TOutputFilter.Execute After Loop > >> > TOutputFilter.Execute fProcess.ExitStatus=217 > >> > >> Hmm. Maybe this means the compiler got an runtime error 217. I wonder what > >> this means. > > VH> That it stopped due to an unhandled exception (that is what RTE217 > means). Normally a process stopping with runtime error 217 gives: TCompiler.WriteError Internal compiler error! (217) Internal compiler error! (217) But Roland does not get this error message and the gdb backtraces do not help much. And for some reasons both lazarus and fpc have trouble. FPC gives 217 and TProcess can not handle it. So it is no normal 217. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello Mattias, > > I have also uncommented some DebugLns which are inside of code: > > Compiling ./unit/ResConf.pas > Assembling resconf > An unhandled exception occurred at $00148A20 : > TOutputFilter.Execute After Loop > TOutputFilter.Execute fProcess.ExitStatus=217 Hmm. Maybe this means the compiler got an runtime error 217. I wonder what this means. >[...] Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[3]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello Mattias, > > I have forgotten to send also result of building under gdb. Here is: > > Compiling ./unit/ResConf.pas > Assembling resconf > An unhandled exception occurred at $00148A20 : > > Breakpoint 1, 0x00017500 in fpc_raiseexception () > (gdb) bt > #0 0x00017500 in fpc_raiseexception () > #1 0x0010d334 in TOUTPUTFILTER__EXECUTE (THEPROCESS=0x2788a20, > ACALLER=0x25e9d40, ATOOL=0x2997200, this=0x27882a0) > #2 0x003b7bbc in TEXTERNALTOOLLIST__RUN (EXTTOOL=0x2997200, > MACROS=0x29780c0, THEOUTPUTFILTER=0x27882a0, COMPILEROPTIONS=0x297ce90, > this=0x25e9d40) at exttooldialog.pas:370 Thanks. Maybe reading fProcess.ExitStatus does some strange things. I added a check in 15949 for the WaitOnExit, so that for a terminated process the ExitStatus is not read. [...] Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello Mattias, > > MG> /usr/local/share/lazarus/lazbuild --build-ide="-va -dVerboseOFExecute" > > I have done all things you wrote me, but the result of compilation > didn't write any line written by WriteLn inside of IFDEFs. Maybe there > could be a bug during parsing of -d parameter and IFDEF sections were > not compiled into the code. Or: FPC does not automatically recompile units if a -d option is given. You must add a -B (build all) yourself or clean up before build. For example: /usr/local/share/lazarus/lazbuild --build-ide="-dVerboseOFExecute -B" > Therefore I have commented IFDEFs out to > get them into lazbuild and the result is the following: > > Compiling ./unit/ResConf.pas > Assembling resconf > An unhandled exception occurred at $00148A20 : > TOutputFilter.Execute W1 > TOutputFilter.Execute W2 > EAccessViolation : Access violation > $00148A20 ok. So, it is somewhere in EndBufferingOutput. Can you add there some writelns and try again? >[...] Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Translate C to Pascal
How to translate this: struct a; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpimage font
What is the status of the freetype font support of fpimage? I tried the following: http://wiki.lazarus.freepascal.org/Developing_with_Graphics#Drawing_without_LCL which runs fine under 32bit, but under 64 bit I get an AV: GNU gdb 6.8-debian [...] Program received signal SIGSEGV, Segmentation fault. 0x7f5d83a92f14 in FT_Get_Glyph () from /usr/lib/libfreetype.so.6 (gdb) bt #0 0x7f5d83a92f14 in FT_Get_Glyph () from /usr/lib/libfreetype.so.6 #1 0x00488b70 in FREETYPE_TFONTMANAGER_$__CREATEGLYPH$CHAR$$PMGRGLYPH () #2 0x7f5d83f05220 in ?? () #3 0x0054 in ?? () #4 0x7f5d83efd2e0 in ?? () #5 0x001e in ?? () #6 0x7fff8bf18c20 in ?? () #7 0x00488c11 in FREETYPE_TFONTMANAGER_$__GETGLYPH$CHAR$$PMGRGLYPH () #8 0x0003 in ?? () #9 0x0014 in ?? () #10 0x0014 in ?? () #11 0x in ?? () Should I debug it, or am I misusing fpimage fonts? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello Mattias, > > Next backtrace: > > Compiling ./unit/ResConf.pas > Assembling resconf > An unhandled exception occurred at $00148A20 : > > Breakpoint 1, 0x00018100 in fpc_raiseexception () > (gdb) bt > #0 0x00018100 in fpc_raiseexception () > #1 0x0010dde4 in TOUTPUTFILTER__EXECUTE (THEPROCESS=0x2700a20, > ACALLER=0x25ded00, ATOOL=0x27c3d90, this=0x27002a0) > #2 0x003b7bac in TEXTERNALTOOLLIST__RUN (EXTTOOL=0x27c3d90, > MACROS=0x27aa800, THEOUTPUTFILTER=0x27002a0, COMPILEROPTIONS=0x27f4e90, > this=0x25ded00) at exttooldialog.pas:370 I think the AV happens somewhere in the finally part of ide/outputfilter.pas 375. I added some verbosity in rev 15849. Please update lazarus svn and compile IDE and lazbuild clean with -dVerboseOFExecute. Then try again. Can you reproduce the bug in a smaller package and send me the example? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[4]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello Mattias, > > Next backtrace: > > Compiling ./unit/ResConf.pas > Assembling resconf > An unhandled exception occurred at $00148A20 : > > Breakpoint 1, 0x00018100 in fpc_raiseexception () > (gdb) bt > #0 0x00018100 in fpc_raiseexception () > #1 0x0010dde4 in TOUTPUTFILTER__EXECUTE (THEPROCESS=0x2700a20, > ACALLER=0x25ded00, ATOOL=0x27c3d90, this=0x27002a0) no line number. :( > #2 0x003b7bac in TEXTERNALTOOLLIST__RUN (EXTTOOL=0x27c3d90, > MACROS=0x27aa800, THEOUTPUTFILTER=0x27002a0, COMPILEROPTIONS=0x27f4e90, > this=0x25ded00) at exttooldialog.pas:370 > #3 0x0017ebb8 in TBUILDMANAGER__ONRUNCOMPILERWITHOPTIONS (EXTTOOL=0x27c3d90, > COMPOPTIONS=0x27f4e90, this=0x25cd860) at buildmanager.pas:1221 >[...] > (gdb) c > Continuing. > EAccessViolation : Access violation >[...] > Fatal: Compilation aborted > > 109034 > $0011D3B4 > $0012AADC > > TExternalToolList.Run Exception: there was an error > ERROR: tool reported error This line should only appear, if the Exception is an EOutputFilterError, not on EAccessViolation. Strange. I will do some tests tonight on a Mac. > Program exited with code 02. > (gdb) > > > But I don't see any debug information from freepascal's executable. > > This is really strange, because our package is compilable alone > without problem. Indeed. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Roland Turcan <[EMAIL PROTECTED]>: > Hello all, > > Backtrace from lazbuild: > > An unhandled exception occurred at $00148A30 : > > Breakpoint 1, 0x00018090 in fpc_raiseexception () > (gdb) bt > #0 0x00018090 in fpc_raiseexception () > #1 0x001106d4 in CHECKFORURGENTMESSAGES (P=1, parentfp=0xbfffe0c0) at > outputfilter.pas:561 > #2 0x0010e400 in TOUTPUTFILTER__READFPCOMPILERLINE (S=0x3129048, > this=0x27002a0) > #3 0x0010e0b8 in TOUTPUTFILTER__READLINE (S=0x3129048, DONTFILTERLINE=false, > this=0x27002a0) at outputfilter.pas:418 > #4 0x0010dbcc in TOUTPUTFILTER__EXECUTE (THEPROCESS=0x2700a20, > ACALLER=0x25ded00, ATOOL=0x27c3ac0, this=0x27002a0) > #5 0x003b7c1c in TEXTERNALTOOLLIST__RUN (EXTTOOL=0x27c3ac0, > MACROS=0x27aa200, THEOUTPUTFILTER=0x27002a0, COMPILEROPTIONS=0x27f4e90, > this=0x25ded00) at exttooldialog.pas:370 >[...] This exception is normal and caught in ide/exttooldialog.pas 387. Please continue and see what comes next: gdb ./lazarus.app/Contents/MacOS/lazarus break FPC_RAISEEXCEPTION r bt c bt c bt Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ugly exception during compilation FPC 2.3.1 MacOS X 10.5 PowerPC
Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > On 22 Jul 2008, at 11:13, Mattias Gaertner wrote: > > > The Lineinfo unit does not work currently under Mac OS X. > > The lineinfo unit does work under Mac OS X (but only for stabs > currently). Ah. This means: either lineinfo and a lot of linker warnings on each compile XOR no lineinfo and no warnings, right? dwarf is the future, isn't it? What is needed to get lineinfo working with dwarf? > Depending on the used system version, it may also only > work if you start the program with the full path, because paramstr(0) > is not guaranteed to contain the full path to the binary (as for why, > see http://lists.apple.com/archives/darwin-kernel/2004/Jul/ > msg00058.html ; and note that those arguments hold equally well for > any *nix, so in general it's a bad idea to rely on paramstr(0) being a > valid full path to some existing file). Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Mac OS X 10.5
Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > On 16 Jul 2008, at 14:56, Mattias Gärtner wrote: > > > Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > > >> Well, if it found units before you did that, you probably had > >> a .fpc.cfg somewhere in your home directory already. > > > > Maybe. I didn't check. > > I called samplecfg first as normal user and so samplecfg ignored my > > parameters > > and wrote the config to my home directory. A strange automatism. I > > deleted it > > and ran it again with sudo. > > It really is only intended to be run by installers, which is why its > usage is nowhere documented. In this case you can call me 'installer'. ;) > Snapshots are also only intended to be > installed on top of official releases. On most if not all platforms at > least some things are missing if you start with just a snapshots (such > as binutils or a config file). > > > But if there was an ~/.fpc.cfg, then it could only be created by > > 2.2.0 or the > > 2.2.2rc1 snapshot. > > No, samplecfg generates a ~/.fpc.cfg if it cannot create fpc.cfg in > the designated location. I meant, that I only installed 2.2.0 and 2.2.2rc1 via a dmg. So these are the only candidates for running samplecfg. > > Maybe through the above automatism? > > But they all used $fpcversion, don't they? If yes, then all fpc > > versions should > > create a useful fpc.cfg? > > If the basepath in the generated (.)fpc.cfg is correct, yes. All installations were in /usr/local/lib/fpc. > >> That issue is documented on the FPC Mac OS X download pages and 2.2.1 > >> starting packages for Mac OS X 10.5.x are are provided there. > > > > Where? > > > > I did this: drove browser to www.freepascal.org, click on download > > on the right > > panel, then Binaries / intel/i386 / Mac OS X, choose as mirror > > Sourceforge, and > > there is only the 2.2.0 version. > > The problem is that there is no download page with explanations on > sourceforge (I don't know whether it's even possible to do that). You > can see it on all of the regular download pages. That release was > however indeed never uploaded to sourceforge. On the australian page there is only a small hint at the end of the page about dwarf debugging. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Mac OS X 10.5
Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > On 16 Jul 2008, at 13:15, Mattias Gärtner wrote: > > > Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > > >> This is strange, since the FPC config files all use $fpcversion to > >> set > >> the unit paths. > > > > BTW, for some reasons 'make install' did not recreate the /etc/ > > fpc.cfg. > > That is by design. /etc/fpc.cfg is only created by the installers of > releases on our website. > > > I did it > > manually by calling samplecfg with $fpcversion. But it did not make > > any > > difference. The errors stayed the same. > > Well, if it found units before you did that, you probably had > a .fpc.cfg somewhere in your home directory already. Maybe. I didn't check. I called samplecfg first as normal user and so samplecfg ignored my parameters and wrote the config to my home directory. A strange automatism. I deleted it and ran it again with sudo. But if there was an ~/.fpc.cfg, then it could only be created by 2.2.0 or the 2.2.2rc1 snapshot. Maybe through the above automatism? But they all used $fpcversion, don't they? If yes, then all fpc versions should create a useful fpc.cfg? > >> There was also no 2.2.2rc1 release for Mac OS X > >> (although it may have been distributed along with some Lazarus > >> snapshot(s)). > > > > Yes, I had to use the lazarus snapshot of fpc as start compiler, > > because the > > 2.2.0 failed to compile fpc 2.2.3 and 2.3.1 (Access Violation). What > > is the > > current startup compiler for Mac OS X 10.5? > > That issue is documented on the FPC Mac OS X download pages and 2.2.1 > starting packages for Mac OS X 10.5.x are are provided there. Where? I did this: drove browser to www.freepascal.org, click on download on the right panel, then Binaries / intel/i386 / Mac OS X, choose as mirror Sourceforge, and there is only the 2.2.0 version. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Mac OS X 10.5
Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > On 16 Jul 2008, at 10:26, Mattias Gärtner wrote: > > > Maybe you misunderstood: I did not use the lazarus 'make install'. > > I installed fpc with 'make install'. This installed fpc 2.3.1 in a > > separate > > directory (/usr/local/lib/fpc/2.3.1) (separate from the prior > > installed fpc > > 2.2.2rc1). > > And I did a lazarus 'make clean all'. This lead to the strange > > linker errors. > > This is strange, since the FPC config files all use $fpcversion to set > the unit paths. BTW, for some reasons 'make install' did not recreate the /etc/fpc.cfg. I did it manually by calling samplecfg with $fpcversion. But it did not make any difference. The errors stayed the same. I did not check the diff between both fpc.cfg. > There was also no 2.2.2rc1 release for Mac OS X > (although it may have been distributed along with some Lazarus > snapshot(s)). Yes, I had to use the lazarus snapshot of fpc as start compiler, because the 2.2.0 failed to compile fpc 2.2.3 and 2.3.1 (Access Violation). What is the current startup compiler for Mac OS X 10.5? But I don't think the 2.2.0 nor 2.2.2 had to do with the bug, because I didn't use 2.2.0 nor 2.2.2 to compile lazarus and the solution was to remove all the ppu files of 2.3.1 and lazarus. So 2.2.0 nor 2.2.2 never touched the ppu/o files. The only explanation is that some ppu/o files mixed up. Maybe some search paths contain some invalid paths? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Mac OS X 10.5
Zitat von Schindler Karl-Michael <[EMAIL PROTECTED]>: > Am 16. Jul 2008 um 09:44 schrieb Mattias Gärtner: > > > Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > > >> > >> On 15 Jul 2008, at 00:16, Mattias Gaertner wrote: > >> > >>> Now only the wrong file formats. > >>> zbase, gzio, crc, zdeflate, ... inffast. Hmm. These are only the .o > >>> files in paszlib. > >> > >> I can't reproduce it. One thing you can try is compiling with -Cn and > >> checking the generated link.res file to make sure that the object > >> files which are linked in are the ones you expect to be linked in. > > > > I removed all fpc .o/.ppu files under /usr/local/lib and in lazarus. > > Then it > > worked. Apparently somewhere the fpc make install / lazarus make > > clean does not > > replace/delete all files. > > make clean does not delete installed files from make install. Maybe you misunderstood: I did not use the lazarus 'make install'. I installed fpc with 'make install'. This installed fpc 2.3.1 in a separate directory (/usr/local/lib/fpc/2.3.1) (separate from the prior installed fpc 2.2.2rc1). And I did a lazarus 'make clean all'. This lead to the strange linker errors. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC and Mac OS X 10.5
Zitat von Jonas Maebe <[EMAIL PROTECTED]>: > > On 15 Jul 2008, at 00:16, Mattias Gaertner wrote: > > > Now only the wrong file formats. > > zbase, gzio, crc, zdeflate, ... inffast. Hmm. These are only the .o > > files in paszlib. > > I can't reproduce it. One thing you can try is compiling with -Cn and > checking the generated link.res file to make sure that the object > files which are linked in are the ones you expect to be linked in. I removed all fpc .o/.ppu files under /usr/local/lib and in lazarus. Then it worked. Apparently somewhere the fpc make install / lazarus make clean does not replace/delete all files. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Wednesday 02 July 2008 11.08:31 Mattias Gärtner wrote: > > Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > > > For example lib/common/kernel/msedrawtext.pas:223, procedure layouttext. > > > > Nice code. > > As far as I can see, it handles tabs, linebreaks, c_softhyphen and > > charwidth. It uses single array element per character optimizations, like > > the charwidths array. > > I think I would simply keep that and define the characterwidth for the > > follow up elements as 0. > > Then you only need to change the places where you check for the > > c_softhyphen. And because this is a constant you can even use some tricks > > here. > > I don't see how this have a big impact on the performance. > > > The code is complicated enough, don't you think? ;-) Ah, sorry, now I understand. You meant, the performance penalty of the *programmer* is not negligible comparing ASCII/UCS-2 and UTF-8/16. Yes, it's true, that for layout code it is often better (readability, maintance) to refactor the code first, before extending it for UTF. Especially if it is optimized code. BTW, where is the layout code that handles Right-To-Left, kerning and sub pixel rendering? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Wednesday 02 July 2008 09.32:17 Mattias Gaertner wrote: > > On Tue, 1 Jul 2008 18:55:44 +0200 > > > > Martin Schreiber <[EMAIL PROTECTED]> wrote: > > > On Tuesday 01 July 2008 18.32:30 Mattias Gärtner wrote: > > > > > In this routines length(widestring), widestring[index], > > > > > pwidechar^, pwidechar[index], pwidechar + offset, pwidechar - > > > > > pwidechar and inc(pwidechar)/dec(pwidechar) are used often. This > > > > > can't be done with utf-8 strings. > > > > > > > > Ehm, do you know, that UTF-8 has the advantage, that many ascii > > > > functions work without change? > > > > For example ReplaceChar or searching a substring? > > > > > > Sure, but for layout calculation and the like we need fast access to > > > codepoints. > > > > Can you point me to an example function, where this is critical? > > > For example lib/common/kernel/msedrawtext.pas:223, procedure layouttext. Nice code. As far as I can see, it handles tabs, linebreaks, c_softhyphen and charwidth. It uses single array element per character optimizations, like the charwidths array. I think I would simply keep that and define the characterwidth for the follow up elements as 0. Then you only need to change the places where you check for the c_softhyphen. And because this is a constant you can even use some tricks here. I don't see how this have a big impact on the performance. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Tuesday 01 July 2008 13.13:19 Mattias Gärtner wrote: > > Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > > > On Tuesday 01 July 2008 12.19:26 Mattias Gärtner wrote: > > > > Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > > > > > I did it with utf-8 and UCS-2, beleave me, it was not negligible. > > > > > > > > Where is the code in msegui? (the code that was formerly UTF-8, not the > > > > old UTF-8 code) > > > > > > lib/common/kernel/msedrawtext.pas, mserichstring.pas, msestrings.pas. > > > > > > http://sourceforge.net/projects/mseide-msegui > > > > Thanks. Can you be little bit more specific? I see a lot of functions. Most > > of them can treat UTF-8 as 8bit encoding. Unless you want to do something > > special. > > > In this routines length(widestring), widestring[index], pwidechar^, > pwidechar[index], pwidechar + offset, pwidechar - pwidechar and > inc(pwidechar)/dec(pwidechar) are used often. This can't be done with utf-8 > strings. Ehm, do you know, that UTF-8 has the advantage, that many ascii functions work without change? For example ReplaceChar or searching a substring? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Summary on Re: [fpc-pascal] Unicode file routines proposal
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>: > Michael Van Canneyt wrote: > > > > On Tue, 1 Jul 2008, Paul Ishenin wrote: > > > >> Michael Van Canneyt wrote: > >>> You can still do C:=S[i]. What you cannot do is > >>> > >>> P:=PChar(S); > >>> While (P^<>#0) do > >>>SomeByteSizedOperation; > >>> > >> Why you cannot? PChar(S) should represent S as raw bytes. If you know what > you > >> are doing - it will not harm. In other case, if you corrupt the string > then > >> you are responsibile for all problems you get. > > > > Obviously you can :-) > > But what I meant was that you shouldn't expect old code > > that relied on 1-byte characters to work. > > It is supposed to break on utf-xx or whatever anyways. The above works normally for UTF-8. UTF-8 was designed for this. That's why most ansistring code works with UTF-8. Switching to UTF-8 was easy. Switching to UTF-16 needs more work. And a multi encoded string will break even more things. Means: more work. The question is: how much more? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Tuesday 01 July 2008 12.19:26 Mattias Gärtner wrote: > > Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > > > > > > I did it with utf-8 and UCS-2, beleave me, it was not negligible. > > > > Where is the code in msegui? (the code that was formerly UTF-8, not the old > > UTF-8 code) > > > lib/common/kernel/msedrawtext.pas, mserichstring.pas, msestrings.pas. > > http://sourceforge.net/projects/mseide-msegui Thanks. Can you be little bit more specific? I see a lot of functions. Most of them can treat UTF-8 as 8bit encoding. Unless you want to do something special. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Martin Schreiber <[EMAIL PROTECTED]>: > On Tuesday 01 July 2008 10.35:00 Mattias Gaertner wrote: > > > A good example is text layout calculation where it is necessary to > > > iterate over characters (glyphs) over and over again. > > > > Text layout nowadays need to consider font widths and unicode specials. > > Iterating from character to character should be hardly measurable > > compared to this. For example synedit does not yet care much about font > > widths and unicode specials and the UTF-8 stepping is negligible. > > > I did it with utf-8 and UCS-2, beleave me, it was not negligible. Where is the code in msegui? (the code that was formerly UTF-8, not the old UTF-8 code) > > > I think the best compromise for a GUI framework are referencecounted > > > widestrings where normally physical index = code point index. If one > > > needs characters which are not in the base plane, he must use > > > surrogate pairs and more complicated and slower processing. I assume > > > this will be seldom used. > > > > It depends if your code should solve a special problem or if you > > write a library that should work for all. The RTL and FCL should work > > for all. So they must support UTF-16 and can not use a > > limited widestring. > > > That's why I wrote "for a GUI framework". There we have always the > possibility > to access the OS with optimized routines independent from RTL and FCL and to > provide the optimozed stringhandling routines for the chosen internal string > representation. What is necessary for the toolkit user is automatic > conversion from the GUI framework internal string type to the system > encoding. That already exists for widestrings. Ah, ok. Yes, a gui framework is a special case. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode file routines proposal
Zitat von Felipe Monteiro de Carvalho <[EMAIL PROTECTED]>: > Hello, > > There is already another thread about that, but the thread got too > long, and I would like to make a concrete proposal about unicode file > routines. > > It looks simple to me, there are just 2 ways to go, either utf-8 or > utf-16. Correct me if I am wrong, but I beliave that FPC developers > prefer utf-16, so we can have a widestring version of every routine in > the RTL which involves filenames. > > So let me start with a concrete example: > > http://www.freepascal.org/docs-html/rtl/system/assign.html > > We would need to add a: > > procedure Assign( > var f: ; > const Name: widestring > ); > > Also for all this routines: > > http://www.freepascal.org/docs-html/rtl/sysutils/filenameroutines.html > > Under Windows it can be implemented like this with Windows 9x support: > > procedure AnyFileRoutineInWin32(AFileName: widestring); > begin > if UnicodeEnabledOS then SomeWin32APIW() > else AnsiToWideString(SomeWin32ApiA()) > end; But what about all existing code? For example the FCL? How will TStringList.LoadFromFile be converted? > One can initialize UnicodeEnabledOS by reading the operating system > version and the operating system type NT/9x very easily. > > Under Windows 9x we won't support true unicode filenames, but this > doesn't matter, because the operating system doesn't support them > anyway. The widestring routines will keep working under Windows 9x for > most code. > > This method is used with great success in the LCL. Extended information here: > > http://wiki.lazarus.freepascal.org/LCL_Unicode_Support#Guidelines Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] UTF8String
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > > Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > > > > types? > > > > > > It will be released in August. > > > > If they are bold enough for this big incompatibility, then maybe we must be > > braver too. > > What, also stop supporting anything but Windows? ;) I meant, break some compatibility too. At the moment the RTL uses Ansi = current code page < unicode. And so any filename that uses indirectly these functions is limited to the current code page. One solution is to create a new string type UTF8String. Similar to AnsiString/WideString auto conversions, there would be an auto conversion AnsiString/UTF8String, IFF there is an UTF-8 string manager. The RTL and FCL can use it for filenames and similar things. There should be some compiler flags to set the default string type to either ansistring or utf8string. All lazarus related sources would set the default string type to utf8 and would load an UTF-8 string manager. Drawbacks: - If a UTF8 string manager is enabled, old code that uses ansistring would double recode filenames under windows. From ansistring to UTF8 to widestring. I guess in case of filenames this is hardly measurable. - Mixing code compiled with ansistring and compiled with UTF8String will be slower due to the conversions. Especially when exchanging big lists of string like TStringList.Assign. Remedy: enable UTF8String and fix the few issues. This might be arbitrary difficult and/or unpleasant. But hey, CodeGear says that even switching from ansistring to widestring is easy. And of course you can still use 'ansistring' explicitly. - Mixing code compiled with ansistring and compiled with UTF8String with dirty typecasts will create hidden conversion errors. Remedy: Same as above. - If the most common RTL/FCL functions are *not* converted to UTF8String then all UTF8String programs will become very slow and might even get conversion errors, due to typecasts. So, if RTL/FCL don't use it, no one will. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode filenames
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > > Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > > > > > > > > Makes me wonder how CodeGear is going to handle something like this. > > > > Have they released more information on their Unicode support? > > > > > > They actually use unicode support, so NT only -W functions. > > > > Do you know what happen with their plans of creating a new string type (a > > reference counted 2-byte string) and changing all String and Char to the > 2-byte > > types? > > It will be released in August. If they are bold enough for this big incompatibility, then maybe we must be braver too. > > Is this only for .net or for the win32 too? > > Both. (and afaik .NET already is), but they don't have an unix to keep track > of, so we can't simply follow them blindly. True. I guess, FPC will support the new string type and create some compiler directives/flags to control the default string/char type, won't it? And it will use the widestring manager to auto convert these types, won't it? So FPC will be able compile the new Delphi code, although the code will run slower and there will conversion errors on non ansi characters. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode filenames
Zitat von Marco van de Voort <[EMAIL PROTECTED]>: > > 2008/6/30 Mattias G?rtner <[EMAIL PROTECTED]>: > > > > >> No idea if this is enough for all cases (I'm not a unicode guru), but > > >> Vladimir (russian developer) reported that it works for him. > > > > > > Of course it works for him - MS keeps things going. As long as a user > stays in > > > his code page it works. > > > > Ah, now I get it!! I'm a bit slow today. :-) Using characters > > outside of the current code page range needs special attention. > > Thanks for your explanation. I now understand the problem. > > > > Makes me wonder how CodeGear is going to handle something like this. > > Have they released more information on their Unicode support? > > They actually use unicode support, so NT only -W functions. Do you know what happen with their plans of creating a new string type (a reference counted 2-byte string) and changing all String and Char to the 2-byte types? Is this only for .net or for the win32 too? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode filenames
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/6/30 Mattias Gaertner <[EMAIL PROTECTED]>: > > > > Can you test to create a chinese filename in the explorer. For example: > > > > ±±·½»°.txt > > I can't create that file in Windows Explorer. I'm using Windows 2000 > in a VMWare session. I opened explorer. Then copied the filename above > to the clipboard from Linux (where Firefox and GMail runs). The then > go to Window VMWare session. Right Click and create now text file. > Past the chinese name, which then seems to escape the name. Maybe that's the way 'explorer' handles unsupported characters in the font. Windows has still to go a long way for real unicode. > When I > press enter to confirm the name, Windows gives me an error. > > See the screenshot. > http://opensoft.homeip.net/~graemeg/test.png Ok. Thanks for trying out. It's not that important. I think it's clear now, that windows need the W functions. > PS: > I hope I got the Apache access permisions correct to my home folder. > Let me know if there is a problem accessing the image, then I'll move > it somewhere else on the web. Works here. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode filenames
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/6/30 Mattias Gaertner <[EMAIL PROTECTED]>: > >> Even Linux's terminal didn't display the russian directory correcty. > >> A whole bunch of '?' instead. fpGUI worked fine! ;-) > > > > How did you change to russian locale? > > By setting the LANG environment variable. > export LANG=ru.UTF-8 That's not a valid lang value. export LANG=ru_RU.UTF-8 But the important part is the UTF-8. If you don't change this, then the terminal will still use UTF-8 and the fonts will not change. If it shows '??' then the filename is not a valid UTF-8 string or your terminal shows unsupported characters as '??'. For example xterm shows rectangles for valid but unsupported characters. > > Linux is not the problem here. Windows is. You must use the W functions. > > We do use the W functions in the GDI backend. As show in Felipe's post. > > if UnicodeEnabledOS then > ... // W functions > else > // plain functions And the same must be done for filenames. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode filenames
Zitat von Graeme Geldenhuys <[EMAIL PROTECTED]>: > 2008/6/30 Vincent Snijders <[EMAIL PROTECTED]>: > > > > But for filenames in fpgFileExists? > > Sorry, yes the previous code was for things like painting text. > > > Here is the code for fpgFileExists > > // platform indepenent > function fpgFileExists(const FileName: TfpgString): Boolean; > begin > Result := FileExists(fpgToOSEncoding(FileName)); > end; ok > // GDI dependent > function fpgToOSEncoding(aString: TfpgString): string; > begin > Result := Utf8ToAnsi(aString); > end; Not ok. UTF8ToAnsi converts to the current windows 8bit code page. Each code page only supports a few languages, but not all. See: http://www.microsoft.com/globaldev/reference/WinCP.mspx As you can see, the 1250 is for whole central europe, so french, spanish, german, english - they all use the same codepage. Russian needs another. And afaik chinese is converted to DBCS. (I did not try) > function fpgFromOSEncoding(aString: string): TfpgString; > begin > Result := AnsiToUtf8(aString); > end; ok. I wonder, what windows gives for characters not in the current code page. > No idea if this is enough for all cases (I'm not a unicode guru), but > Vladimir (russian developer) reported that it works for him. Of course it works for him - MS keeps things going. As long as a user stays in his code page it works. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.2.1 on Mac OS X
Zitat von Felipe Monteiro de Carvalho <[EMAIL PROTECTED]>: > On Fri, May 23, 2008 at 9:59 AM, Mattias Gärtner > <[EMAIL PROTECTED]> wrote: > > It will change, as soon it works 'better'. > > Sure, but what does better mean? Better then what? Is there any real > alternative at the moment to the Carbon IDE? > > Have you ever worked with the Gtk IDE under Mac OS X? Yes, but this is long ago. > The installation > problems are just the point of the iceberg. Copy+Paste doesn't work. > Do you see how this can be annoying? You open your e-mail, want to > paste some code to the editor and bang, it's impossible =/ > > Also, It crashed every 5 minutes. It looks crappy. It is absolutely > unusable, even for developers, and trust me, I tryed to use it for a > long time, and I eventually gave up because it's simply unusable. Apparently it worked better for me. > I use the Carbon IDE daily and there are only some minor bugs (all > already reported). Sometimes the tabs show the wrong file, sometimes > it needs a restart, but it looks very good, is very fast, doesn't need > X11, copy+paste works, it never crashed for me, ... > > I think that the Carbon IDE is ready on it's own merits, and even if > there are bugs, there is no other alternative, so it's irrelevant. Great. I was little bit worried about the heavy development and the bugs in the tracker. But if the development does no longer create new bugs for the IDE, then let's change it. Will you do that? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.2.1 on Mac OS X
Zitat von Vincent Snijders <[EMAIL PROTECTED]>: > Felipe Monteiro de Carvalho schreef: > > On Fri, May 23, 2008 at 8:49 AM, Bent Normann Olsen <[EMAIL PROTECTED]> > wrote: > >> I just tried to install fpc 2.2.1 and clean/build Lazarus, but it says > (many > >> lines skipped): > >> > >> ... > >> Linking ./hello > >> /usr/bin/ld: can't locate file for: -lglib-1.2.0 > > > > You are building Lazarus for Gtk 1. I recommend against doing that, > > because copy+paste won't work, it's needs X11 and fink to run, etc. > > > > Build Lazarus instead for the native Carbon interface: > > Why don't the Mac OS X maintainers for Lazarus change the default LCLPLATFORM > in the > Lazarus makefiles to carbon, if that is the recommended widget set? It will change, as soon it works 'better'. Some months ago it was not. The carbon was easier to compile/install, but it had some bugs and unstabilities making the IDE hardly usable for non devels. How many major bugs are left for the carbon widget set? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FreePascal Coding style
Zitat von Vinzent Hoefler <[EMAIL PROTECTED]>: > On Monday 21 January 2008 13:54, Marco van de Voort wrote: > > > On Monday 21 January 2008 11:59, Marco van de Voort wrote: > > > > > > > Nor does an editor. It can only help. I also think being to focussed > > on coding standards (to the point of enforcing) is counterproductive. > > > > > As an example where most tools just put out nonsense, consider this: > > > |type > > > | CPU_Ins = (Add, Sub, Mul, Div, > > > | Jnz, Jz, Jnc, Jc, > > > | Call, Ret, > > > | Push, Pop, > > > | ...); > > > > > > Now, as you can see, the instructions are laid out tabular (a lot > > > of tools [yes, including "elastic tabstops"] I've seen so far are > > > unable to handle even that simple case). > > > > Then you'll add a tool switch to make enums tabbable. That's actually > > an easier example than Graeme's original. > > Oh, come on. What if you encounter an enum that does *not* require > such "tabbing" inside the same source file. > > Of course you can do it all configurable until the tool formats as you > would like it to format, but in the end this leads to one tool > configuration per source file. Also to be checked in into version > control in case the source file somehow changes and its formatting > configuration needs to be adjusted. > > > Note that this is the first time that I actually saw this enum > > formatting as an requirement. Do you have a criterium for this? > > I didn't say, it's a requirement. But I don't want a tool to reformat > code, which has been explicitely logically ordered for readability, a > better overview over the instruction set, and for easier extensionby > the coder. > > > > And even if the tool is a bit more intelligent and detects the > > > tabular design, how is it supposed to know which instructions are > > > more similar to the other and should appear in a row and which ones > > > not? > > > > If you make coding standards an artform, you'll need an artist. > > No. A simple set of rules is sufficient. The only problem with those > simple rules is that they can bend and there's no tool yet which knows > how far it may bend the rule for formatting a certain piece of > code... ;) > > The first universal rule is that the code needs to be readable. This > overrules any other rule anyway. > > > The only exception I can see is documentation, but then you'll need > > meta info to the formatter. Either in source, or out source > > (unitname.enumx.style:=tabular or something in some metafile) > > Yeah, great. Just like /*INDENT-OFF*/ in each and every C-source file > I've ever checked into the company's CVS before we threw out the whole > auto-formatting on check-in. > Ok, GNU-indent is probably not the best auto-formatter (in fact, it's > one of the worst I've ever seen), but you get the idea, I suppose. > > > > Code is primarily written for humans. Otherwise we wouldn't care > > > about the formatting. Interestingly, to format code properly you'd > > > need to understand it. And that's something that currently only a > > > human can do. > > > > Depends on your definition of "properly". > > There's only one: You need to easily understand it when you read it. > Even if you read it 10 or 15 years after it has been written. And > contrary to popular beliefs, there's a substantial amount of visual > appearance involved. > > In other words: Sexy code is easier to understand. ;) That's true on a pascal list. Other languages care less. It seems, pascal programmers are people preferring readable code - not only when they write pascal. If I understand the thread correct, it is about 'a formatter is needed' and 'no formatter is perfect'. IMO the solution is context sensitivity: A formatter should not have one set of rules, but at least two. Some rules should be enforced and some should only be applied if manually started. For example: A hard rule could be: The line after a 'begin' should have at least the indent of the 'begin' line. A extra rule could be: The line after a 'begin' should be indented 2 spaces. The hard rule could be applied, when text is pasted. The extra rule is only applied if the user selects some text and uses the IDE function 'beautify selection'. And the rules must be project/package and language specific. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 0.9.24 released
Zitat von Rainer Stratmann <[EMAIL PROTECTED]>: > Am Mittwoch, 21. November 2007 13:37 schrieb Bernd Mueller: > > Mattias Gaertner wrote: > > > The Lazarus team is glad to announce the 0.9.24 release. This release > > > is based on fpc 2.2.0. > > > > Thank you. I used the 0.9.20 since November 2006. The progress you did > > with the 0.9.24 is huge. > > I wanted to use, but find it difficult to install. > Runs it with KDE? > I installed sidux www.sidux.com > Runs it with KDE Desktop of sidux? > Is there a Distribution with build in Lazarus? No. At least none with a recent stable lazarus. One that comes close to it is ubuntu plus our repository: http://wiki.lazarus.freepascal.org/Getting_Lazarus#Getting_Lazarus_from_our_Ubuntu_repository Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Speed
Zitat von Krishna <[EMAIL PROTECTED]>: > On 10/30/07, Mattias Gärtner <[EMAIL PROTECTED]> wrote: > > Zitat von Krishna <[EMAIL PROTECTED]>: > > > > > On 10/30/07, Valdas Jankūnas <[EMAIL PROTECTED]> wrote: > > > > > > > P.S. Where i can read tips about writing fast FP code? > > > > > > > > > > Here's one: profile your code! > > > > And where can you read how to do that? > > The section on gprof in the FPC User's Guide? And ofcourse the gprof > manual itself. Yes, that's ok for some platforms. But gprof/fpc does not work under linux anymore. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Speed
Zitat von Krishna <[EMAIL PROTECTED]>: > On 10/30/07, Valdas Jankūnas <[EMAIL PROTECTED]> wrote: > > > P.S. Where i can read tips about writing fast FP code? > > > > Here's one: profile your code! And where can you read how to do that? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SNMP For Accessing PDUs
Zitat von Robert Wolfe <[EMAIL PROTECTED]>:
> Good morning, folks!
>
> I am in desperate need of an SNMP unit that will let me pull information
> from an APC PDU via SNMP for some network monitoring software I need to
> write. I currently use Synapse, however, and the program I have
> currently seems to connect to the PDU via SNMP, but it fails to retrieve
> any data.
>
> Any suggestions would be greatlfully appreciated!
This works:
procedure MiniSNMPTest;
var
OIDSysName: String;
aSNMPSend: TSNMPSend;
i: Integer;
CurMIB: TSNMPMib;
begin
aSNMPSend := TSNMPSend.Create;
aSNMPSend.Query.Clear;
aSNMPSend.Query.Community := 'public';
aSNMPSend.Query.PDUType := PDUGetRequest;
aSNMPSend.TargetHost := '192.168.0.1';
OIDSysName:='1.3.6.1.2.1.1.5.0'; // system.sysName.0
aSNMPSend.Query.MIBAdd(OIDSysName, '', ASN1_NULL);
if aSNMPSend.SendRequest then begin
for i:=0 to aSNMPSend.Reply.MIBCount-1 do begin
CurMIB:=aSNMPSend.Reply.MIBByIndex(i);
if CurMIB.OID=OIDSysName then
writeln('Decription: ',CurMIB.Value);
end;
end else begin
writeln('SNMP failed');
end;
aSNMPSend.Free;
end;
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
