Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Tue, 26 Feb 2008, schreef Luiz Americo Pereira Camara: Yury Sidorov wrote: The patch removes packed record for some platforms. IMO packed can be removed for all platforms. It will gain some speed. I'd like to understand more this issue. Why are non packed records faster? Cache trashing. One of the most underestimated performance killers in modern software. The difference occurs at memory allocation or at memory access? Memory access. What happens is that the non-packed version causes more cache misses. A cache miss costs many cycles on a modern cpu, a misaligned read just costs an extra memory access (which is fast if cached) on x86, and extra load instruction on ARM. This much cheaper than a chache miss. It's much worse than that. Some architectures simply _can't_ do unaligned access, and they will trigger an exception. This exception will in many configurations be caught by the OS, that then might simulate the read by doing 2 reads, putting the result together, writing into the application memory, and doing a task switch. This, in total, is several _orders of magnitude_ worse than unaligned access on a supported platform. Of course, unaligned access in itself is pretty bad. -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode resourcestrings
Martin Schreiber wrote: On Friday 29 February 2008 09.02:02 Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Martin Schreiber: Hi, Is there a way in current FPC to have unicode or wide resourcestrings? Thanks, Resourcestrings are ansistrings, so the answer is no. This is indeed a shortcoming in a widestring environment, the only solution is probably to encode them UTF-8. This works with utf-8 system encoding only - not in an usual Windows installation. Are there plans to implement unicode resourcestrings? There is a non-ambiguous UTF-8 to UTF-16 mapping. It should be no problem at all, except for the extra programming effort. -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Memory access. What happens is that the non-packed version causes more cache misses. A cache miss costs many cycles on a modern cpu, a misaligned read just costs an extra memory access (which is fast if cached) on x86, and extra load instruction on ARM. This much cheaper than a chache miss. It's much worse than that. Some architectures simply _can't_ do unaligned access, and they will trigger an exception. This exception will in many configurations be caught by the OS, that then might simulate the read by doing 2 reads, putting the result together, writing into the application memory, and doing a task switch. This, in total, is several _orders of magnitude_ worse than unaligned access on a supported platform. Of course, unaligned access in itself is pretty bad. True, but irrelevant, because the discussion was under the assumption than an unaligned read is done using the unaligned pseudo function. Unless there is a bug in the compiler, the use of unaligned will never cause an exception. Oh, you're right of course. I didn't catch that part of the argument. Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. Unlike modern x86 processors? Granted, I haven't timed it, but most processors since early P4 models are supposed to have Streaming access detection, which is a fancy way of saying array detection. Are you sure your information is current? (I could be wrong too, of course) -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Patch, font rendering on Arm-Linux devices.
Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Daniël Mantione wrote: Op Fri, 29 Feb 2008, schreef Christian Iversen: Instead unaligned will simulate an unaligned load with two loads and some rotation etc. On the ARM, where every mnemonic can rotate operands, this is isn't that bad of a penalty. Therefore, I wouldn't be surprised that even on ARM, arrays with packed structures are faster than arrays with unpacked structures. That's possible. Why would it be faster, btw? Better cache coherency? Like I mentioned, unliek modern x86 processors, ARM processors cannot detect an array traversal and preload the array into the cache. If the array is not in cache, you get cache miss after cache miss. Unlike modern x86 processors? Granted, I haven't timed it, but most processors since early P4 models are supposed to have Streaming access detection, which is a fancy way of saying array detection. Are you sure your information is current? Please read again. I said modern X86 processors have, ARM processors don't have. Sorry, it's just really not my day today.. ;-) I'll now go join another discussion without reading it properly, in turn annoying even more people.. :-) -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Freepascal in microcontrollers
Andrew Haines wrote: Can freepascal be used on small processors that are 8 or 16 bits or does it expect that there are at least 32 bits for most things? I've been tempted lately to start making little circuits with microcontrollers on them. I realize that a great deal of the rtl/fcl would not be used on these little processors. Also since there is no OS on these devices does that mean that for sure fpc cannot work? Most of the RTl is written for 32- and 64-bit computing, as you correctly state. I would imagine that _some_ of it would work on 16-bit, and maybe 1-2% would work on 8-bit ;-) However, you can choose to compile fpc without the system unit, using a special option on the command-line. This would enable you to code your own system routines (such as writeln), most likely in assembler. However, the most obvious problem here is that (AFAIK) fpc does not support arbitrary 8- and 16-bit targets. You need to find an architecture that fpc supports, so you can compile programs for it. Other people on this list probably know more about embedded systems than I do, so I hope someone else can answer with the specifics. -- Med venlig hilsen Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Michael Van Canneyt wrote: On Wed, 18 Jul 2007, Marco van de Voort wrote: On 18 Jul 2007, at 14:08, Jonas Maebe wrote: Install the IDE setuid. That would be an extremely bad idea with the current stability record of the IDE. Not to mention that it allows you to open and overwrite any arbitrary file. Yes. Just like we all have for decades. And no, it is not ideal, but apparantly that is what the kernel devels want as the only way to access the full terminal capability. You cannot distribute a tool which creates a security hole as large as from here till Tokio. That would not look good the day it is discovered, and arguments like the kernel forcing us to do so will not help us then. It just means you'll have less functionality. How does midnight commander solve it? As far as I know, it also has strange keyboard combinations ? Sorry for joining the discussion so late, but what special key combos are we talking about? And what changed in the kernel? I agree that it does sound absurd to require root privs - and of course it goes without saying that the IDE _cannot_ under any circumstance be distributed to run as +s, it just cannnot happen, period. These privileges that we are talking about, are they transferrable between processes? In that case, we could write a small setuid wrapper to setup the terminal, then exec the IDE without privs. Under any circumstance, if there really isn't any New And Improved way to do this sans root, we should bring it up on the kernel mailing list. I can do that, if need be - I'm always quite interested in security matters. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux kernel behaviour change regarding keyboard
Ales wrote: And to add to my last setuid stuff.. I think that if we properly audit the IDE code so that: a) fpc is called in the uid of the original ide starter b) the console is run in the uid of the original ide starter c) compiler programs are called in the uid of the original IDE starter I think it's ok to use setuid after these. Ofcourse, depending on how the IDE executes all the externals, it might be a trouble. But if we do some typical fork, it shouldn't be so difficult (I'm willing to do this should we decide to go this route). There is absolutely no clean way to use setuid in a program the size of the IDE. Trust me. It is vaguely possible that a very small (think less than 100 LOC) wrapper could be generated, which will simply set certain configuration parameters of the PTY that the IDE is attached to. I imagine that this would work. This could be distributed, and called from the IDE after startup. The entire IDE would then be run completely as normal, by the user. Even with such a small wrapper, one would have to put a big fat warning in the README file and similar places. In the Debian package, debconf should ask the user if s/he is ok with installing a suid program. If this is not feasible, then the IDE will have to be redistributed with reduced functionality. You just cannot compromise when it comes to security matters. Ever. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] language extensions
Michael Schnell wrote: We already have the generics can the preprocessor symbols. That leaves the for in. The development team has its doubts about the for in construct, but: * Andreas did it in a reasonably clean way with a lot less hacks and ugly constructions than Delphi did. * The pressure on us is increasing to have a for in. AFAIK, Chrome does extended for in or similar stuff. I'd vote for using a meta-compiler or other pre-processor instead. I think the preprocessor is already doing too much, and not in a very nice way. If we were to rewrite the preprocessor so that it wouldn't actually be a preprocessor, but a built-in meta-compile stage, that would be good. Then we could do strict syntax- and semantic checks on the preproc statements. Right now there are all kinds of errors that can happen in specific circumstances. -- Regards Christian Iversen (who actually worked on the fpc preproc) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strings: a proposeal
On Sunday 04 February 2007 01:01, peter green wrote: currently there is some demand for a fast widestring type on windows and i suspect there will be requirements for more string types in the future. During the creation of our project, Technetium (www.technetium.dk), we designed a string library that would incorporate support for not only widestrings, but also ansistrings, utf-8 strings, mbcs, etc - and not by compiling to different types, but at the /same/ time. My programming partner, Ivo Steinmann, has done a truly excellent job implementing and perfecting this string library. If used right, it's also faster than FPC's internal strings. We'll discuss licensing options, and try to see if we can make ready a public source collection for testing. The source is directly compatible with FPC in objfpc mode, and should even be /somewhat/ compatible with delphi, if you remove the operator overloading. These overloaded operators does make the library /much/ easier to use, though. Is anyone interested in testing this? -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type question
On Saturday 14 October 2006 15:55, Marc Weustink wrote: Hi, if I define 2 types like: type MyA = type string; MyB = type string; are MyA and MyB considered as the same type ? No, you are explicitly marking them as a new type. This is a very cool feature of Pascal you wont find in many other languages. (For instance, you could use it to create a new integer-type for little- and big-endian numbers, ensuring that you _never_ directly assign a little-endian number to a big-endian one, or vice versa) Should it be allowed to assign a variable of type MyA to a variable of type MyB ? No. IIRC, the use of = type some type creates a new type. That's right. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type question
On Saturday 14 October 2006 17:38, Peter Vreman wrote: On Saturday 14 October 2006 15:55, Marc Weustink wrote: Hi, if I define 2 types like: type MyA = type string; MyB = type string; are MyA and MyB considered as the same type ? No, you are explicitly marking them as a new type. This is a very cool feature of Pascal you wont find in many other languages. (For instance, you could use it to create a new integer-type for little- and big-endian numbers, ensuring that you _never_ directly assign a little-endian number to a big-endian one, or vice versa) For the compiler the types are not equal anymore, but they are still compatible for implicit type conversion. This has mainly impact on overload choosing and parameter passing. Normal assignments using ':=' are not affected because of the still available implicit type conversion. I really feel there should be a way to make two types completely incompatible. How exactly does the compiler figure out the rules for implicit conversion? In the case of wrapper integers in records, are 4-byte records handled as efficiently by the compiler as 4-byte integers? I suspect it's some radically different code that handles it. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Monday 02 October 2006 11:46, Ales Katona wrote:
Having same function names as parameter names per se isn't a biggy but
the biggest problem is:
TFirst = class
protected
FFirst: Integer;
public
property First: Integer read FFirst write FFirst;
end;
TTest = class(TFirst)
FSomething: Integer;
public
procedure DoWithFirst(a, First: Integer);
end;
implementation
procedure TTest.DoWithFirst(a, First: Integer);
begin
First:=a; // ???
FSomething:=First; // ???
end;
Ales, there is _no_ confusion here. Normal scope rules ensures that the first
line only assigns the param a to the param first. There are no other ways
to interpret that.
The second line assigns the param First to the private field FSomething.
Again, no problem at all.
Ofcourse the intention was setting FSomething to value of argument First
and setting FFirst to value of First. It CAN be achieved with FFirst
or self.First but it's just a stupid example of how easily you can
overlook things especialy if some parts are hidden in another unit
somewhere in an ancestor.
This is very much less of a problem in practice, I believe.
Really, perhaps what we would like to check, is that there are no fields of
the same name, _with_a_compatible_type_? That would give warnings that are
much better, and still allow (non-method-pointer) parameters in one method to
be named the same as another method.
Wouldn't that make more sense?
Also notice that in mode delphi there's not a single warning about this.
True - because it's OK to do this. There are no warnings about all sorts of
other normal behaviour either :)
And believe me things like this CAN happen and will take you 3 days to
find out...
I name my arguments aName since this incident and not because
{$objfpc}...
Ok.
PS: there are worse cases but I can't remember a better example now
Let me know if you remember them :)
--
Regards,
Christian Iversen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
On Monday 02 October 2006 19:20, Micha Nelissen wrote: Christian Iversen wrote: procedure TTest.DoWithFirst(a, First: Integer); begin First:=a; // ??? FSomething:=First; // ??? end; Ales, there is _no_ confusion here. Normal scope rules ensures that the first line only assigns the param a to the param first. There are no other ways to interpret that. This is a weak argument. Suppose this were not true, then the language would be ambiguous (or the semantics undefined)! That would be really really bad. And people are not robots you know, following, knowing and applying rules like an exact grammatical rulebook ;-). I think I might have misunderstood Ales's argument :) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Language extension: absolute for classes
On Saturday 30 September 2006 12:23, Marco van de Voort wrote: I realize that this is only a 'saving-typing' language extension, but it does save significant amounts of typing and would make the code more readable (IMHO). You can achieve the same with generics ? Specialize a class with T=G ? Something similar can also be done with interfaces (but in this case, generics is probably a cleaner way to do it) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Suggestion for change: Overly strict check
Hi all. I was hoping there could be a discussion of a certain feature in FPC, which doesn't work very well for us. Ultimately, I would like to see it gone completely. It's a very small extra-strong syntax check, appearantly implemented to avoid bad code. However, it's not entirely obvious why this is supposed to help. Please consider this example: type tfoo = class(tbar) private public procedure Frob(); procedure Wait(delay: integer); procedure ReadStuff(buffer: tbuffer; wait: boolean); end; When declaring classes or interfaces, it is specifically checked that the names of methods are NOT the same as _any_ variable name of _any_ other method in the class. This means that the example above will NOT compile. Now, in Delphi mode this check is not performed, and so the code above will compile without problems. The reason for keeping this check, as far as I know, is that it's supposed to lead to better code. For instance, in the body of ReadStuff(), the identifier wait could be potentially confused between the boolean parameter, and the procedure(delay: integer) of object;. At least, that's the theory. Of cours, if the parameter wait was a function (delay: integer) of object, there could be some confusion. This is very rare, however - and you have to be careful anyway, because this restriction is not consistent: var wait: boolean; procedure tfoo.ReadStuff(buffer: tbuffer; wait: boolean); begin // In here, wait could refer either to the parameter, or the global var. end; However, it's not confused with the global var, because standard scoping rules apply. Same as with inner functions and such. Also, if you have a unit foo, with a variable bar, you can use foo.bar to refer to that specific var. However, foo.bar could also refer to the local record foo with the field bar. Again, standard scoping rules solve this problem without incident. The _real_ problem, however, is that with these very strict checks we essentially only have one namespace for each class/interface. All function names, parameter names AND local variable names share ONE namespace, with the one exception that no check is performed between functions. We have several examples where good, standard names are used for functions, and then cannot be used in local variables - this is even though they could never be confused in any realistic scenario. We urge you to rethink the introduction of these checks. It's making it tremendeously difficult for us to change our code to objfpc mode, and removing it would not break a single line of code anywhere. We have to rethink quite many variable and/or function names, because many good names are already taken. This is, in effect, making our code quality slightly worse overall. What are your thoughts on this? -- Regards, Christian Iversen, Ivo Steinmann ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linking problem
On Sunday 24 September 2006 11:02, Ivo Steinmann wrote: Ivo Steinmann wrote: Hello all I tried to link libmodplug.so but get this error: /usr/lib/libmodplug.so: undefined reference to `operator new[](unsigned int)' /usr/lib/libmodplug.so: undefined reference to `operator delete(void*)' /usr/lib/libmodplug.so: undefined reference to `operator delete[](void*)' /usr/lib/libmodplug.so: undefined reference to `operator new(unsigned int)' do I have to link another library also (something like libstd) or is there a way that I can define those function in my application? Im a littlebit confused about operator I found my own solution (and that's working for linux here). But I dont know if it's a bad idea to do it. linking libstdc++ leads to other problems here, so I cant do that. Flawless and me have got a unit that implements some parts of stdlibc++, so I took the functions above from this lib. [...] now it compiles and works without any problems. What do you think? dangerous? crazy? I don't think so. Since every call to new _must_ be matched by a call to delete, we can be sure that there are no special functions for clearing a pointer. If you think it's a good idea, I would like to add a unti called fpcstdcpp or something like that. This unit defines other things also, like fdiv, etc... I like it, that's why I made the original unit :D Really, many things can compile with just a few simple functions (like those you used here). Maybe we could use littlelibcpp.pas as a base for fpstdcpp.pas? -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linking problem
On Sunday 24 September 2006 19:52, Micha Nelissen wrote: Ivo Steinmann wrote: now it compiles and works without any problems. What do you think? dangerous? crazy? If you think it's a good idea, I would like to add a There is no difference on the ABI level of 'new' and 'new[]' ? I think the reason there are two different operators, is because the names are mangled differently for consistency (because it _could_ very well have been important if it's the array version or not) Of course, this makes it possible to try and use an array-optimized memory allocator for the []-cases. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The implements keyword
On Sunday 06 August 2006 11:12, Martin Schreiber wrote: On Sunday 06 August 2006 02.39, Christian Iversen wrote: Finally I got some spare time for coding. So, after quite a bit of help from Florian (Thank you!), the implements-keyword is well, IMPLEMENTED! Finally! Great, thank you very much! I really like this feature. Do method resolution clauses (procedure interface.interfacemethod = implementingmethod) work too? Yes I'm almost sure that works too - although I didn't make it. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The implements keyword
On Sunday 06 August 2006 12:12, Florian Klaempfl wrote: Christian Iversen wrote: Finally I got some spare time for coding. So, after quite a bit of help from Florian (Thank you!), the implements-keyword is well, IMPLEMENTED! Finally! It's not yet in trunk, but it will be soon. As far as I can tell, it's completely hack-free, but I will submit the revisions as patches for code review. The code is still not complete, and there are some needed changes that will happen when I can find the time (for instance, what's the procedure to add new compiler messages? should I just add them to errore.msg?) Yes, at the appropriate place. Then run make msg in fpc/compiler and commit the changed msg*.inc files as well. Ok, I'll do that. The current version of the patch adds 2*sizeof(pointer) to each TInterfaceEntry. That might seem like a lot, but with bitpacking this can be brought down to just 1*sizeof(pointer). Now, to make the bitpacking I need to be able to assume VMT's are always aligned to at least 4-byte boundaries. I think this is a safe assumption, but maybe it's not? Well, when compiling optimized for size it isn't I fear. It would really save a lot of space if we could just agree to always align VMTs to 4-byte boundaries. Trying to pack them together actually hurts the size, in the case of interfaces. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The implements keyword
Ok, so now it IS in trunk. It works with fields assignments (virtual and static interface-proxy methods are not yet supported) There's a few debug statements left in as comments, but those will be removed soon. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abstract functons with parameters on classes
On Thursday 27 July 2006 17:49, ik wrote:
Hi all,
Is there a way to do the following ?
...
{$MODE OBJFPC}
type
TA = class
public
function fnc : Boolean; virtual; abstract;
end;
TA2 = class (TA)
public
function fnc (const a : Boolean) : Boolean; override;
end;
...
Maybe the overload keyword works between classes? I don't know, I haven't
tried it yet. You could.
--
Regards,
Christian Iversen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] space char inside identifier's name
On Saturday 25 March 2006 10:50, Bisma Jayadi wrote: WWWHHH! *Falls off chair* *grabs desk* *pulls up* Clear enough ? ;-) Same respond when the first time I knew that file name is case-sensitive in un*x-like OSes (Linux, etc). It looks silly and ridicilous (especially for M$ users), but most people still use it (the users like it even more). :P But this is a lot more silly. There's \ everywhere! -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] space char inside identifier's name
On Saturday 25 March 2006 11:19, Bisma Jayadi wrote: Foo a.bar a := baz b[4].foo q You made a very excessive example. Of course we don't HAVE TO use space char all the times. I won't use it that way either. But it's there when we really want/need it. Can you please make an example where we _need_ it? :-) is harder to read! It's not the char itself, it's that it's used all over the place whenever this is used. I don't like it. Maybe you don't like it and that's alright. This feature won't harm you in any ways. But some other people could demand it in some circumstances. That's not true. I have to work with the code other people produce, and this is a huge step towards making that code potentially unreadable. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] procedure Types
On Saturday 04 March 2006 10:09, Amir Aavani wrote: I have problem with procedure Types. Look at the following code: TProcedure= procedure (S: String); TTest= class MyF: TProcedure; procedure F1 (S: String); procedure F2 (S: String); ... end; TTest.constructor ; begin MyF:= @F1; end; it says it can't cast Procedure (S: String); Object to TProcedure. The problem is clear but I don't know (can't find) any solution to define TProcedure as a procedure of a class which accepts one argument. You have declared MyF as a TProcedure, so this is just not going to work. Try this instead: type TMyFProc = Procedure(S: String) of Object; ... MyF: TMyFProc; ... that should work. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Web language
On Sunday 05 February 2006 19:25, VisionForce wrote:
On Unix platforms, you don't need to do anything. Just use
read/write functions to communicate with the world around you.
On Windows, you need to define that you are not working with a GUI
program, which you do like this:
{$APPTYPE console}
I think that is with Delphi.
Isn't freepascal the opposite, where in fact command line mode is
default
and you must explicitly specify app type of GUI if you want a GUI?
Oh, I thought the original question was about Delphi - one of the recent
questions were :)
Oh it might have been - I guess it depends on his decision to use fpc or
delphi? :)
Which should I use when creating a server-side web language?
I'd recommend FreePascal, no doubt about it. It would be perfect for the job.
(Not that delphi would be bad, but I'd say it's biggest strength is GUI
design)
--
Regards,
Christian Iversen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Web language
On Monday 30 January 2006 00:07, VisionForce wrote:
Okay, I know this is a beginner questions, but how do I create a Pascal
program that only reads the text and sends it through some sort of CGI
thing (i.e. doesn't pop up that DOS-style window/shell). I already know how
to do the CGI part, I just need to know how to make a program without a
user interface.
On Unix platforms, you don't need to do anything. Just use read/write
functions to communicate with the world around you.
On Windows, you need to define that you are not working with a GUI program,
which you do like this:
{$APPTYPE console}
Other than that, there are no explicit requirements.
--
Regards,
Christian Iversen
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PR: What sites to spam for 2.0.2 release?
On Wednesday 07 December 2005 23:33, Daniël Mantione wrote: Hi guys, Speaking of PR, we have a 2.0.2 to announce within a very short time and we better do it well. We won't be able to do a Slashdot or OSnews announcement, nevertheless we should take these opportunities to promote FPC. So, any ideas what sites we should spam? I'm looking for developer focused sites. Pascal/Delphi related sites are welcome, but remember we are already quite famous in that world. We need generic open source related sites. We need to send more messages to the general Delphi community. I didn't know FPC well before I tried kylix, and heard about it as an alternative to that. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
On Thursday 17 November 2005 13:18, Alexander Todorov wrote: Hi folks, can you tell if there is a good crypto class for FPC / Lazarus ? What do you use for crypting your stuff ? Any opinions are welcome. I'd go for openssl. I know we have to implement crypto support at some point in Technetium, and I'd really look into that library. It seems well-developed. Writing a new, safe, crypto lib is _hard_. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cryptography class nedded ?
On Thursday 17 November 2005 14:04, Paul Davidson wrote: Did some work getting SSL working for FPC. Attached is unit that exposes most of the functions required. Tested with Darwin and Linux. Thank you! That's a great starting point. I'll look at it when we are implementing crypto :) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Wednesday 16 November 2005 13:57, Florian Klaempfl wrote: Daniël Mantione wrote: Op Wed, 16 Nov 2005, schreef Vincent Snijders: Daniël Mantione wrote: What should be done on Linux/FreeBSD/MacOS is still unknown to me, it is a wild west, but likely something similar, internally a widestring rtl is used that converts to the right encoding when communicating externally. Does that mean string operations will be twice a slow? I don't think so. A string copy operation for a wide string needs to move twice as much data as a string copy operation for an ansistring. However, when walking through it, (take the widestring version of pos for example) the amount of work per character does not change. Modern CPUs are memory bandwidth limited usually so widestrings a lot slower. But still, only if the string operations are a bottleneck. That might not be the case. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics Basics
On Tuesday 08 November 2005 21:33, L505 wrote: Hello, I am trying to understand what exactly generics are. I read the wiki page, but there are lot's of code examples and very few explanations. Can someone explain it to me in a (relatively) simple way? What problem is it trying to solve? And how do generics relate to interfaces? I had the same problem for a few years. It took me a few months/years to first diagnose what the fudge templates/generics actually were, and what problem they exactly solved. All the information about generics is pretty non-real world and non-case study on the internet. It is also hyped by programmers who again seem to show no real world or case studies. But I can see how they can be useful in theory, nevertheless. I'm not going to give you a technical explanation on what they are, because someone else can do that (and I don't have experience with generics, so I'm not qualified to do so). Here is a vague non-technical explanation: Basically generics helps you save some Typing and syntax in your units. You can address several things at once with the same Type. Supposedly, this encourages code reuse. You can address and create things via a shortcut syntax sort of way. The Very Big Advantage (Tm), is that you get syntax checking, while still using a type diversely. That's impossible to do (at compile-time) without generics. Probably the best example of this is something like TList: Without generics: TOrange = class ... end; TApple = class ... end; var T: TList; begin T := TList.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // Whoops, what was that? Now our program might crash. end; Of course, we could create a specialized TAppleList that only accepts Apples, but that's boring and hard work. A much cleaner way is generics: var T: TListTApple; begin T := TListTApple.Create(); T.Add(TApple.Create()); T.Add(TOrange.Create()); // This wont compile! The problem is prevented at compile-time! end; I hope that answers your question as to why it's a good idea :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Friday 04 November 2005 10:33, Vinzent Hoefler wrote: On Friday 04 November 2005 09:25, Micha Nelissen wrote: Marc Weustink wrote: If the generic is precompiled (which is maybe necesary if you need access to privates) then I fear some runtime logic has to be added to call the correct procedure. IE. something like case TypeInfo(Data) of StringType: Show(Data); IntegerType: Show(Data); end; The whole idea of Generics is to avoid this :-) At user level, yes. But as a compiler-writer you'd gotta make it work somehow. Yes, somehow, and not like that ;-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] {$DEFINE x := something}
On Thursday 30 June 2005 21:34, Florian Klaempfl wrote: Christian Iversen wrote: On Thursday 30 June 2005 20:15, L505 wrote: I've always wanted to find the most compact and readable font myself. Just never spent the time looking. Well today I did a bit of searching, and found some fonts that are more compact than at least Courier New http://z505.com/cgi-bin/qkcont/qkcont.cgi?p=Compact-Readable-Fonts Save about twice as much screen space if you just choose the right compact font. Courier new seems to waste a lot of space between lines. Clearly, the only right choise is FixedSys :-) Yes and a console IDE :) It does 120x70 easily :) Hehe, sounds sweet ;-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fast ascii upper/lowercase
On Saturday 11 June 2005 20:38, Daniël Mantione wrote: Op Sat, 11 Jun 2005, schreef Christian Iversen: With all the discussion about speed of lowercase/uppercase recently, I thought I'd chip in. I don't have the time to actually implement and test this, but I hope somebody else will. This semi-pseudocode should be a bit faster than what is currently done: function lowercase(const value: string): pchar; var X,L,C: Integer; B: Char; begin C := length-of(value); set-length(result, C); for X := 0 to C/4-1 do begin L = PIntegers(value)[X]; // Char 1/4 B := char(L and $FF); if (B in ['A'..'Z']) then result[x shl 2] := B or $20 else result[x shl 2] := B; // Char 2/4 B := char((L shr 8) and $FF); if (B in ['A'..'Z']) then result[(x shl 2)+1] := B or $20 else result[(x shl 2)+1] := B; ..etc.. end; ..fix remainging 0-3 chars.. end; Basically, a simple loop unroll, with the twist that the fetch is collapsed to every 4th iteration. This, combined with the dynamic scheduling of modern CPUs, should increase the speed considerably. Since each iteration is very collapsable in terms of data-dependencies, this could work out to be quite fast. I could be wrong, of course :-) Does somebody want to try this? I expect it would be hard to get any speed advantage using this approach, since the overhead of expressions like char((L shr 8) and $FF) is quite severe. I was aiming for a very low level of data-dependencies, which (on modern hardware anyway) can more or less amortize having to do extra calculations. Do not underestimate the power of the force^H^H^H^Hpipelining :-) The real penalty is the expression in ['A'..'Z']. This expression needs two branches which both cannot be predicted by the processer. They depend on the input, the processors branch caches don't help here. You get a pipeline stall in 50% of the cases. This is the reason why a branch-less solution like I posted is so much faster. On older processors, I'd expect you to be right. However, according to the impression I got from the Intel Pentium 4 Optimization Handbook, this is less true for the P4 and similar processors. They do speculative branch calculations for crying out loud! In general, it comes down to what is most expensive: data stalls or branch stalls. You could very well be right - branch stalls are expensive as hell - but I'd still time it to find out. Of course, working with dwords can be a huge advantage, but only if you can process data in parallel or if you are memory bound. At least, this is what I expect and theory and practise don't allways agree. And that's exactly the point. You _can_ process data in parallel. (or did I miss something?). With the ever diverging speeds of CPU and memory, we may or may not be memory bound. I appreciate the input. -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type discussion
Sorry, the only language that does what ? var strlist : TStringlist; strlist := Tstringlist.create; I know strlist is a Tstringlist, the compiler knows it too as I have declared it so why do I have to spell it out in the creation process? In C++: TStringList strlist; strlist = new TStringList; How is that shorter ? okay but its still redundant. Why does the compiler need to have it spelt out twice? Why cant the compiler deduce that as the pointer is declared as TStringlist therefore it creates a TStringList? Because the pointer might not be. Polymorphism, you know? :-) -- Regards, Christian Iversen ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Patch for better Delphi-compatability in preprocessor
Certain Delphi constructs are not yet supported by the FreePascal preprocessor. Therefore, I have written a patch to implement this functionality, so the package Technetium can compile on FreePascal again. The attached patch closes both these bugs: http://www.freepascal.org/bugs/showrec.php3?ID=3683 http://www.freepascal.org/bugs/showrec.php3?ID=3691 If you accept this patch, please give credit as something like this: Patch by Christian Iversen to implement symbolic constants and the IN operator in the preprocessor It seems that the real delphi uses a different approach to parsing expressions in the preprocessor, so eventually this patch will be replaced. However, for now, it helps many projects compile that otherwise wouldn't be able to. -- Regards, Christian Iversen Index: scanner.pas === RCS file: /FPC/CVS/fpc/compiler/scanner.pas,v retrieving revision 1.100 diff -u -3 -p -r1.100 scanner.pas --- scanner.pas 14 Feb 2005 17:13:07 - 1.100 +++ scanner.pas 25 Feb 2005 15:59:00 - @@ -191,7 +191,7 @@ implementation cutils, systems, switches, - symbase,symtable,symtype,symsym,symconst, + symbase,symtable,symtype,symsym,symconst,symdef, fmodule; var @@ -628,8 +628,54 @@ implementation else begin hs:=preproc_substitutedtoken; + +if searchsym(current_scanner.preproc_pattern,srsym,srsymtable) then + begin +case srsym.typ of + constsym: +with tconstsym(srsym) do + begin +if consttyp = constord then +begin + if not assigned(consttype.def) then + begin +internalerror(2005022501); +exit; + end; + case consttype.def.deftype of +orddef: + begin +if torddef(consttype.def).typ in [u8bit,u16bit,u32bit,u64bit, + s8bit,s16bit,s32bit,s64bit, + bool8bit,bool16bit,bool32bit] then + str(value.valueord, read_factor) +else if torddef(consttype.def).typ = uchar then + read_factor := char(value.valueord) +else + read_factor := hs; + end; +enumdef: + begin +str(value.valueord, read_factor); + end; + else read_factor := hs; + end; +end else if consttyp = conststring then + read_factor := upper(pchar(value.valueordptr)) +else + read_factor := hs; + end; + enumsym : + str(tenumsym(srsym).value, read_factor); + else +read_factor := hs; +end; + end +else + read_factor := hs; // Symbol not found + preproc_consume(_ID); -read_factor:=hs; +current_scanner.skipspace; end end else if current_scanner.preproc_token =_LKLAMMER then @@ -638,6 +684,18 @@ implementation read_factor:=read_expr; preproc_consume(_RKLAMMER); end + else if current_scanner.preproc_token = _LECKKLAMMER then + begin + preproc_consume(_LECKKLAMMER); + read_factor := ','; + while current_scanner.preproc_token = _ID do + begin + read_factor := read_factor+read_factor()+','; + if current_scanner.preproc_token = _COMMA then + preproc_consume(_COMMA); + end; + preproc_consume(_RECKKLAMMER); + end else Message(scan_e_error_in_preproc_expr); end; @@ -701,18 +759,24 @@ implementation begin hs1:=read_simple_expr; t
Re: [fpc-devel]Patch: Support for $LIBPREFIX, $LIBSUFFIX, and $EXTENSION compiler directives.
On Monday 02 August 2004 09:17, Michael Van Canneyt wrote: On Sun, 1 Aug 2004, Christian Iversen wrote: The following patch is tested, although only on linux. It supports the (at least for me :) long-awaited LIBPREFIX/SUFFIX support. It also cleans up scanner.pas a bit, by renaming some turbo_scannerdirectives and directive_turbo to common_scannerdirectives and directive_common. This closes a number of bug reports, although my own one is the only one I can find at the moment. (Can somebody do a fulltext search in the bugreports?) Thank you. I have applied the patch, but I reverted back to the old turbo_ names. I assume Peter Vreman or Florian Klaempfl chose these names are for a reason. I closed the bug report. I'm sorry, I completely forgot to say I talked to Florian on #fpc - he approved the new names. turbo_* was left over from some old code. -- Regards, Christian Iversen ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]Patch: Trivial cleanup in gdp.pas
Please find attached a trivial cleanup patch that removes a non-effective statement. -- Regards, Christian Iversen Index: gdb.pas === RCS file: /FPC/CVS/fpc/compiler/gdb.pas,v retrieving revision 1.19 diff -u -3 -p -r1.19 gdb.pas --- gdb.pas 20 Jun 2004 08:55:29 - 1.19 +++ gdb.pas 30 Jul 2004 20:06:18 - @@ -182,9 +182,6 @@ N_BINCL to N_EINCL inherited create; typ:=ait_stabs; -if current_module.modulename^='NCNV' then - current_module:=current_module; - str:=_str; if do_count_dbx then begin
