Re: [fpc-devel] -Oodfa
Florian Klämpfl wrote: Am 30.12.2011 02:00, schrieb Martin: Florian wrote at http://bugs.freepascal.org/view.php?id=20907 c:\fpc\svn\compilerfpc ..\tw20907 -vw -Oodfa Is that documented somewhere ? Is that production read or beta? Beta. I'am not aware of any missing stuff, but it's mainly untested. Maybe add a nightly testsuite run for it? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Extended type
Florian Klaempfl wrote: Am 19.04.2011 15:18, schrieb Marco van de Voort: You'll need to runtime test for SSE3 though. Since the first generation of athlon64's (clawhammer and friends, socket 751 or so) doesn't have SSE3. For such a relatively expensive operations, one runtime check per function is imo ok even more since it is predicted perfectly after the first run. If the branch history table does not overflow ;-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetMem(SomePointer, 0) nil
Paul Ishenin wrote: 01.03.2011 19:29, Jonas Maebe wrote: That sounds very much like badly written code. For simplicity we had the next code: GetMem(SomeArray, Count * SizeOf(ArrayCell)) if SomeArray nil then DoSomeLogic; DoSomeLogic ... with a Count = 0, right? or was Sizeof(...) = 0? :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
Graeme Geldenhuys wrote: am saying is that in the current released Delphi versions (at least down to D7, probably D6 too) this feature works. The mouse cursor trick using the same Interface behaviour has been in tiOPF code for years, and I think that's where I saw it first. Should FPC be compatible performance timing wise as well? assembly instruction by assembly instruction? That's what you're talking about it's not language compatibility, but performance compatibility. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
Graeme Geldenhuys wrote: same application behaviour and outcome, using the same source code. That's got nothing to do with performance as far as I'm concerned. Because you're a brainless moron. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
Graeme Geldenhuys wrote: a managed code environment with garbage collection. So I guess most developers would expect common out of scope rules apply. When a local variable is defined and you leave that method/procedure, it's out of scope. *picky mode* exactly this is true for FPC as well. But it's a when relation only, not an only when relation. LOL Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need advice for refactoring
Florian Klaempfl wrote: Anyways, why do you want to do the same change twice? Just make it once and merge. In a distributed environment this is more common, like: person B partially pulls (some commits) from person A, and person C pulls from both A and B. Or a diamond where B and C pull from A, and D pulls from B and C. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Need advice for refactoring
Florian Klaempfl wrote: Micha Nelissen schrieb: In a distributed environment this is more common, like: person B partially pulls (some commits) from person A, and person C pulls from both A and B. Or a diamond where B and C pull from A, and D pulls from B and C. Yes, but those are merges of regular commits? True, but the point is that in both cases it's possible that someone merges a specific commit twice. Maybe subversion also handles this case well; I have never tried. One may get the same problem when merging two-way which is necessary with long-lived branches (the branch merges commits from trunk, and later the complete branch is merged back into trunk). Or those branches have to 're-based' (not a real subversion action is it?) but then you can't merge from them anymore. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Delphi/FastMM4/TopMemory speed test
Adem wrote: I did some rough + emprical (i.e. non-exhaustive + non-authoritative) tests with the native memory managers of -- x64 FPC (v2.4.3)/Lazarus (v0.9.29-26670), -- Delphi (2010), So this is 32 bit vs 64 bit? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit loading overhead
Jonas Maebe wrote: Total memory usage barely changes (from 297MB to 299MB). I guess it's no For the compiler use case .. ;-) Perhaps the compiler creates a lot of same sized blocks, while other (smaller) applications allocate many different sizes; say use a lot of different sizes classes. Do you mean to change this in heap.inc or in the compiler startup? 256kB on 297MB isn't much; but if a program has typical memory use of e.g. 3MB it is significant ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit loading overhead
Jonas Maebe wrote: 256kB on 297MB isn't much; but if a program has typical memory use of e.g. 3MB it is significant ;-). They could still change it in their application's startup code. We could also set a different default for the embedded rtl. I think applications using 300MB+ are the exception, not the rule; so it should be other way around. Let the compiler make it bigger. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit loading overhead
Marco van de Voort wrote: In our previous episode, Micha Nelissen said: I think applications using 300MB+ are the exception, not the rule; In absolute numbers: sure. In cases where memory management performance is limiting, they are more likely to be memory intensive apps. How do you know? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unit loading overhead
Jonas Maebe wrote: All applications but the ones that allocate a only few memory blocks (especially in case it's a few small blocks of many different sizes) would benefit from this change, not just apps allocating hundreds of megabytes at the same time (it also helps in case applications maximally use 10MB, but allocate and free a lot of data so the blocks get released back to the OS). Applications allocating a ton of them would obviously benefit more than others. So why 256kb? not 64, 128, or 512kb? Specific apps can change the size according to their expected pattern, the default should be conservative. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Daniël Mantione wrote: Compiler speed can loose from maintainability, but it can also loose from code quality; the performance of your application is probably also worth a lot to you. Does FPC compile significantly faster when using -O- then? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Messages overhead
Daniël Mantione wrote: Op Fri, 16 Jul 2010, schreef Micha Nelissen: Does FPC compile significantly faster when using -O- then? That is irrelevant; for example the register allocator made the compiler slower (initially even 3 times, but we managed to reduce it to a few ten %), but had great effects on code quality. What do you mean with code quality then? I thought performance of the generated code. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] arm embedded cortexM3 unrecognized opcode
Nataraj S Narayan wrote: Hi May I ask why do we need a CONFIG_OABI_COMPAT=y in the kernel to for fpc to work on arm-linux? The fpc target for eabi is called 'armel', the 'arm' target compiles for oabi. Regards, Micha On Wed, Jul 14, 2010 at 3:42 PM, Jeppe Johansen jepj...@kom.aau.dk mailto:jepj...@kom.aau.dk wrote: Well, this is off topic, but ARM is quite a bit backwards compatible. All ARM versions are backwards compatible(if we ignore thumb, which fpc doesn't support anyway) :) Geoffrey Barton skrev: On 14 Jul 2010, at 10:49, Bernd Mueller wrote: Michael Schnell wrote: On 07/14/2010 11:02 AM, Bernd Mueller wrote: ... which could easily be done in gcc btw. ... I'm quite sure that FPC's ASM can compile hex constants (using DC ???) that is not the point. You don't wont to bother with (error prone) hex constants, but want to use the regular assembler mnemonics. quite right! especially with a processor like the ARM, where it keeps, er.., improving its instruction set between each generation of hardware! rgds, Geoffrey Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc content syntax suggestion
Michael Van Canneyt wrote: Well, I don't see the point in learning yet another syntax (however simple If the time it takes to learn the new syntax is less than the time saved modifying and writing documentation then it's worthwhile ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Michael Schnell wrote: unfortunately we are in a realtime system and the priority of thread 2 is set higher than that of thread 1 and thus thread 1 never gets a CPU Priority inversion? Isn't this a problem with any InterlockedC/E? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Threading support and C library under Linux/Unix
Marco van de Voort wrote: Huh? Do stock Linux kernels still support a.out? Since afaik ELF was only added in 1.1.52 ? It's a kernel option to support it. Most distro's choose module here I think? (Autodetect when used) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Specialized Generic for Structures with Abstract Methods
Andrew Brunner wrote: ... then I get C:\Developer\Source\Libraries\Core\uInt64Array.pas(54,17) Error: Forward declaration not solved GStructList$Int64.Empty(var Int64); Please always provide a complete compilable example. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parameters must match exactly?
Florian Klaempfl wrote: ... and one uses normally a function and not a var/out parameter. That also would need a typecast since the function would return a parent class of the real class that was created, but the somehow the callee knows it's a descendent, so needs a cast to get to it (or use the is or as operators or ... etc). This actually proves that a compiler error should also be required for the var/out parameter case as well. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] cmem not aligning memory
C Western wrote: Inspecting the cmem unit indicates the issue is the extra bytes allocated for the count - is this really needed? Or do we have to allocate more bytes for blocks that are a multiple of 8? Do C memory managers guarantee any alignment anyway? Not for SSE (16 bytes) I'm sure, but 8 bytes I don't know. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] GetHeapStatus.TotalAllocated
Nikolai Zhubr wrote: Now, I'm starting to suspect that negative TotalAllocated values just result from doing deallocations in a different thread, which is what my programm actually does all the time. I'll go to make a small test. Maybe it's related to (or the same as) bug 14315? http://bugs.freepascal.org/view.php?id=14315 Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM Backend?
Jonas Maebe wrote: On 17 Nov 2009, at 08:18, Vincent Snijders wrote: If you look at CPU secs, then the factor is 3 at most. What helps the C++ programs most is that they use 4 cores more, the fpc programs are mostly singlethreaded. LLVM doesn't help to solve this (AFAIK). Anyway, the above is an example of what I mentioned earlier (in the quoted text at the top of this message), since it's of course perfectly possible to also write multi-threaded versions using FPC. Not quite, because things have to be part of the language to be able to use them. GCC programs may use OpenMP since it is implemented using pragma's which are part of the language. FPC would have to implement the 'parallel for' ideas and friends for them to be used. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Giuliano Colla wrote: var Pfoo: pointer; foo: any valid FPC Type based Pfoo; or foo: based Pfoo any valid FPC type; . Pfoo: pointer; PBfoo: PByte absolute Pfoo; PIfoo: PInteger absolute Pfoo; I don't see the difference between based and absolute, except order of keywords? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Could FPC add the PLM based construct?
Giuliano Colla wrote: With absolute you need a) to declare an extra type (PByte, or Declaring an extra type is one of those things that make Pascal what it is; declaring before use. whatever), b) to explicitly access the variable through the pointer (PBfoo^ as opposed to foo). But if the variable is an array or a string, So we're talking about saving typing of a '^' ? Explicitly typing a '^' when you're derefencing a pointer makes the code more readable, not less. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Source Code Optimization
Dariusz Mazur wrote: Maybe it is something interesting http://www.linux-kongress.org/2009/slides/compiler_survey_felix_von_leitner.pdf Seems that LLVM doesn't do so well, but not as bad as Microsoft :P. GCC seems to be quite good. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Jonas Maebe wrote: If you'd want to limit the length to 2GB on 64 bit systems. I also don't know whether all 64 bit CPUs support atomic operations on 32 bit entities (for the reference count). Something might be said for compatibility towards 32 bit implementations that the maximum length is the same, but I don't really have an opinion on whether this is actually a good idea (limiting the size for compatibility reason). At least Intel and PowerPC do have atomic operations on smaller sizes. Intel: system programming guide vol 3 section 8.1.1 says byte, word, doubleword, quadword (since Pentium) are all atomic if they are naturally aligned. (word = 16 bits) 8.1.2.2 notes that LOCK is also best to be used on naturally aligned boundaries for 8/16/32/64 bit accesses for best performance. PowerPC: pem64, 2005mar, section 5.1.2 says byte, halfword, word, doubleword (64 bit only) are atomic if they are naturally aligned. (word = 32 bits). lwarx/stwcx still exists on 64 bit implementations. So both guarantee smaller reads/writes are atomic. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Micha Nelissen wrote: Intel: system programming guide vol 3 section 8.1.1 says byte, word, doubleword, quadword (since Pentium) are all atomic if they are naturally aligned. (word = 16 bits) 8.1.2.2 notes that LOCK is also best to be used on naturally aligned boundaries for 8/16/32/64 bit accesses for best performance. Hmm, note: it seems that intel's movq to move quadword (64bit) register (or load/store data) is usable only for XMM/MMX registers, not the regular registers? This would mean there is no atomic load/store for the native sized regular registers (rax, rcx, etc) in x86_64? Is this right? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)
Jonas Maebe wrote: Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8 string 'a' will be 9 bytes long? No, 25 bytes. The plain ansistring 'a' is already 17 bytes on x86_64 platforms today. Is that because of sizeint? Wouldn't longint be long enough? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] time for dumping stacktrace, when using dwarf.
Schatzl Thomas wrote: Improving upon that should be trivial, all reading from the debug input has been encapsuled in the two ReadNext() methods in the file mentioned. It should be easy to make them to read from a (static?) buffer that is filled blockwise; note that a static buffer may give headaches for MT programs, and you are strongly discouraged to do memory allocation during crashes... Allocating that buffer on the stack isn't sufficient? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Hoefler wrote: Suppose, the list items have a property Owner and the iterator calls some method that says Owner.Delete (self); somewhere. How's the compiler supposed to detect that? It can't. In general, all references to the (iterator) list need to be const at this time, but I guess it's impossible to prove whether some reference is a reference to the particular list being iterated. Let alone a function that might be called by an iterating for-in loop. In some languages, this problem is circumvented by creating a copy of the list before iterating the set, but I don't think that this is a viable solution for Pascal (or any compiled language, for that matter). That solution seems too costly to me. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help need for FPC
Михаил Абаляев wrote: Second, using FPC, i've designed my own (open source) tool ARM Pascal http://www.arm-pascal.ru/ http://www.armaide.com/ Suggestion: do not include links that have different target as its text. Thunderbird will mark your email as a scam (probably not your intention). Regards, Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Help need for FPC
Jonas Maebe wrote: A note to people who wish to reply to this person: he is not subscribed to fpc-devel (at list not with the address he posted from), so it's best to CC him. This list is not subscribers-only? (To combat spam?) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ncurses example on arm linux uclibc
Nataraj S Narayan wrote: /usr/bin/arm-linux-uclibcgnueabi-ld: cannot find -lncursesw firework.pp(120,48) Error: Error while linking Add -Fl/usr/br-git-rf/lib, -Fl/usr/br-git-rf/usr/lib or whereever this library is located? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ncurses example on arm linux uclibc
Jonas Maebe wrote: On 23 Oct 2009, at 17:19, Micha Nelissen wrote: Add -Fl/usr/br-git-rf/lib, -Fl/usr/br-git-rf/usr/lib or whereever this library is located? No, -XR/usr/br-git-rf should cause those directories to be searched automatically (but apparently doesn't on Linux). I saw them missing in the link.res that's why I suggested it. I've been cross compiling to x86 uclibc myself successfully ... somehow ;-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote: Von: Micha Nelissen mi...@neli.hopto.org That's why I suggested the use of 'const functions' in other message in this thread. Yes, I read that later on. Is that implemented in FPC? I don't think so; but I think it would be a useful part of the iterator proposal. The iterator case really gives it some strength. If not used by other features it may seem more like a OO-purity thing (although that is not per definition bad) ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Ideally, the compiler has no knowledge at all of specific classes, and a new keyword such as Iterator (or whatever) helps in ensuring that the compiler is not contaminated with knowledge of specific classes or methods. I'm not sure how things are helped by slapping a keyword onto it? If we call the thing a class then it's evil, but if it's called an iterator which is actually the exact same thing as a class, it's fine? Correct me if wrong. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: Because with something like Type MyIterator = Iterator(TSomeResultType,Func1,Func2,Func3); So the place in this list determines its function? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: On Wed, 21 Oct 2009, Micha Nelissen wrote: So the place in this list determines its function? Yes. Just like in an operator... Hmm that's not comparable, for operators it's much more intuitive what to expect as the context is forced, Result := expr op expr; Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Michael Van Canneyt wrote: I see little gain in changing while Something(f) do F.Somethingelse This is not quite equal, it's more like: Start(f); while not Last(f) do F.DoWork; In your case, the function 'Something' must know about a generic F. There are also recursive state problems to be thought about. I guess this is why in the STL an iterator is a separate object on the local stack, but able to iterate through (another) object of the defined type. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature discussion: for-in loop
Vinzent Höfler wrote: Marc Weustink marc.weust...@cuperus.nl: loop you are not allowed to modify the loop variable. In this case I can imagine its not allowed to modify the list. But how's the compiler supposed to know which method modifies MyList and which one does not? That's why I suggested the use of 'const functions' in other message in this thread. IIRC they are also part of C++; const functions are functions that never do an assignment (directly or indirectly) to a member field. Regards, Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] msgtxt.inc and msgidx.inc
Florian Klaempfl wrote: I want really fast building and no external tool calling etc., that's why I still use the text mode ide. Not to forget that msg*.inc not the only auto generated files in the compiler sources: there are e.g. autogenerated register tables and instruction tables so this adds up. make can do dependency checking and not regenerate them unnecessarily, but if they are changed they need to be regenerated anyway to have proper result ;-P. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Errors using generics - what is wrong?
Žilvinas Ledas wrote: Thanks, it works with named type. Is using not named specializations is some kind of not implemented yet part? :) No it's a design choice to more easily reuse separate (but equal) specializations. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Errors using generics - what is wrong?
Tomas Hajny wrote:
Well, the internal error is in any case a bug, so if this appears also
with the latest (trunk) version, a bug report would be useful.
I didn't see an internal error? But a more descriptive message would be
useful ('specialization not allowed in this context' or so?).
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] embedded arm port
Michael Schnell wrote: C can do local (Stack?) volatile variables. This does not seem to make much sense. Why not? You could pass a pointer to this stack variable to another thread which could write to it asynchronously to your thread. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support
Graeme Geldenhuys wrote: MyString := '世界您好'; MyChar := MyString[1]; writeln(MyChar); end. Extracting a Char from a UnicodeString? What's that supposed to do? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 2.3.1 seems a mixed mess with Unicode support
Marco van de Voort wrote: In our previous episode, Micha Nelissen said: Graeme Geldenhuys wrote: MyString := ''; MyChar := MyString[1]; writeln(MyChar); end. Extracting a Char from a UnicodeString? What's that supposed to do? CHAR is a 16-bit wchar in D2009. Simularly, pchar is a pointer to a 16-bits char. (pansichar being the 1-byte one). And if MyChar is declared as a WideChar? Then it does work? Isn't it like assigning a LongInt to an Integer? It might be cut, screwed or stay the same (depending on sizeof(Integer)). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] conversion between types?
Michael Schnell wrote: As FPC (other than Delphi) features a Macro preprocessor, I suppose you can get away without modifying the code. FPC does support macros but not parametrized ones. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] conversion between types?
Michael Schnell wrote: Micha Nelissen wrote: FPC does support macros but not parametrized ones. Any chance to use another preprocessor ? So many choices, eg. sed? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] patch for zipper.pp
Andrew Haines wrote: procedure tfor...@unzipcustomoutput(Sender: TObject; var AStream: TStream; AItem: TFullZipFileEntry; AClosing: Boolean); begin if AClosing = False then begin AStream := TMemoryStream.Create; end Do you mind if I say I think this is a very weird event handler? What is the behaviour? How many times is it called? What does AClosing mean? How do I know I don't have a memory leak? Why an event handler and not a property? A CustomStream property where non-nil means use this stream, if nil then default old behaviour e.g. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [PATCH] patch for zipper.pp
Michael Van Canneyt wrote: The handler is called 2 times: - Once to create the stream (aclosing=false) - Once when the data has been written to the steam. (AClosing=true) Maybe it had been better to create 2 events: - OnCreateStream - OnDestroyStream (optional, if not set the component frees the stream) What do you think ? Yes, that's more intuitive to me. (Also removes the need for that boolean parameter?) Would it be allowed to do processing on OnDestroyStream? Maybe OnDoneStream or so would be even better (since that is what it means I guess, the file in the zip stream has been extracted to the specified stream in OnCreateStream?). In Delphi, in an OnDestroy you normally don't need to destroy the object the event is about? Would it be allowed to re-use the same stream? 1) OnCreateStream - MyStream 2) OnDoneStream - write MyStream to but do not free it 3) OnCreateStream - same MyStream etc...? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Assign Self
Hi,
Are we supposed to be able to assign to Self? FPC accepts the attached
unit, but seems strange to me to allow this?
Micha
{$mode objfpc}
unit selfass;
interface
type
TTestObj = class
procedure TestSelf;
end;
implementation
procedure TTestObj.TestSelf;
begin
Self := nil;
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assign Self
Jonas Maebe wrote: On 11 Jul 2009, at 12:53, Micha Nelissen wrote: Are we supposed to be able to assign to Self? Yes. When would it be used? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assign Self
Jonas Maebe wrote: Note that some hits, like the one in cgbase.pas of FPC, refer to the self parameter of objects, not of classes. ... or a local variable or a field in a record ... Only ones I found are TExpression and TContractForm, but those don't win a readability contest, like below one in which self is abused as a kind of temporary variable of the right type: procedure tcontractform.add; begin self:=tcontractform.create(owner); self.insert.enabled:=true; self.btnregion.enabled:=true; self.showmodal; end; Gives me the creeps, but I guess nothing strange will happen as other people's references to the original Self aren't modified. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Assign Self
Micha Nelissen wrote: procedure tcontractform.add; begin self:=tcontractform.create(owner); self.insert.enabled:=true; self.btnregion.enabled:=true; self.showmodal; end; In this case I guess there is even a memory leak in the sense that Owner is usually Application which is a variable existing for lifetime of program. So although this temporary form is freed eventually it takes up memory until end of program lifetime AFAICS. A temporary variable named LeakedContractForm would have been much clearer then :-P. Or put Self.Free at the end which is even creepier. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] lone property
Marco van de Voort wrote: type myclass = class property doit : integer; end; Does sb know this, and is this a feature? And if so, should delphi mode accept it ? What kind of code does fpc generate when you reference it? :-) I guess you will get a compiler error when referencing it? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Delphi compatibility question...
Maxim Egorov wrote: I guess that the behavior of FPC is correct and expectable. I just try your example in Delphi 7, 2007, 2009 and was amazed. They indeed don't assign anything to the array A. This is a Delphi compiler bug. FPC must not copy delphi compiler mistakes. :) Since the return value is undefined, anything is possible: * calculate crc32 over executable * random value from stack * do nothing at all Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Compiler hint for uninitialized local variable minor mistake
Jonas Maebe wrote: It is not possible to change this in the compiler. The reason is that if we change the first parameter of fillchar from a var parameter (as it is now) into an out parameter (so the hint would not be shown), then the behaviour of the code changes. Wasn't outvar a long wished feature to solve this? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreports
Bogusław Brandys wrote: Can someone assign those bugreports : http://bugs.freepascal.org/view.php?id=13499 and http://bugs.freepascal.org/view.php?id=13518 to proper person ? You must first request to be added as developer before we can assign the bug to you ;-P. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] virtual methods and smart-linking?
martin wrote: for the linker (http://www.freepascal.org/docs-html/user/usersu15.html#x38-450005.1.4) but I have no luck in identifying it... The mail also says that it hasn't been done yet! Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Debugger for FPC
Graeme Geldenhuys wrote: Like I said, I am not very knowledgeable with debugger internals, but I am willing to learn and help. Not having decent debugger support is killing me - and I am clearly not alone, as the thread in the Lazarus The problem is not so much the debugging itself. That is easy. (In linux e.g., couple of lines using ptrace). Most of the work is reading debug symbols and all the various execution formats of various platforms. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Debugger for FPC
Graeme Geldenhuys wrote: And then the same think under Kylix 3. As I said, with Delphi and Kylix such trivial things is a no-brainer. Debugging just works. http://opensoft.homeip.net/~graemeg/kylix_debuging.png Delphi/Kylix also does not have 'absolute', so FPC requires even more features in debugging format also than even K/D. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A note on Mantis issue 13173
Sergei Gorelkin wrote: So maybe ThreadWndProc function and window creation/destruction code in AddThread and RemoveThread procedures should be removed? I've removed it. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A note on Mantis issue 13173
Sergei Gorelkin wrote: Looking at the changes to rtl/win/tthread.inc made in r12761, I see that 'thread helper window' is pretty well unused, as CM_EXECPROC message is never posted to it (grepping rtl sources for CM_EXECPROC shows that). TThread.Synchronize is supposed to use it. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] A note on Mantis issue 13173
Sergei Gorelkin wrote: TThread.Synchronize is supposed to use it. It probably was so a while ago, but the current implementation uses a platform-independent mechanism (TThread.Synchronize is entirely in rtl/objpas/classes/classes.inc). Oops, didn't I write that? Good catch. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode and UTF8String
Jonas Maebe wrote: There are an immense amount of similar examples possible (and if you add operator overloading in the mix, it increases exponentially), and you'd get a huge amount of can't decide which overloaded function to call errors even if the compiler were hacked to take the use of the function results into account. Let the programmer define a scoring function (to be called by the compiler when it has multiple options) that takes two functions and decides which combination is most efficient or whatever ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why is FPC so self-contained ?
Michael Schnell wrote: which system/vendor did you choose? We are going to design some controller boards with Altera Cyclone III FPGAs. The NIOS processor is optimized for this FPGA architecture, is very easily implemented into the HDL design, offers acceptable features How big is the implementation? In LUTs, FFs, BlockRAMs? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Parallel Computing
Michael Schnell wrote: I tool a look at the C code of one of the example projects in the ALIOTH test. Here they seemingly used SIMD vector operations via typedef int This has nothing to do with MT or OpenMP though. GCC can vectorize automatically and takes advantage of SSE. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] GetAppConfigFile
Hi,
Why is there a parameter to GetAppConfigFile? I'd suggest something like:
function GetAppConfigFile: string;
begin
{ first look for user specific config file }
Result := GetAppConfigFile(false);
if FileExists(Result) then
exit;
{ otherwise use global one }
Result := GetAppConfigFile(true);
end;
This would first look for the user version, then for the global variant.
(BTW: instead of Boolean, I would have liked a acLocal, acGlobal better,
it's clearer to read).
Any thoughts?
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Sdf / Fixed maximum line length flexibilization
Felipe Monteiro de Carvalho wrote: function StoreToBuf(Source: String): String; virtual; public +MAXSTRLEN: Integer; If you don't object, this is a bit ugly to my taste. Why not 'FMaxStrLen', and have a property MaxStrLen: read FMaxStrLen ? Looks better to me. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] an observation about GetMem
Peter Popov wrote: Well, if it points to something, then there is space, isn't it? Unless it is clearly mentioned in the documentation that GetMem(p,0) results in You get a pointer to some place where you may store 0 bytes, so nothing :-). This can be useful because otherwise you may think the allocation failed if you get nil back. (And you've disabled heap exception). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] an observation about GetMem
Peter Popov wrote: size is 0 (realloc does). On the other hand, assigning something is a bad idea too, as it suggests at least Size(pointer) amount of storage, unless that memory spot is somehow marked as empty, etc. How does it suggest a storage space with size 0 ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] generated assembler
Graeme Geldenhuys wrote: Hi, I know it's possible, but I can't remember the exact FPC parameters. How do I see the assembler generated by FPC for my source code? Read ppc386 -h. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety : second proposition
Marco van de Voort wrote: Inoussa OUEDRAOGO wrote: - TAVLManagedTree that uses a node mem manager provided in the constructor. The developer using this one is _aware_ of the thread safety issue and can then provide a thread safe node mem manager for an instance exposed What is exactly the add-on value for the node mem manager? I can only think of heap fragmentation and reduction of creation overhead. Yes, but fpc's memory manager also already does this (at least if the allocation size is less than 512 bytes or so). Before very complex multithreaded implementations are thought up and implemented, it would be wise to see if there really is a significant enough performance boost with the node manager. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
Inoussa OUEDRAOGO wrote: 2008/8/6 Micha Nelissen [EMAIL PROTECTED]: Perhaps another option is to remove the NodeMemManager altogether and simply use GetMem/FreeMem (or New/Dispose)? The second proposition contains a default TAVLTree that remove the node mem manager and TAVLManagedTree that has a node mem manager for people who do need it that way. Was that (a) or (b)? I didn't see this? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Daniël Mantione wrote: Easier said than done, because threading always involves multiple cores operating in the same address space, which means the cores need to communicate which core has which page in cache. They don't care about pages. They only care when writing to shared memory (to keep other caches consistent). This is on cache line level, e.g. 32 bytes for PPC usually, 128 bytes on Intel. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Florian Klaempfl wrote: Michael Schnell schrieb: Now you suggest that all procedures an instance of this kind of class are protected and thus thread-safe by definition. They aren't but it makes things easier. Just look at the linux kernel: it's smp support started also with BKL: the Big Kernel Lock That's not so good example since now it's almost gone. That suggests this synchronized keyword would be deprecated in a few years as well ;-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: synchronous class [Re: Multi threading support was Re: [fpc-devel] Russian locale information not compatible withFPClocale variables]
Martin Friebe wrote: IMHO per class may create some problems? but maybe I am just overlooking something? TBar =class( TFoo ) end synchronized class; Let's say TFoo was declared in another unit, and TFoo was not declared Synchronized. Then TFoo code can be entered by anyone at any time. Even if a thread is in TBar. How would one make sure, that a base class, knows about all classes that inherit from it? Why does it need to know? Base classes can't access the fields of inherited classes anyway. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible withFPClocale variables
Boian Mitov wrote: among the processor architects. Intel already demonstrated 100+ core processor last year. This year we expect the first 16 core processors to hit the market ( 8 HT cores), and the direction is very clear. Any compiler vendor, or developer, should at least be paying attention ;-) . I think it's the world upside down. Intel should be engineering stuff we want, not the other way around. If we compiler/application developers don't develop multithreaded programs then they can't sell their expensive processors anymore. Seems wrong to me ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Daniël Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Marco van de Voort wrote: Dani?l Mantione wrote: is no proper solution, MBCS requires it to be a string rather than a char, but compatibility requires it to be a char. Which means you are Isn't a string backward compatible with a Char? No. You can't typecast or ORD() it anymore, or subtract other chars from it. I'm not sure how many people are trying to do that on the ThousandSeparator variable, but in theory you are right. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Russian locale information not compatible with FPC locale variables
Bee wrote:
I don't understand why FPC has DELPHI MODE directive in the first place
if FPC don't want to be different with Delphi. Maybe FPC should
eliminate this directive and make it as the default mode. :-P
This is exactly the reason. Strings and API touches everything, while
generics are a language feature and thus under control of {$mode X}
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
Graeme Geldenhuys wrote: Simple one liners like the following: inc(FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots, itm.CountSlots); or FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots += itm.CountSlots; now has to change to this ugly line... FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots := FDayList[itm.WeekDayNum].Rows[itm.Timeslot].AvailableSlots + itm.CountSlots; Or: tempRow := FDayList[itm.WeekDayNum].Rows[itm.Timeslot]; tempRow.AvailableSlots := tempRow.AvailableSlots + itm.CountSlots; Assuming .Rows[X] results in a class instance. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
Jonas Maebe wrote: Indeed. I've checked the code and properties are explicitly not allowed for the C-style operators. The reason is that the x+=y is translated into x:=x+y at the parser level rather than at the lexical level. This So I guess the obvious question is: would it be risky to change that so it parses it at the lexical level? :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C style operator doesn't work with properties in 2.3.1
Graeme Geldenhuys wrote:
My question too Would somebody be so kind as to explain the
difference to me? As I mentioned before, I'm not a compiler
developer.
Very rudimentary:
source --lexer-- tokens --parser-- tree --code gen-- code
- source is the .pas file etc.
- tokens are things like '{', '}', identifiers, etc.
- tree is using the grammatical rules to form a tree with 'statement'
nodes, 'if' nodes, 'for' nodes, etc.
- code is the destination language (assembly usually).
There are more steps in the compiler, but this is the basic idea.
Apparantly in the tokens, the property has already been parsed to its
getter function. (Making some assumptions here, I don't know fpc that well).
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Illegal type conversion: enumeration type to TObject
Sean McIlwain wrote: initialization AObject := TObject(AValue); Could this be supported in the Delphi mode as well? Forgot to take your pills today? ;) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register
Craig Peterson wrote: Use mode objfpc and CallBack:[EMAIL PROTECTED] Is there some reason why this can't be handled automatically in Delphi mode? In the example (and every case where it's an issue in our code), the callback is a procedure and doesn't return anything, so Callback := Proc isn't ambiguous. Ambiguity depends on whether it takes parameters or not. Return value would be context sensitive. One doesn't want a context sensitive language. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incompatible Types: got untyped expected procedure variable type of procedure(Pointer);Register
Craig Peterson wrote: Micha Nelissen wrote: Ambiguity depends on whether it takes parameters or not. Return value would be context sensitive. One doesn't want a context sensitive language. The code presented is perfectly valid in Delphi, so it apparently *is* a context sensitive language, and I'm sure we're not the only developers that appreciate that fact. The objfpc mode can be as strict as you Yes but this has got nothing to do with original poster's problem :-). Original poster's problem is about '= nil', not the more general context sensitiveness issue. want, but it seems like the Delphi mode should work with all of the constructs that Delphi itself allows. Am I wrong about its intended behavior? No, AFAICS it's a bug in fpc's delphi mode. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Illegal type conversion: enumeration type to TObject
Michael Van Canneyt wrote: AObject := TObject(AValue); Could this be supported in the Delphi mode as well? Please submit a bug report. Eh ? As far as I'm concerned this should not compile in Objfpc mode as well ? It's a typecast, so then almost anything is allowed, except perhaps if the size doesn't match. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The usage of Include() doesn't work any more in 2.3.1
Graeme Geldenhuys wrote: WindowAttributes are defined as follows: ... property WindowAttributes: TWindowAttributes read FWindowAttributes write FWindowAttributes; ... It's the same thing as mentioned before, FPC now guarantees you can change that into GetWindowAttributes function. If this is the case, then you can't take the address anymore of a variable, because that doesn't exist. Include() implementation takes the address, then modifies it to add to it. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ExtractFileDrive is broken under Linux
Graeme Geldenhuys wrote: :/tmp$ ls -l drwxr-xr-x 3 graemeg graemeg 4096 2008-05-21 11:43 app -rw-r--r-- 1 graemeg graemeg0 2008-05-21 13:14 c:\myfile.txt -rw-r--r-- 1 graemeg graemeg0 2008-05-21 13:12 c:myfile.txt -rw--- 1 graemeg graemeg 607 2008-05-21 11:48 code-1.pp -rw--- 1 graemeg graemeg 607 2008-05-21 11:48 code.pp That's nuts! :-) Why? Because it does what you ask? :-) Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New Language Features in Oxygene 3.0
Michael Schnell wrote: Parallel Programming: have multiple-CPU systems run code automatically in multiple threads This one could be interesting. What does it provide, how does it work? Does it scale well? Etc. Nullable Expressions: Calculations automatically handle a missing value bit-combination in a type (in fact not new with Oxygene 3.0 but a feature of Remobj's language since long) (I don't know if that uses .NET support, but of course it can be done natively as well). The compiler should be able to detect this ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
Marco van de Voort wrote: You are right, after moving all exernal name declarations to interface I could move back uses msesysintf to implementation in msefileutils and the project compiled. Maybe we should have a known issues entry for this? Perhaps but isn't it quite logical one should put these in the interface part? How the hell is the compiler otherwise going to know the right name when only parsing the interface? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
Tomas Hajny wrote: On Wed, April 16, 2008 10:38, Micha Nelissen wrote: Perhaps but isn't it quite logical one should put these in the interface part? How the hell is the compiler otherwise going to know the right name when only parsing the interface? Well, this statement assumes that all users think how the compiler processes their source (which is accepted by the compiler as valid). BTW, I think 'how the compiler' processes is a bit overstated since this case is a simple extension of the define-before-use paradigm very common to pascal. Agree with Jonas, a warning would be a very good idea. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSEide+MSEgui binary package
Martin Schreiber wrote:
Recompiling msesysintf, checksum changed for msefileutils {impl}
Fatal: Can't find unit msesysintf used by msesysutils
Fatal: Compilation aborted
What do we wrong, any hints?
Do you have multiple installed msefileutils? Recompile with -va to see
what's going on.
Micha
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] sysstr patch
[EMAIL PROTECTED] wrote: @@ -335,11 +336,12 @@ Result:=1; exit; end; - Repeat + While (Result=0) and (S1^#0) and (S2^#0) do You only have to check one of S1 or S2 being unequal to zero. (Otherwise they would be different anyway). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: FYI: so before streaming, the streamer has to reset the values to their defaults to stream properly. Unfortenately, there is no function to do this, and it's usually done in constructor. Therefore streaming twice does not work properly. This is not correct. The default value is the value at create time and remains fixed during the lifetime of the component. It has no influence on the number of times you stream a component. Example: suppose a component has been written out that uses the default for a certain property X. Now if you do: class.X := some-non-default-value; stream.readstream(class); (class.X = default-value) is false, while it should be true. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: If you want a general streaming mechanism (javabeans like), then you simply should not use stored or default, then you'll have something that comes close. Oh come on! It's not *that* far from a general streaming mechanism; so I consider this a design flaw. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in trunk?
Michael Van Canneyt wrote: Oh come on! It's not *that* far from a general streaming mechanism; so I consider this a design flaw. IMHO, it's very far, see Mattias' remarks :( Hmm well the other fun thing was that in Delphi you could not have no default for floats or integers IIRC. Maybe this was fixed though? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
