Re[2]: [fpc-pascal] Reading text from images
1. As far as I know, there are no free pascal (or Freepascal) libraries working with PDF consistently. However, open-source xPDF and Ghostscript (C/C++) do process PDF files (with some glitches, though). Full PDF reference is available from Adobe, 1.7 (Acrobat 8) included. There are some omissions in the reference, but they are related to very uncommon protection methods only. Of course, some bugs should be present too. 2. Jpeg is a well known fully documented standard, Freepascal lists a package to work with Jpeg as a base one (it's included: the name is pasjpeg). Of course, there are some other open-source libraries. 3. OCR things are more vague, implementing them full-feathered from scratch is enormous task, if you want them to work good, because most methods are uncertain by their nature. But if you want to recognize simple typed text and know the used fonts and scale, the task becomes easier. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Inline and defines
on. As of 2.1.1, it won't matter anymore either since the compiler will always accept the inline specifier, but only actually do something with it if inlining is turned on. Is there a way to know (in terms of $if etc.) that compiler actually does something? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] Inline and defines
Implementing it for all cases is non-trivial and has low priority. Actually, implementing the warning is easy, but always adding the reason why it isn't inlined is more difficult. Jonas I think, that there are many reasons, which will not help me a single bit. However, reliable warning without explanations seems to be a good thing. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[8]: [fpc-pascal] Inline and defines
However, reliable warning without explanations seems to be a good thing. How? I think it's completely useless if you have no idea what it's caused by and what to do about it. Jonas Because I know, that I have to fiddle with program structure or something. One less reason to look into assembler code to see, what happens. (Of course, it concerns only time critical procedures.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] gcc beats fpc again
The one missing FPC program measures the speed and abilities of the regular expressions engine from language distribution. Tonow FPC one has not enough abilities, but the engine may be written even exclusively in assembler or C: what matters is whether it is present in the distribution and has headers file. So this test qualifies basic I/O operations and the distribution. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Growing dynamic arrays performance (another thing)
Is there a canonical way to reserve memory for a dynamic array? When there are several slowly growing dynamical arrays I encountered severe performance drop (probably, they tried to overlap each other many times). Setting estimated length and navigating with extra counter inside each of them (and growing by 10%+100 elements if needed) completely solved the problem. This issue does not seem to be resolvable without manual memory preserving, is it possible to do it so that range checking will work and extra counters won't be needed? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] BLOCKWRITE-restrictions in writing .bmp-file?
IF (((NDum) MOD 4)0) THEN BLOCKWRITE(OutFile,Pixel,SIZEOF(Pixel)); IF (((NDum + 1) MOD 4)0) THEN BLOCKWRITE(OutFile,Pixel,SIZEOF(Pixel)); IF (((NDum + 2) MOD 4)0) THEN BLOCKWRITE(OutFile,Pixel,SIZEOF(Pixel)); 1. If NDum = 4k (e.g. 12=4*3), you write two times; if NDum = 4k + 3 (e.g. 15=5*3), you write two times. It's not right. 2. Check sizeof-s. Are you sure they are one byte each? 3. Are you sure the code worked good before? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] range check errors
Is it a bug or just a feature, that when compiled with -gcl options, program does not report line of range check error (sorry, but I have neither tested it thoroughly nor checked compiler sources)? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] connecting with Delphi (object files,dll etc)
I have a question concerning connecting FreePascal function with Delphi application (under win32). I hope I'm totally wrong in my approach and so hope for some help. 1. DLL files created by FPC 2.0.2 are not usable under Delphi forms (there are about 5 posted unfixed bugs about it by different persons). (But they work, e.g. when you use FPC-FPC.) 2. Of course, rewriting source to be Delphi compatible is poor option: it requires some work and gets slow working program (I want (have) Delphi frontend for intensely calculating FPC console program/unit/library). 3. Connecting object file is difficult: FPC doesn't support OMF (object files), and in FPC 2.0.2 support for COFF (object files) seems to be dropped. FPC produces PECOFF (object files). Sometimes you can translate COFF to OMF by (free?) Borland utility COFF2OMF, but it's not well documented: FPC *.o files are not translated, and I don't know the exact reason (is it their PECOFFness or some other incompatibility? maybe I just use them in a wrong way?). If this approach (DLL or object files) is despairing, I add a few words about two other methods... 4. Pipes are nice when you redirect stdout of some utility to file, but are pretty unclearly documented (yes, I do grow my hands from behind and can't get them to work stable for Delphi-FPC pair with bidirectional information flow). 5. The last approach is freaky: just run one application from the other and exchange information via named file on disk. Can anybody suggest something on one of this method? Can anybody suggest some other way of program to program communication of Delphi-FPC? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] connecting with Delphi (object files, dll etc), assemblers and FPC
Florian Klaempfl wrote: Пётр Косаревский wrote: 3. Connecting object file is difficult: FPC doesn't support OMF (object files), and in FPC 2.0.2 support for COFF (object files) seems to be dropped. FPC produces PECOFF (object files). FPC supports OMF by using NASM/MASM/TASM as assembler (e.g. -Amasm). Oh. I tried several assemblers (nasm-wasm and masm=renamed ml, MS assembler). I didn't use special options, but masm and wasm didn't compile, and nasm(win32) generated GPF-ing .exe (in program mode). In all three modes program without asm usage worked (by itself or by calling function from dll/unit). (I didn't post it as FPC bug, because I'm not using these tools regularly and don't want to prove or falsely proclaim FPC guilt.) I had some issues (both in unit, library and program modes): MASM (ML, version 7.10.3077) (minor) constant strings contained symbols from 128-255 region (russian text used for debugging messages) and were converted into too long strings (not really long: no more than 320 symbols in my case) (by the way, using crt (i know it's legacy stuff) converts such symbols into '?', and so do mailers of many posters: Florian was rare one to save my russian name (unreadable by many)) (fatal for me) (line 18465 [near eof]) fatal error A1010: unmatched block nesting : _BSS (fatal too, but macabre [I need OMF]) (line 2 [near file beginning])error A2214: GROUP directive not allowed with /coff option WASM (Open Watcom Assembler Version 1.2) (fatal for me) (line 17949 [near eof]) Error! E506: block nesting error. NASM (version 0.98) I have already typed: program was compiled, but .exe happily outputs Run time error 216... I have not checked lines-too-long (i.e. db too complex) for wasm and nasm. I wrote this message both because want my problem be solved (now I believe in some crude workaround), and to help developers expect issues of the software discussed. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] how to pass PChar (or any pointer) fromDelphi to FPC ?
-Original Message- From: Jonas Maebe [EMAIL PROTECTED] On 4 apr 2006, at 11:14, Пётр Косаревский wrote: How do you transfer these pointers and what are you trying to accomplish? You generally cannot transfer pointers from one running program to another. It may work by accident in some cases, but it is not something you can rely on (even if both programs are compiled by the same version of the same compiler on the same OS and are running on the same machine). Jonas I transfer them as numbers. I work under win32. I transfer them as LParam-s with PostMessage() WinAPI function. Numbers are transferred correctly (I checked it with .messagebox/writeln). I try to have access to the same physical memory (I want to have common read-write variable). Each and every process has its own virtual memory space under win32 (and most other operating systems). You cannot access the same physical memory this way (not in Delphi either), you must use some Win32-specific functions to setup a shared memory area and request the OS to map it in both processes. I don't know how to do this on win32. Jonas PS: in general always reply to the mailing list, unless people explicitly ask not to do that.___ 1. Thank you, I was aware of something like that, but I was really looking for a way to setup that shared memory area. 2. I try to reply to the mailing list, but do not always check the To: field with autoreply (it's like posting the same bug report twice: just press refresh and you send new report instead of looking at the status of the previously posted). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] When are used units recompiled?
Tom Verhoeff wrote: Can someone explain to me under what circumstances FPC will (attempt to) recompile a unit for which *.ppu and *.o are already available? I couldn't find this in the documentation. Wrong target (OS) or incompatible compiler version, usually. Vote for: http://www.freepascal.org/bugs/showrec.php3?ID=4691 :-) Micha It's interesting, because it was the last argument for me to uninstall Lazarus after experiments with compiling it with different compilers. I read about different OS-es, but the reason was probably different compiler version (or something absolutely different). Maybe, if you, Micha, submit patch to compiler sources (i.e. point the lines you want to be changed) to fpc-devel mail list or something, after a short discussion the developers will add such a hint? (Of course, only if it is absent in development branch tonow.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] bug in online docs, spam entry not allowed in bug report system
In online docs, programmer's guide, 11.3 I read, that either -O3 or -Ou enable uncertain optimizations. It seems to me, that only -Ou is to be mentioned (compiler tells, that -O3 is just strenghtened version of -O2). When I tried to submit this report, spam entry not allowed turned out. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] gprof win32
How can one use gprof under win32? While it is possible to download one or another gprof, fpc reports linking error: ld.exe: cannot find -lc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] gprof win32
At 09:54 17-4-2006, you wrote: How can one use gprof under win32? While it is possible to download one or another gprof, fpc reports linking error: ld.exe: cannot find -lc. gprof only works under cygwin Peter Is there any common way of profiling under win32 with freepascal? (One way is obvious: getting timestamps before/after long procedures, analyzing assembler output for little ones. But it's not an easy one.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] gprof win32
While it is possible to download one or another gprof, fpc reports linking error: ld.exe: cannot find -lc. gprof only works under cygwin Peter Is there any common way of profiling under win32 with freepascal? (One way is obvious: getting timestamps before/after long procedures, analyzing assembler output for little ones. But it's not an easy one.) Using gprof is the only way that fpc provides. Peter So, if I install cygwin, will error disappear? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] big const arrays
Is there any easy way to create big array of constants? Does it matter (with maximum optimizations switches), if my 50 Kb array is defined as constant? That is: are there benefits from defining heavily used array as const versus defining it as variable and filling data by program? (For example, array contains precalculated values of some function.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] alignment
Win32, i386. In FPC 2.0.3 -Oa option is described as type=values. This is hard to understand. What should -Oa=16 mean? Probably, it could be better decribed. (If I get it right, the type means code or data, and values are not alignment values for individual types. Even if so, I didn't understand what does it mean.) There are assembler directives .balign 16 for some types in .data or .bss sections (with -Oa=16). Code is aligned with .balign 4 where it's useful. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] another fpc RAD: MSEide
I do neither use Lazarus, nor MSEide, but if executable size is really important, there is something called KOL (I didn't use it either). As I have read, it's currently compilable by FPC. Speaking of bigger applications, I don't see much difference between 6 or 30 Mb executables... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc and intel vtune
Now: I have downloaded evaluation version of intel VTune 8.0 and tried to debug/optimize an application with it. It does not recognize symbols in FPC module (function names etc., source is not supported too). Still, it does work with Delphi, for example. History: Long ago someone complained about some other problems with vtune-FPC and was answered, that they have supported languages and compilers (that day Delphi was not among them), and that they will answer something only on premier support intel site. It concerned old versions of both FPC and vtune. My question: does anyone know, whether vtune can be tuned to work with FPC (at list on function names level) or not? Remark: of course I don't ask here for vtune support, I ask about FPC tools. As far as I know, FPC does not have any profiler under win32 without cygwin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] fpc and intel vtune (now about gprof)
Sorry, eight questions ahead (first two are important to me). -Original Message- From: Florian Klaempfl [EMAIL PROTECTED] To: Пётр Косаревский [EMAIL PROTECTED],FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Date: Tue, 25 Apr 2006 09:57:55 +0200 Subject: Re: [fpc-pascal] fpc and intel vtune Remark: of course I don't ask here for vtune support, I ask about FPC tools. As far as I know, FPC does not have any profiler under win32 without cygwin. Last time I used gprof on win32, it worked fine? Well, not long ago I was told in these maillists, that gprof requires cygwin under win32 for FPC. Is it normal, that compiler (linking stage) tells: ...ld.exe: cannot find -lc and fails? (I thought about installing cygwin, but I don't understand what do I need from it.) Is it supposed, that I integrate cygwin with FPC or something? Is it normal, that FPC from almost fresh base_w32... and fpc-2.0.3.i386-win32... required as.exe and ld.exe (I copied them from slightly older ones)? Is it OK, that after recent FPC update I have to add -Sg for my pretty GOTO (It is objfpc mode, no extra option is required under Delphi)? Is it normal, that with e.g. -va switch I see verbosely what was processed before -va switch? Should I bump the fixed bug about uncommented compiler option -Op4 (it is uncommented in both 2.0.3 and 2.1.x versions)? Is it sufficient to build 2.1.x and rename one of fpc.exe to operate both release and development versions (I didn't try, but it seems that the one ppc386 would be run)? Should I split this message? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] fpc and intel vtune (now about gprof)
Пётр Косаревский wrote:
Sorry, eight questions ahead (first two are important to me).
Well, only WHAT I NEED TO RUN GPROF UNDER WIN32? and WHY cannot find -lc
WHEN COMPILING WITH GPROF SUPPORT? are real questions. Others were like minor
info/bug reporting (not important to me).
Last time I used gprof on win32, it worked fine?
Well, not long ago I was told in these maillists, that gprof requires
cygwin under win32 for FPC.
Is it normal, that compiler (linking stage) tells: ...ld.exe: cannot find
-lc and fails? (I thought about installing cygwin, but I don't understand
what do I need from it.)
Just guessing here: Most probably libc.dll? Better to be answered by
someone else.
Is it supposed, that I integrate cygwin with FPC or something?
No, except that you have to provide its runtime libraries.
Well (guess), if you mean, that libc.dll is a part of cygwin, it's not a bad
idea, but -lc thing doesn't look like a rebus or a charade, it's like an
enigma:)
fpc-2.0.3.i386-win32... required as.exe and ld.exe (I copied them from
I'd say so - if you're talking about snapshots, these tools are not
included in them (as opposed to releases).
You are probably right!
But releases and snapshots don't differ much in their size, so I didn't expect
that about 3% (as.exe and ld.exe) would be dropped intentionally (because they
are needed for functionality). On the other hand, these utilities are not made
by FPC folk. It seems to be the reason for me...
Is it OK, that after recent FPC update I have to add -Sg for my pretty
GOTO (It is objfpc mode, no extra option is required under Delphi)?
Use -Mdelphi (or {MODE DELPHI}) if you want compatibility to Delphi. Use
of GOTO (and some other constructs supported by Delphi) isn't considered a
good programming practice, so it isn't supported by default in native FPC
modes. If you want to use GOTO in these modes, you need to supply -Sg
explicitely.
Well, IT CHANGED, I didn't need to use this option before, it contradicts at
least my expectations of objfpc mode.
If you have a little arithmetical procedure you don't want to write in
assembler (by the way, assembler is not interoperable), GOTO is a good thing.
GOTO do exists in PASCAL syntax, and I use it on my own risk. I even saw this
hint in compiler output, but don't understand the reason for this change
(except trying to complicate compilating to user).
I find overcomplicating source with {$IFDEF}-s more confusing, than labels.
Is it normal, that with e.g. -va switch I see verbosely what was
processed before -va switch?
I'm not sure if I understand what you meant here?
It's nonsense: if it is process in time, there should be no extra (verbose)
messages before processing -va switch, because compiler is not yet in verbose
mode. I believe, some developers do find that remark hackneyed.
Should I bump the fixed bug about uncommented compiler option -Op4 (it
is uncommented in both 2.0.3 and 2.1.x versions)?
I guess it would help to be more specific here - what exactly is wrong,
please?
See bug #.
Is it sufficient to build 2.1.x and rename one of fpc.exe to operate
both release and development versions (I didn't try, but it seems that the
one ppc386 would be run)?
That depends. It could work if you provide proper fpc.cfg in the compiler
directory (and no other fpc.cfg exists in other directories) and if you
make sure to use different output directories for compilation of your own
units.
I just wanted to avoid experiments and asked for solution:)
Should I split this message?
Not necessarily if you don't mind receiving answers in many pieces
(different people responding to different parts). ;-)
Regards
Tomas
Well, you are the first to answer and the only important question is (now about
gprof) :(
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[5]: [fpc-pascal] fpc and intel vtune (now about gprof)
Last time I used gprof on win32, it worked fine? Is it normal, that compiler (linking stage) tells: ...ld.exe: cannot find -lc and fails? (I thought about installing cygwin, but I don't understand what do I need from it.) Just guessing here: Most probably libc.dll? Better to be answered by someone else. Is it supposed, that I integrate cygwin with FPC or something? Sorry, I got it (from bug reports 2888, 4342). I don't have to install cygwin, I only need runtime libraries: libc.dll and may be something more. as,ld question: the answer is in bug report 4462. However, searching bugs or even browsing them is not a good option. Should I bump the fixed bug about uncommented compiler option -Op4 (it is uncommented in both 2.0.3 and 2.1.x versions)? I guess it would help to be more specific here - what exactly is wrong, please? See bug #. Bug number is 4929. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] fpc and intel vtune (now about gprof)
Jonas Thank you, it was very clear (except bug 4929, and I can kinda answer that question myself: probably if -CpPENTIUM4 is specified, optimizations are automatically for Pentium4). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[7]: [fpc-pascal] fpc and intel vtune (now about gprof)
ON TOPIC: maybe shipping with FPC cygwin runtime libraries for gprof wouldn't harm? Because: 1. Some are shipped (for FP --- IDE) 2. If I am right, libc, libgcc, libgmon and libkernel32 are needed, they shouldn't be weightier than some rarely used binary utils 3. Full CYGWIN is not required (as I guess, MINGW is more appropriate [its rtl], isn't it?) 4. -pg is a compiler option, not some external feature implying installation of something BRANCH: Bug number is 4929. a valid option. So my statement is still the same - could you be more specific what is wrong, please? Tomas Well, it is not a bug. I even submitted it as compatibility or something. I do call it a bug, because it was marked Fixed, not Not a bug. BUT: 2.0.3 2006.4.20 does not emit warning, nor do I see one in compiler messages file. (Maybe you mean still BUGGY maximum optimize, Ox? [don't mix with older comments about still BUGGY!!! register optimizations]) Sorry for inconveniences. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[9]: [fpc-pascal] fpc and intel vtune (now about gprof)
These are pretty big when taken together. ... ... An optional downloadable package would probably make more sense though. Yes. Hint, link and package/link to smallest possible set of libraries would be better. I am not experienced with many things, so this was pretty confusing (can't find -lc --- maybe I'd decipher libc, but -...). 4. -pg is a compiler option, not some external feature implying installation of something There is no other way than to have it as a compiler option, since the compiler must generate special code for it. Similarly, -gv implies that you will use Valgrind, but that does not mean we're going to ship Valgrind with the compiler. No way! I can compile with -gv, I don't have valgrind, compiler/linker do not complain. PS. 1. Well, I don't know whether it's really .exe with valgrind support, because I had issues [and reported them], for example, with external assemblers: compile successful, application [otherwise working] immediately fails.) 2. I have already reported: -gd causes access violation by compiler (still in 2.0.3 2006.4.20). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[9]: [fpc-pascal] fpc and intel vtune (now about gprof)
for libgdb.a needed for our IDE as well). OTOH, if we ship gprof.exe, we should probably ship the needed libraries and vice versa, it doesn't make too much sense as it is now... By the way: I don't use IDE (it is not handy due to many issues that are not bugs), but when I tried, it completely freezes (it worked before upgrade to 2.0.3 2006.4.20) after pressing mouse button (winxpsp2, both fullscreen and window modes). If someone can acknowledge, please submit it as a bug. Why did I write it? Because I don't have libgdb.a (neither did I with 2.0.2). In my school days compilers had something like filelist.txt in bin directory. (Neither Delphi7, nor VC7 [which I don't use, but checked for this feature] do have such a file.) I believe, that something like this is not very useless. For example, if you use command line zip and unzip, older versions shipped with FPC can do harm (like many other utilities, assembler included). It would be great to know what utility is needed and what for (and a little hint for not shipped ones, like libc.a discussed). Nothing lengthy, just like cygwin1.dll part of CYGWIN ver. 1.5.12, ___for FP (IDE), GDB, GPROF and ...___ dlltool.exe part of GNU binary utilities, ver. 2.15.91, 20040904, __for PPC386 (Compiler) on linking stage___ Of course, such a thing can slightly help even developers. Some hints for older versions that are required would be great (when newer version has incompatible command line parameters, for example). The reason: user (I) can already use newer version and it can be in search path... PS: compiler mentions dlltool bug with short var names (1 character?). isn't this bug corrected in newer version of dlltool? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[11]: [fpc-pascal] fpc and intel vtune (now about gprof)
But the result is useless without Valgrind (no more useful than a regularly compiled binary at least), just like compiling with -gd is Jonas Just as compiler without a linker. What about user friendly filelist I mentioned? (Now that I know why and how cygwin is needed, I'll install it and look at the files to save and files to delete... I didn't find easy to install cygwin libraries pack.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[11]: [fpc-pascal] fpc and intel vtune (now about gprof)
Yes. Hint, link and package/link to smallest possible set of libraries would be better. I am not experienced with many things, so this was pretty confusing (can't find -lc --- maybe I'd decipher libc, but -...). The compiler can also generate code for e.g. FreeBSD,Darwin and Linux. Should we also deliver all FreeBSD,Darwin and Linux libs? You do it: I can download from FPC site sources and binaries for needed libraries. 4. -pg is a compiler option, not some external feature implying installation of something There is no other way than to have it as a compiler option, since the compiler must generate special code for it. Similarly, -gv implies that you will use Valgrind, but that does not mean we're going to ship Valgrind with the compiler. 2. confusing linker error cannot find -lc with -pg -- well, I can't use gprof without cygwin anyhow (while gprof.exe itself does not use extras except shipped cygwin1.dll) It is not confusing. It is expected that you know what you are doing when using low-level tools like gprof for profiling. Yes. I have already read that The -pg option also links in versions of the library routines that are compiled for profiling (gprof man page). I really didn't think these versions are so external to FPC. But: 1. when cygwin (with binutils) is installed, e.g. libgcc.a may be not installed. 2. when cygwin is installed, you have to copy/make accessible libraries to FPC ld.exe (and cygwin itself has newer version of ld.exe). 3. the packages of cygwin to install for gprof functionality are not obvious 4. archived (libc.a, libgcc.a, libgmon.a, libkernel32.a, libmsvcrt.a and libmoldname.a) use only 200 Kb of space (and I am not sure that all of them are needed). (to the contrast, the single cygwin1.dll uses more than 400 Kb and is shipped with FPC.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] google summer of code?
On 4/27/06, Пётр Косаревский с mail.ru [EMAIL PROTECTED] wrote: 2. Freepascal is too marginal to support. (But I like it.) They support Adium, a instant messenger I had never ever heard about. Also Adium only works on Macs. They also support various other extremely marginal software. I still think they are just disorganized and let anyone get in until they realised they had too many projects and started rejecting the others. Probably you are right. But even that Adium thing has few advantages over FPC: 1. it's goal is easy to understand 2. any computer-unfriendly man is supposed to become able to use it FPC is easier to compare with LispNYC. Which, in turn has its advantages (like being close to huge american city). And about too many projects: they can reject students. Well, it's a pity anyway. And only an insider can help to both understand the reason and participate next time (good advices should be enough). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] writing to dynamic array via formal parameter; what is the right way
I use something like var a: array of byte; setlength(a,TheSize); blockwrite(afile,a[0],TheSize); Of course, if it is possible that TheSize=0, I have to write if TheSize0 then blockwrite(...); Is this the intended way? (Ok, that's not a big overhead, but it seems strange to me.) What is the intended way (if it's somewhat different)? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] rotating bits
Is there high level operator/(inline)function for rotating bits? Am I supposed to implement rotating bits (like ror/rol in i386 asm) by inline assembler or some ugly workarounds (shifts and or-s)? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
On 24 mei 2006, at 10:56, Пётр Косаревский wrote:
Is there high level operator/(inline)function for rotating bits?
No.
Am I supposed to implement rotating bits (like ror/rol in i386 asm)
by inline assembler or some ugly workarounds (shifts and or-s)?
Yes. I think there's already a feature request to provide these
operations, but no one worked on it yet.
Jonas___
Why don't use this code?
{$INLINE ON}
interface
{$IFDEF CPUI386}
function brol(b: byte; c: byte): byte; assembler; inline;
function wrol(w: word; c: byte): word; assembler; inline;
function lrol(l: longword; c: byte): longword; assembler; inline;
function bror(b: byte; c: byte): byte; assembler; inline;
function wror(w: word; c: byte): word; assembler; inline;
function lror(l: longword; c: byte): longword; assembler; inline;
{$ELSE}
function brol(b: byte; c: byte): byte; inline;
function wrol(w: word; c: byte): word; inline;
function lrol(l: longword; c: byte): longword; inline;
function bror(b: byte; c: byte): byte; inline;
function wror(w: word; c: byte): word; inline;
function lror(l: longword; c: byte): longword; inline;
{$ENDIF}
implementation
{$IFDEF CPUI386}
function brol(b: byte; c: byte): byte; assembler; inline;
asm
movb b,%al
movb c,%cl
rolb %cl,%al
movb %al,result
end ['al','cl'];
function wrol(w: word; c: byte): word; assembler; inline;
asm
movw w,%ax
movb c,%cl
rolw %cl,%ax
movw %ax,result
end ['ax','cl'];
function lrol(l: longword; c: byte): longword; assembler; inline;
asm
movl l,%eax
movb c,%cl
roll %cl,%eax
movl %eax,result
end ['eax','cl'];
function bror(b: byte; c: byte): byte; assembler; inline;
asm
movb b,%al
movb c,%cl
rorb %cl,%al
movb %al,result
end ['al','cl'];
function wror(w: word; c: byte): word; assembler; inline;
asm
movw w,%ax
movb c,%cl
rorw %cl,%ax
movw %ax,result
end ['ax','cl'];
function lror(l: longword; c: byte): longword; assembler; inline;
asm
movl l,%eax
movb c,%cl
rorl %cl,%eax
movl %eax,result
end ['eax','cl'];
{$ELSE}
function brol(b: byte; c: byte): byte; inline;
var s,r: byte;
begin
s:=c and $7;
r:=byte(b shl s);
r:=r or byte(b shr (8-s)); // c may be over 8 and should be processed
correctly
brol:=r; // result is not supported in inline procedures
end;
function wrol(w: word; c: byte): word; inline;
var s: byte; r: word;
begin
s:=c and $f;
r:=word(w shl s);
r:=r or word(w shr (16-s)); // c may be over 16 and should be processed
correctly
wrol:=r;
end;
function lrol(l: longword; c: byte): longword; inline;
var s: byte; r: longword;
begin
s:=c and $1f;
r:=longword(l shl s);
r:=r or longword(l shr (32-s)); // c may be over 32 and should be processed
correctly
lrol:=r;
end;
function bror(b: byte; c: byte): byte; inline;
var s,r: byte;
begin
s:=c and $7;
r:=byte(b shr s);
r:=r or byte(b shl (8-s)); // c may be over 8 and should be processed
correctly
bror:=r;
end;
function wror(w: word; c: byte): word; inline;
var s: byte; r: word;
begin
s:=c and $f;
r:=word(w shr s);
r:=r or word(w shl (16-s)); // c may be over 16 and should be processed
correctly
wror:=r;
end;
function lror(l: longword; c: byte): longword; inline;
var s: byte; r: longword;
begin
s:=c and $1f;
r:=longword(l shr s);
r:=r or longword(l shl (32-s)); // c may be over 32 and should be processed
correctly
lror:=r;
end;
{$ENDIF}
Comments:
I. style/consistency
I didn't use all needed {$if}s: current code should word with range
checks on both on i386 and not.
{$Asmmode} was not used either.
First symbol denotes type: while shl/shr emit longword, cyclic shifts
shouldn't
Endianness is not supported, because I don't understand, why it should be.
II. performance
Result is not supported in the inline mode.
I don't know how to use ret to achieve the same goal with fewer
commands.
Test:
{$INLINE ON}
program testb;
uses commonthingies;
var i: byte;b: byte;w: word;l: longword;
begin
write('Enter byte (dec):');readln(b);
for i:=0 to 16 do
writeln('Orig:',binstr(b,8),' Left:',binstr(brol(b,i),8),'
Right:',binstr(bror(b,i),8));
write('Enter word (dec):');readln(w);
for i:=0 to 32 do
writeln('Orig:',binstr(w,16),' Left:',binstr(wrol(w,i),16),'
Right:',binstr(wror(w,i),16));
write('Enter lw (dec) :');readln(l);
for i:=0 to 64 do
writeln('Orig:',binstr(l,32),' Left:',binstr(lrol(l,i),32),'
Right:',binstr(lror(l,i),32));
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] rotating bits
I don't know how to use ret to achieve the same goal with fewer commands. Well, if I get it right (and it works on my system), the last lines: movb %al,result etc. (6 times) should be commented out. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] rotating bits
With register calling convention (which is the default calling convention in FPC 2.x), it can be reduced just to: function brol(b: byte; c: byte): byte; assembler; inline; asm rolb %cl,%al end; (and similarly for all the other functions). The first parameter goes to eax, the second to ecx, and the result is supposed to be in eax again. Tomas Well, I am jealous of your knowledge of the calling conventions. Did you notice, that in default compiler mode mov %al,result does not work? Anyway, why don't introduce these functions? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] rotating bits
With register calling convention (which is the default calling convention in FPC 2.x), it can be reduced just to: function brol(b: byte; c: byte): byte; assembler; inline; asm rolb %cl,%al end; (and similarly for all the other functions). The first parameter goes to eax, the second to ecx, and the result is supposed to be in eax again. Tomas Did you test it? It does not work for me (one-liner). (result line does not seem to be needed, but calling conventions used seem to be somewhat different). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
But the problem with ROR/ROL is that any real use over shr/shl uses a hard to model carry flag? Ugh, I don't understand well, but the talk is about rotating bits, no low level features like CF are requested (it doesn't mean very much if you rotate by several bits). Who talked about CF? I didn't talk about RCL/RCR either. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] rotating bits
Well, if we're going in that direction anyway: Why not include all possible assembler instructions then ? Because some of them are not designed for calculations. But ror/rol are. Let's be serious. You must draw the line somewhere. I think these instructions are so exotic, they are pollution of the system unit. Michael. They are widely used in encryption/decryption algorithms. Unfortunately, I don't really know why they were introduced in 8086 assembler. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] a suggestion...
bzip2 has similar compression rates (except maybe for multimedia files, which isn't the case) and 7zip/LZMA usually compresses better than RAR. 7zip isn't installed by default in any distro AFAIK, but at least it open source. RAR would be my last option... I tried to benchmark a little. Archivers were limited to 512 Mb. Timings only in the second test. Precision is kept 1 Mb/10 seconds intentionally. There are many comprehensive benchmarks, but I tested nearly the last versions. OpenOffice 2.0.2 sources, 1209 Mb (there are several .gz and other binary files inside). (RAR and 7z had the advantage of managing files themselves to create solid archives, gzip and bzip2 were used on a 1209 Mb ball made by RAR.) Rar (3.60 beta 2): 212 Mb gzip (1.2.4): 276 Mb bzip2 (1.0.3): 230 Mb 7z PPMd (4.4.2):190 Mb 7z LZMA (): too slow (~100 Kb/s, more than three hours) After that I tried to compress FPC SVN (153 Mb), and the numbers were in different order (FPC ball was created in 2 minutes by Rar): Rar 21 Mb 5 minutes gzip29 Mb 1 minute 30 seconds bzip2 20 Mb 3 minutes 40 seconds (is it optimized for pascal?) 7z PPMd 17 Mb 8 minutes 20 seconds 7z LZMA 16 Mb 25 minutes (well, it would be better, I believe it had memory problems) I tried PPMonster archiver (open source, from the author of PPMd algorithm), while sources are less than 60 Kb in C, speed is often about 20 Kb/s. However, it promised 0.548 bits per byte of the FPC ball (but 1.5 for OpenOffice). Naturally, there is still no good reason to change something. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] real to integer
The problem is that Apple's universal interfaces also include a round function, which returns a real instead of an integral type. How can one find such a thing himself without trialerror? Some time ago I had a similar problem with bool DeleteFile(PChar) function in Windows API and sysutils function DeleteFile(string):boolean. Good program: uses windows,sysutils; const B:shortstring='1.txt'; begin DeleteFile(B); end. Bad program: // Error: PChar expected uses sysutils,windows; const B:shortstring='1.txt'; begin DeleteFile(B); end. While compiler gives a hint about true declaration, it does not point to the problematic unit. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] real to integer
The compiler already gives unit information in case you have conflicting types for making it easier to debug such problems. I don't see why it shouldn't do the same for used function definitions. Jonas program A; // Bad program uses sysutils,windows; const B:shortstring='1.txt'; begin DeleteFile(B); end. Last compiler messages (-va): (all dependencies, path searching etc are before) Searching file 1.pp... found (A)Load from A (implementation) unit WINDOWS 1.pp(3,1) (A)Parsing implementation of 1.pp 1.pp(4,19) Error: Incompatible type for arg no. 1: Got ShortString, expected PChar Hint: Found declaration: DeleteFile(PChar):LongBool program C; uses windows,sysutils; const B:shortstring='1.txt'; begin DeleteFile(B); end. Last compiler messages: Searching file 2.pp... found 2.pp(3,1) (C)Parsing implementation of 2.pp 2.pp(2,13) Hint: Unit windows not used in C I got nice hints: Load from A (implementation) unit WINDOWS and Hint: Unit windows not used in C. While the second hint helps me to understand, that if I wanted to run deletefile() from windows, I failed, I don't understand how to read first bunch of messages (there are lotsa Load from A ... messages). Of course, if I use any function from windows unit, I don't get Hint: ... not used This is fpc-pascal maillist, I don't insist, that I can read good. Where from had I to get my hint? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[5]: [fpc-pascal] a suggestion...
Correction: Rar produced 212 Mb on OO 2.0.2 sources, but using force text compression makes it produce 206 Mb with not really big time overhead. Then try one of the last compressors as PAQ8, your OO 2.0.2 sources will take days in compress, but i think you can get 140-150 MB or even less and is opensource too. But it isn't used out of First thing: I did neither think or believe, I just tested. Well, my benchmarks concerned bearable timings and memory requirements: no more than two hours and 512 Mb. I didn't test archivers, which were not mentioned in the thread (exception: PPMonstr, which actually was only an example of compression world only compressor). comp.compression world. Also, the WinRK3.03 is a lot faster and gets a bit more compression, but only works on windows. The tar.gz of All four archivers tested by me work under many systems (bzip2, gzip, rar, 7z). I believe, paq8h has only minor problems porting. Rar is commercial, but it has good GUI (well, I use it and I like it) and is supported and developed continuously (and my benchmarks showed, that its compression ratios under given circumstances are not so good: losing to 7z is due to dictionary size: rar uses no more than 128 Mb of memory, but losing to bzip2 on fpcSVN is freaky). http://www.maximumcompression.com/ for details and the newsgroup comp.compression or datacompression.info for more info. Oh, you forgot www.compression.ru :) Didn't you pay attention, that the these sites didn't test sources? (And www.compression.ru has really outdated benchmarks :( ) Just change the gzip to a better zip program for make zip files, as 7z, and you'll get an improvement from current compression, but the Gzip does not produce zip files. It just uses deflate algorithm. bzip2 suggestion is very good, even FreeBSD has changed the tar.gz system to tar.bz2 (tbz) and the difference is notable. Yes. And it uses only about 8 Mb memory. (But my test showed, that it loses 8.5% on OO 2.0.2 sources to Rar. And more than 11.5% with force text compression in rar.) WinRK is unacceptable, because it is not only commercial, but runs only under windows. While Rar offers command line support under several linuces and unrar support under many systems. AND WHILE ITS COMPRESSION ENGINE MAY BE GOOD, it simply does not work well (e.g. 3.0.3 b2 tells, that trial period has expired right after installation). IT'S PROGRAMMED BADLY. Paq8 may be good, because it's open source and free. (By the way, if I get it right and speak it out very roughly, it is PPMd based with some dictionary improvements and other tweaks added.) But it's incredibly slow (in PPMonstr's category). I understand, that experimental archivers are sometimes optimized for Calgary Challenge (not because of luaghable money prizes, but because of some sort of fame), so it's not that great for compressing OO 2.0.2 or FPC sources. Benchmarks addendum (FPCsvn): WinRK --- requires tweaks to run and may crash at many moments (GUI problems?). Could it be useful, High profile would be applied (512 Mb). And it would be too long (as 7z in LZMA mode). Paq-8H (on a rar ball): too long... Well, bzip2 or 7z do seem most efficient. Nothing has changed. Probably, this thread is useless: if the developers find some time, they will use bzip2 or something they like. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] a suggestion...
To save your time, you should limit your tests to: It doesn't take much human time. 1. Command-line tools. Creation of installs is automated. GUI tools cannot be used in automated builds. 2. Completely cross-platform. For obvious reasons. 3. Completely Open source. For obvious reasons. 4. Compress time should be definitely less than 10 minutes. Sometimes we do 4-5 builds one after the other. We simply cannot afford to wait 2 hours, and we never know whether the next build will be the final one. Any solution that falls outside of this is not acceptable in advance. Michael. From first message: 1. rar,7z, bzip2+tar/bzip2+? (I used rar to create ball), gzip+tar/gzip+? (--) it depends on script writer 2. nothing is completely cross-platform, but all the four archivers provide executables (sources are great, but executables do work) for a good deal of platforms/systems (7z disclaims that executables are official). 3. 7z, bzip2, gzip 4. ??? well, if the thing is not bigger than FPCsvn directory, they fit. You didn't mention memory requirements. However, bzip2 is already great for FPC-sized installs. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] overflow checking
Just a question about programming practice:
How can I disable overflow checking for a couple of operations?
I use something like that:
{$DEFINE CHECKINGS}
{$IFDEF CHECKINGS} --- of course, this block can be much bigger
{$R+,S+,Q+,V+}
{$ELSE}
{$IMPLICITEXCEPTIONS ON}
{$R-,S-,Q-,V-}
{$ENDIF}
...
a:=b+c;
{$Q-}
e:=f+g;
{$IFDEF CHECKINGS}
{$R+,S+,Q+,V+}
{$ELSE}
{$IMPLICITEXCEPTIONS ON}
{$R-,S-,Q-,V-}
{$ENDIF}
h:=i+j;
etc
So I have many lines overhead each time.
Generally I try to disable checkings for bigger blocks, but it is somewhat lame.
Is there an easier way?
Like
{$SAVE Q} {$Q-} e:=f+g; {$LOAD Q}
so that it will fit one line?
I know, that I can split {$IF} block:
{$Q-} e:=f+g; {$IFDEF CHECK_OVRLW} {Q+} {$ENDIF}
Is this a better practice?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] overflow checking
Thank you for advices!
Probably, I'll stick to global definitions.
It seems, that {$IFOPT} doesn't help conserve space when you have to switch
checks somewhat often, while greatly helps write code fragments for injection.
(A line starting with {$Q-}, then simple expression, ending with some {$IFDEF
..}...{$ENDIF} sequence seems more readable to me than a company of extra lines
or beginning with {$IFOPT}/{$IFDEF}: fewer symbols for eyes to make through.)
From: Vinzent Hoefler [EMAIL PROTECTED]
Well, if you do define CHECK_OVERFLW depending on the current compiler's
settings like this:
{$IFOPT Q+} {$DEFINE CHECK_OVRLW} {$ENDIF}
then ...
{$Q-} e:=f+g; {$IFDEF CHECK_OVRLW} {Q+} {$ENDIF}
... this looks like one of the easiest ways.
Well, my practice is to use more lines, so that the instruction(s) in
question don't get hidden by all the compiler-directives surrounding
it.
From: Alexey Pavluchenko [EMAIL PROTECTED]
{$IFOPT Q+} {$Q-} {$DEFINE Q_SWITCHED} {$ENDIF}
(* do some stuff here *)
{$IFDEF Q_SWITCHED} {$Q+} {$UNDEF Q_SWITCHED} {$ENDIF}
May not fit in one line though :)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Code example needed, please!
A friend of me wants to write a program which uses a GUI frontend and a backend, which actually does the work. The reason is that the backend shall also be usable from the command line, without any GUI, to make it working on more platforms without having to make changes on it. So it will be the best to compile it in FPC for the related OS, with a minimum of OS dependices. My idea is to write the backend in FPC. It shall only use StdIn/StdOut and also parse its command line options. The Frontend shall be - in a first step - be written in Delphi or Lazarus, but because I ask here for a friend who currently uses Delphi, this would be preferred. My question is: Can somebody show me a little sample program for that? Well, I have written such a program (Delphi-FPC) not very long ago. I can't provide it as an example (and it is not very little), but I can describe necessary steps and provide code bits. It will be enough (for the Delphi-part) to open a window with a textbox and a button. When the button is clicked, the backend shall be loaded, some text be piped into it, and that what comes out from the backend's stdout shall be displayed in the textbox. Nothing more. The backend may be a plain FPC program (no delphi), reading from StdIn, making i.e. everything to UpperCase, then write this out to its StdOut. If somebody, please, could show me how this is done in Windows, please? Ing. Rainer Hantsch Shame on me, but I have given up using pipes. They are not reliable in my opinion. I used (of course, you can use command line parameters and files: frontend creates param.txt, runs backend.exe param.txt and waits for output.txt to be created; no need to keep in mind something system specific) windows messages (and you have to create invisible dummy window for backend) and shared memory. For your example it's possible (but it is windows specific) for frontend: to create shared memory in frontend, zero the first byte of it and start backend (with parameters, if needed). When the button is pressed, the needed parameters and data are written to shared memory and after that frontend flips the switch (changes the first byte from zero to something else). After that the frontend periodically inspects that first byte value, and when the value is zero again, reads the output from shared memory. for backend: to open shared memory (file), periodically inspect the first byte, read the parameters and data when the first byte becomes nonzero, process them, write output, change the first byte, close everything and die. If it suits your needs, I can point you to the sources in the net and/or provide my code bits. PS. I wanted to rewrite ipc unit for windows, so that this task will become less system specific, but didn't succeed: not enough time and confidence*experience; also I don't really know, how it works under linux. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] RE: Nice website
This will move the menu's to the left. I am no graphics artist, but I think it looks better on the right. Regards, - Graeme - Yes, website looks new and polished. I personally prefer darker-softer colors that were there before, but it is definitely great, that someone does change the design: it makes the website alive. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] Code example needed, please!
From: Пётр Косаревский[EMAIL PROTECTED]
To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org
Subject: Re[2]: [fpc-pascal] Code example needed, please!
I have code only with window messages and shared memory (if you don't want
it, tell; otherwise I'll post some about an hour later).
I used something like that for shared memory in Delphi
ShMemFile is THandle, ShMemBuf is Pointer.
ShMemFile := CreateFileMapping(
INVALID_HANDLE_VALUE, -- this creates file somewhere in
memory or swapfile
nil,
PAGE_READWRITE,
0,
ShMemSize, -- set what you need
ShMemName); -- this name will be used by the backend too!!
try to make it unique string, you can set it as command line parameter for
backend
if (ShMemFile=0) or (ShMemFile=INVALID_HANDLE_VALUE) then
begin Application.MessageBox('Shared memory error 1.','Internal
error',MB_OK); Close(); end;
ShMemBuf := MapViewOfFile(ShMemFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);
if (ShMemBuf=nil) then
begin Application.MessageBox('Shared memory error 2.','Internal
error',MB_OK); CloseHandle(ShMemFile); Close(); end;
{}
ShMemP:=ShMemBuf;
Where ShMemP is pointer to array[0..ShMemSize-1] of byte, so that you can
address bytes as ShMemP^[x] (somewhat lame).
And in the backend:
The types of ShMemFile and ShMemBuf are as in Delphi
ShMemFile := OpenFileMapping(
FILE_MAP_ALL_ACCESS,
false,
ShMemName);
if (ShMemFile=0) or (ShMemFile=INVALID_HANDLE_VALUE) then
begin writeln('File open failed!'); ASS_BACK(MsgFileReady); end;
ShMemBuf := MapViewOfFile(ShMemFile, FILE_MAP_ALL_ACCESS, 0, 0, 0);
if ShMemBuf=nil then
begin writeln('File open failed!'); ASS_BACK(MsgFileReady); end;
ShMemBytes:=ShMemBuf;
Where ShMemBytes is byte pointer (so you address bytes as ShMemBytes[x]).
This code creates one chunk of shared memory of ShMemSize size. I used about
64K. Probably, anything up to gigabyte will work, but may be slow.
All these functions are described in MSDN, the only thing not nice is that you
have to guess some default values and pascal types (it's the same in Delphi
help: the examples are in C, if I remember right).
If you plan sending window messages, I can send some working code (ask). There
are examples (for Delphi) in internet on sites like
http://delphi.about.com/od/windowsshellapi/l/aa093003a.htm.
Of course, all the functions are described in MSDN.
There are simple hints: the window handle is Application.handle (you can send
it to backend, so that the dialog will not be broadcast from the beginning,
also you have to write message hookers in both programs [and create dummy
window in FPC one], if you want them to not freeze for some time, use the
functions windows.peekmessage, windows.postmessage, windows.translatemessage,
windows.dispatchmessage; if I remember right, one of them could have name
conflict with something in another unit).
If you want some little fun, broadcast WM_KILL message.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] inline assembler procedure
Currently you cannot inline assembler routines, it is a known restriction. I didn't get this one message. If nothing else, you can skip the stack frame generation using nostackframe keyword. Not that it would help that much probably... Tomas Oh, well. Thanks for the answers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] national support
What other details should I give for somebody to give me advice. I guess this might be enough for somebody to try - I personally have absolutely no idea what kind of charset is used/expected when printing via Write(Ln) to Lst under Windows, but this shouldn't be difficult to check? Do I understand it correctly that the screen output is OK now (as opposed to your original post)? Tomas Some of these matters were discussed before in maillist related to crt garbles writeln output (http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg05224.html is one of the messages). There was a patch for that (not this) problem from Maxim Ganetsky, which can help to understand things. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Offline documentation for Extra Packages
These are Pascal interfaces to C packages. In general there is no Pascal documentation available. However, since they are straight translations the C documentation should apply almost literally to the Pascal versions. Jonas Is there a note/memo about types mapping? There should be some issues (I remember some return values in Delphi were boolean in straight translations, while there were three different meaningful return values in C). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] minor sysutils question under win32
Why does sysutils use CharUpperBuff() user32.dll function instead of CharUpper(): it does not check the return value? (last 2.1.x SVN) --- By the way: (from MSDN regarding CharUpper()) Return value...There is no indication of success or failure. Failure is rare. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Finding the cursor in the IDE
Yes, it is a problem. I often have problems finding the cursor in the IDE. I stopped using IDE after acquiring LCD monitor because of this feature. It does not use lines longer than 132 symbols even when started in console mode with such dimensions (WinXP-sp2, FPC 2.0.4rc2, I like using 160 symbols wide lines). And it's CYGWIN dependency makes me make some efforts to make freshly compiled 2.1.x IDE run (so I avoid it). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] variant part of a record
Yes, you do. :) Nevertheless some_type = record case Something : byte of 1: (x,y: word); 2: (z: longword); end; Thank you, Jonas and Vincent, but I was vague: what I want is blockread'ing, so I have to use record Something: byte; case byte of 1: (x,y: word); 2: (z: longword); end; Or use classes/properties (virtualization of structure: reading into memory, processing there, checking in run-time that data is accessed legally [if needed]). Should I? Is there less abstracted approach? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] variant part of a record
Vinzent H?fler Probably you should used a packed record, though. And it's
in no
Vinzent H?fler way portable, of course.
Also correct.
Jonas
I use
{$A-}
abc= record
something: byte;
case byte of
1: (a,b: byte);
2: (c: word);
end;
{$A+} // or even a: byte; rsrvd1: array[1..3] of byte; b: word; ...
{$IF sizeof(abc)1234}
{$FATAL Неверный размер записи для заголовка (sizeof(abc)1234).} // I think,
there is no need to translate:)
{$ENDIF}
because I read binaries generated by other programs. So it's mostly portable:
if it was supposed to be really portable, I'd add endianness checking.
What am I thinking of is a construction like
xyz= object
raw: abc;
function GetA: byte;
function GetB: byte;
function GetC: word;
property something: byte READ raw.something;
property a: byte READ GetA;
property b: byte READ GetB;
property c: word READ GetC;
procedure GetData(...); // obtain data for the first time, writes to the
'raw'
end;
function xyz.GetA: byte;
begin if something=1 then GetA:= raw.a else
Show_Fatal_Error_Message(Fatal_Error_ID); end;
function xyz.GetB: byte;
begin if something=1 then GetB:= raw.b else
Show_Fatal_Error_Message(Fatal_Error_ID); end;
function xyz.GetC: word;
begin if something=2 then GetC:= raw.c else
Show_Fatal_Error_Message(Fatal_Error_ID); end;
But it's somewhat bulky (in the case of many types), so I hoped there is a
language feature for my convenience (I don't know pascal very well and didn't
understand corresponding documentation in the one way).
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] variant part of a record
Yes, there is a language feature called object orientation. But still that means you would have to translate the binary structure into a class instance somehow. Vinzent. The object I presented compiles well, but there is almost no gain in OO approach: I still have to nest structures and write lots of properties, inheritance does not help. I'm vague: for the first time I hoped that when you access the variant part, if the case variable was named, program checks it run-time. Hoping that it was implemented this way, I asked about control over the relative place in the memory of that named variable. Oh, well, there are no run-time checks, so that's all... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] variant part of a record
It's on my todo list to implement such checks (when enabled by a command line switch, of course). It's not that easy as it may look at first sight though. Jonas It's great news! However, in the case of such checks, ability to explicitly place tag variable in the record structure or to place something after the variant part (assuming it has the size of the biggest branch) would be great too. Implementing else seems very logical (does modula-2 perform this checks?). I wish you all the best. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[6]: [fpc-pascal] variant part of a record
That would be more easily doable than the above, though again it would break compatibility with other Pascal compilers afaik. Jonas I thought so. But FPC isn't very compatible as it is: if you don't care for compatibility much, Delphi won't compile a program. Of course, TP will fail too. It may be active in ObjFPC mode only. Hacking the parser to support this directly is a waste of time imho (not to mention that it would break the code's compatibility with every other Pascal compiler out there afaik). More specifically, it adds feature and does not break backward compatibility. Otherwise, the same as above. As you saw, nested records and properties already solve the problem, but with bulky and not very internal albeit transparent methods (pun). In any way, it's you (one of those), who exert influence upon the FPC, not me. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[8]: [fpc-pascal] variant part of a record
It's not because you don't pay me, or because you cannot demand anything from me or anyone else working on FPC, that you do not have influence on the project or even on what I do (both positively and negatively). Jonas If I get it right, I don't have the influence, mainly because I don't contribute. Are there other reasons? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] variant part of a record
About contributing: is it useful to comment some parts of documentation (html with comments) with improvements, corrections or compilable examples? It's not because you don't pay me, or because you cannot demand anything from me or anyone else working on FPC, that you do not have influence on the project or even on what I do (both positively and negatively). That was a difficult sentence. I think I understood it after reading three or four times. I *think* all he said was: Even if you don't pay me, even if you cannot demand anything from me, you still can have an influence on the project or on what I do. Vincent Well, I think, that the part It's not because you don't pay me ..., that you do not have influence on the project ... means, that I don't have direct influence on the project (it's right: I did not submit a bug for much time, and the last thing I did was writing some list of problems with 2.0.4rc1). Of course, it's not a robot of Jonas, who writes to the maillist, so I have some indirect influence (at least by entertaining, boring or wasting time of someone; I hope, that Florian reads maillist only when someone tells him, that there is something important there). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] variant part of a record
About contributing: is it useful to comment some parts of documentation (html with comments) with improvements, corrections or compilable examples? For example, would it be meaningful to add an example on the discussed matter with a comment stating, that there are no such checks tonow? - That's everything but motivating to even bother replying the next time you post something, since all one gets back is mails in which you basically say but I'm just wasting your time and you don't really care about what I say anyway. And this is another fine example of the above. Jonas Maybe it's better to reply only on the meaningful part? You may regard my moaning as a cookie or an origin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Threading support under FPC
Hi, How good is the threading support in Free Pascal? I'm using 2.1.1. I haven't used threading before under FPC and am about to revamp an in-house application to support mutliple threads. I don't want to start the app and then find out that there is some major stability issues with threading support. Anybody find issues with FPC's threading support? Any special params that I need to pass to the compiler? Regards, - Graeme - If it didn't change recently, thread priority doesn't work under Win32 (you can change the property, but it has no effect). And I was told, it could be possible to use WinAPI SetThreadPriority etc manually. (It appeared that I didn't really need it, so I didn't check it.) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] RE: Threads executing in sequence instead of parallel
I would first port one or two of the top 10 threading applications that was submitted to Borland in a Threading Contest which Borland held in 2002. Search Borland's CodeCentral or I could post the link. There are some good threading examples available. :-) I have troubles searching. Please, post the link (to the list of rated submissions or something). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Last missing benchmark: regex-dna
Although fpc has a regexpr unit: http://svn.freepascal.org/svn/fpc/trunk/packages/base/regexpr/regexpr.pp It has many todos, such as adding support for | in the search expression. So this unit doesn't have enough functionality. While '|' support is to be considered basic regex functionality, what is the really expected functionality? Basic seems to be: |()?*+ (non-UNICODE) support (from wikipedia). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Last missing benchmark: regex-dna
Basic seems to be: |()?*+ (non-UNICODE) support (from wikipedia).
| is not basic afaik. From re_format BSD Manpage:
Obsolete (``basic'') regular expressions differ in several respects. `|'
is an ordinary character and there is no equivalent for its functional-
ity. `+' and `?' are ordinary characters, and their functionality can
be expressed using bounds (`{1,}' or `{0,1}' respectively). Also note
that `x+' in modern REs is equivalent to `xx*'. The delimiters for
bounds are `\{' and `\}', with `{' and `}' by themselves ordinary
characters. The parentheses for nested subexpressions are `\(' and
`\)', with `(' and `)' by themselves ordinary characters. `^' is an
ordinary character except at the beginning of the RE or= the beginning
of a parenthesized subex- pression, `$' is an ordinary character except
at the end of the RE or= the end of a parenthesized subexpression, and
`*' is an ordinary charac- ter if it appears at the beginning of the RE
or the beginning of a paren- thesized subexpression (after a possible
leading `^'). Finally, there is one new type of atom, a back
reference: `\' followed by a non-zero deci- mal digit d matches the
same sequence of characters matched by the dth parenthesized
subexpression (numbering subexpressions by the positions of their
opening parentheses, left to right), so that (e.g.) `\([bc]\)\1'
matches `bb' or `cc' but not `bc'.
You know the traditional Unix syntax, I quoted wikipedia's definition of basic
regex, and it looks like a simplified POSIX ERE (extended regular expression)
syntax ( http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html
).
I've got the idea.
The last missing benchmark requires simplest bracket expressions like [agt]
(equiv. to (a|g|t))). Bracketing is supported in FPC regexpr enough.
Also it requires substitution (find and replace all) of a regex in a string,
which has nothing to do with regex standards.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Last missing benchmark: regex-dna
Then there is also synregexpr.pas: http://svn.freepascal.org/svn/lazarus/trunk/components/synedit/synregexpr.pas But that is not distrubuted with fpc. And I don't know, if the license is open source. Is it looks likes a BSD derivative, but item 3, about income, doesn't seem to fit in. How should this benchmark be implemented? Vincent What about contacting author of synregexpr and asking him to implement it? He seems to live in the same city as me, so if the e-mail address is a dead-end (both web links are broken), I can try to contact him another way (and pursuade him to resolve this issue). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] size of long on different platforms
On Tuesday 14 November 2006 22:28, Jonas Maebe wrote: There's a unit called ctypes in the rtl with all these types defined (prefixed by c, i.e. cshort, cchar, clong, ...) Why does rtl-documentation (http://community.freepascal.org:1/docs-html/rtl/index.html) lack its description? (it mentions 36 out of 48 base rtl units if I get it right) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] size of long on different platforms
Why does rtl-documentation
(http://community.freepascal.org:1/docs-html/rtl/index.html) lack its
description?
(it mentions 36 out of 48 base rtl units if I get it right)
Some units are difficult do document and require some qualification.
In the case of ctypes, I ran fpdoc.exe --output=1.1 --package=rtl
--input=ctypes.pp (of course, it generates isolated bunch of html files),
added between p and /p in 'index.html':
This unit defines types equivalent to common types in C programs. Most names
are easy to understand: they are slightly abbreviated C names with ttc/tt
or ttpc/tt (pointer type) prefix./p
pttspan class=codea href=../ctypes/cint.htmlcuint/a/span/tt,
ttspan class=codea href=../ctypes/cuint.htmlcuint/a/span/tt and
ttspan class=codea href=../ctypes/csint.htmlcsint/a/span/tt
types are 32-bit wide./p
pCurrently (11.2006) only 3 type-definitions depend on processor architecture:
ttspan class=codea href=../ctypes/clong.htmlclong/a/span/tt,
ttspan class=codea href=../ctypes/cslong.htmlcslong/a/span/tt
and ttspan class=codea
href=../ctypes/culong.htmlculong/a/span/tt are either 32 or 64 bits.
And it looks acceptable (it required one glance over tiny ctypes.pp).
The only other thing needed is providing c-names of the types in the types list
('index-3.html' file, I can write them and send the file if needed).
That's somewhat lame, but not so bad: by the way, fpdoc fails with unhandled
exception if the file name is wrong. Is it error enough to be submitted?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] freepascal.org
whatever else? Thanks. well. DaniКl How should one submit bugs with website? Mantis does have website bug category, but I suspect (from your maillist activity level compared to mantis\bug response), that you don't get all the messages fast enough. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] freepascal.org
-Original Message- From: Пётр Косаревский [EMAIL PROTECTED] To: Jonas Maebe [EMAIL PROTECTED] Date: Mon, 27 Nov 2006 13:22:14 +0300 Subject: Re[4]: [fpc-pascal] freepascal.org We get all the submitted bug reports immediately. That does not mean that they are handled immediately. When exactly something gets handled simply depends on a lot of human factors. Jonas I got it. Yes, Daniel Mantione is (I looked at the Mantis changelog) there too, sorry. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[3]: [fpc-pascal] freepascal.org
The your report about the incorrect count of translated messages is DaniКl You simply answer maillist questions so fast, that I became suspicious, that you didn't receive a bug submitted to the Mantis. I understand that there are many things to do with website, and I don't think, that website troubles are more important, than e.g. fpc dll-s in delphi ones. Sorry for extra disturbance. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] freepascal.org
is there a way to always get the english version of the site when I open www.freepascal.org in my browser, independnetly of my current locale and my IP address and whatever else? Thanks. Alexey It seems, that many browsers have languages settings button, but work differently. While Opera processes languages list from that settings right (e.g. if English is the first, www.freepascal.org will load in English, if Russian --- than in Russian), IE works otherwise: it seems, that (at least on some systems) you have to remove all settings from the list except the desired. I don't know about other browsers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
