Re: [fpc-devel] "Blank slate" next version of FPC
> The compiler already supports keeping records in registers under the same > conditions, but only up to a certain size (two native registers) and only > using the > same layout as they would have in memory (so no explicit splitting out fields > into separate registers). Using record fields as independent variables if appropriate could be a nice very high-level optimization strategy (AFAIK, GNU C does this easily). With X64 architecture and others that have many registers this seems to make a lot of sense, but it also would allow to allocate seldom used fields ion the stack. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
>. For us inline variables is one of the most horrid if not *the* most horrid
>thing Embarcadero could have done to Object Pascal.
Can you tell us why ?
(In C I often declare variables just before using them and I indeed would even
like to do “for (int i = 0; i<10; i++) {a[i] = a[i+1];} ☺
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> If Oxygene was open source and (CPU) native, Oxygen *is* CPU native (optionally). But not open source, and of course there are a lot more drawbacks regarding fpc/Lazarus. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> codepage aware AnsiString was one of the disruptive changes that couldn't > really be avoided. IMHO, it could have been avoided (largely), but that would have come at the cost of less perfect compatibility with Delphi XE (which even more severely broke compatibility to previous Delphi versions by their rather silly implementation). This obviously was the more important goal. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> . Syntax for parallel math (SIMD) In Oxygen, you have parallel loops and future variables. This can be used for defining parallelism in the syntax. I understand that currently RemObjects implemented this as a simple translation of the appropriate .Net framework API, and that it’s only available for Software compiled for such systems, but not (yet) when compiled for native code. But in theory, the same or similar syntax should be usable to be compiled to do SIMD support (if appropriate) and as syntax candy to support a Thread Pool library for taking advantage of the now ubiquitous SMP hardware – or both at the same time if appropriate (e.g. Matrix calculations). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> Martin was a loner kind of guy, he did the most of the MSEGUI etc projects > alone too. A real Genius, but always happy to take part in very interesting discussions. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Blank slate" next version of FPC
> I'm interested in starting (or joining) a discussion on the next (*non* > backwards compatible) version of FPC. Did you take a look at Oxygen (RemObjects Elements) ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MACRO - correct syntax?
On 25.02.2018 18:21, Giuliano Colla wrote: Well, just for sake of argument, it appears to me a rather drastic approach. While you can do really cute stuff with Macros in C, using the (or doing a) debugger for code that uses macros is a horrible PITA. Nonetheless it would be nice if there would be a predefined way to squeeze the sourcecode through the gcc macro processor, if anybody really feels the need to do so. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
On 21.12.2017 08:51, Michael Van Canneyt wrote: I know. But I believe such people are completely on the wrong track. This is, because seemingly for you (and many others), the User Communication is a most important part of the project and needs to be crafted in the best possible way regarding look and feel. OTOH, for me (and some others), the User Communication is just a means to tell the program what to do and to watch if it works as expected, while the stuff the program in fact is provided for, does not do any user communication at all. Hence, for the application programmer, it's desirable, that the IDE provides means to create a GUI that fits to the wherabouts of the development phase and final project with as little effort as possible. This results in the request for allowing to do a GUI that without any additional effort runs on multiple targets. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
On 21.12.2017 08:52, Michael Van Canneyt wrote: because I consider it a misguided approach, Could you elaborate why you think so ? What I have in mind is: - Do a common project for both "business" and the "GUI near" code. - The IDE provides some means to define which parts of the codes are to go where (in an Object Pascal system supposedly based on classes). - With that, interfaces are provided for the communication (e.g. procedure calls; in an Object Pascal system supposedly class based procedures, properties and events). - The IDE compiles the code appropriately with acknowledging separates definitions for both parts to be runnable where. - The communication between the parts is implemented accordingly: if it's a "local" GUI, just a normal executable is created, if the GUI is Browser based: this part is implemented with pas2js, and the loading and communication is implemented accordingly (if the main part is stand alone, including a built-in web server, if the main part is to be run behind a web server doing it as a cgi). I do see that this is unlikely to happen, but IMHO just because lack of dev time, not because of bad concept. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
On 20.12.2017 11:36, Michael Van Canneyt wrote: (Nothing stops really the server-side-native binary (e.g. written in Pascal) from sending a pas2js transpiled program to the browser as a part of a 'html page'/script, You could do so. But I don't think you should. How else should the Java Script code reach the browser ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
On 20.12.2017 11:36, Michael Van Canneyt wrote: You program both separately, this is natural. Obviously ! But this is not necessarily the end of what might be provided by (e.g.) Lazarus. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
On 19.12.2017 10:40, Lukasz Sokol wrote: If I Understand This Correctly, pas2js treated program would run in a browser, client side only ? And does not care what the server is, because it does not run on server ? That is of course correct and it is why I offered the sentence in brackets. Right now it's completely up to the application programmer to do the two parts of the application and to mange the communication between them. But it would be a viable task for Lazarus (ow whomever) to provide a "standard" Methodology / Library / IDE integration to allow for splitting a "normal" application in such parts. I understand that Microsoft (quite promising but finally rather unsuccessfully) had this in mind with Silverlight (C# running seamlessly in a browser). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] First pas2js public release
Great ! Thanks a lot to all who enabled this fantastic enhancement to the fpc system ! I have been dreaming of being able to "simply run" Lazarus projects (and legacy Delphi-) ) in a server and have the GUI displayed in a browser. This seems to get in reach right now :) :) :) . (OK, splitting the project in a server and a browser part and communication between the parts will not be automatically done in very near future, but who knows ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Vectorization
On 10.12.2017 20:01, J. Gareth Moreton wrote: Starting at the 4th command, it looks back to find a match in the 1st command, What about loops (such as using arrays of n elements as obvious Vectors). Supposedly, here some higher level optimization would be necessary. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF-8 string literals
On 06.05.2017 09:39, Sven Barth via fpc-devel wrote: That might be the one from Michael Schnell. Very unlikely, as this text does not mention anything about how a source file byte sequence is converted in a String constant / literal. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF-8 string literals
On 06.05.2017 09:39, Sven Barth via fpc-devel wrote: That might be the one from Michael Schnell. Probably it should be marked with a big, fat warning that it's merely a user's suggestion and nothing official. I hope it is absolutely clear in the text that this is only a suggestion and not something that is real (or will be real in the near future). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Nested functions in numlib
Performance-wise, moreover for some tasks (such as Matrix multiplication) with modern multi-core machines parallel calculation could increase performance greatly. This can be done e.g. by using a thread pool. (I once did a thread pool implementation based on TThread, but I suppose there are more "official" sources). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] LLVM
On 15.12.2016 08:35, Jonas Maebe wrote: Thanks a lot for the detailed explanation ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] LLVM
I remember that some time ago an LLVM version of fpc was under discussion. I'd like to know the state. Background: I might be interested in doing a project that runs in the browser. It seems that the upcoming technology for this is WebAssembly. I found that an LLVM backend for WebAssembly somewhere is under construction. Of course another (better) option would be a fpc directly creating WebAssembly, but I understand that this will take a lot of time. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bitset assembler
Just a note: Such functions often are needed for semaphores etc. In that case they need to take multi-thread and multi-Processor issues into account. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is there a way to make Register Allocation inside of Interrupt Service Routines more efficient when using inline-assembler?
On 13.08.2016 18:57, Michael Ring wrote: As you can see I have added the used registers list for this procedure so my expectation was that only the register declared does get added to the list of used registers. Just an additional comment: There are MIPS CPUs (e.g. PIC32 series) that feature multiple register sets and with that (certain definable) ISRs don't need to save any registers, but the hardware automatically activates an an alternate register set until return from interrupt is performed. I suggest that this case should be able to be handled as well. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures
Great ! I am using a kind of home-brew pseudo closure (a function that ends with "free;") in a project I am preparing.I'd be happy to use the formally correct stuff. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Inconsistent use of Timeout in SimpleIPC
On 12/06/2015 03:03 AM, Denis Kozlov wrote: The only way to make TSimpleIPCServer.PeekMessage respect DoReadMessage=False parameter is to store locally all sent data streams TThread does contain a queue for "TThread.Synchronize" and "TThread.Queue". It is decently managed for the main thread and polled by "checksynchronize()" with automatically is used by "event programming" environments such as Lazarus or mse ide. Perhaps it would make sens to (optionally) forward the messages there that weirdly are pre-fetched by Windows. In fact it might be useful to optionally allow to forward all received events (as properly formatted event functions) in that queue and so to use checksynchronize() and with that the Lazarus and mse ide to receive messages from other applications in a way compatible to the "event programming" paradigm . -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Feature announcement: Generic functions, procedures and methods
Is this syntax candy for automatically creating multiple functions (completely dedicated code for each type (combination) it is called with) (in fact optimizing for CPU usage), or is a single code sequence generated that takes different branches at certain locations (in fact optimizing for code size) ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Specific RTL for embedded target
On 11/14/2015 11:20 AM, Sven Barth wrote: You are aware that the discussion is about FPC's embedded target, thus no device drivers available, because there's no OS running that could host them? I in fact did not know that with the RTL the term "embedded Target" is defined in that way, but it in fact is: http://wiki.freepascal.org/TARGET_Embedded Thanks for the pointers. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Specific RTL for embedded target
On 11/12/2015 09:48 PM, Simon Ameis wrote: Hello Georg, yes, RTL may be the wrong term, so let us call it PEL (Pascal Embedded Library) In fact much of this needs to be done by (or at least better is done by) Device drivers, and hence not in the reach of fpc. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Sets > 256
(Not hitchhiking the other thread...) On 13/10/15 19:59, Mohsen wrote: Pascal sets can only contain values/enumerations whose ordinal value is <= 255. As currently new language features are discussed I would vote to drop (or relax to some K ) this limitation. This would not break any existing code. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] simpleipc issues
On 09/15/2015 01:09 PM, Michael Van Canneyt wrote: IPC = Inter PROCESS Communication. I know that you know this, but Ondrej is talking about cthreads in one of his message, so I tried to politely set a trigger. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] simpleipc issues
On 09/14/2015 03:56 PM, Ondrej Pokorny wrote: 3.) MISSING: Multiple clients (from different processes) talk to one server. 4.) MISSING: Client is able to receive a response on a request. 5.) MISSING: (Optionally, not default) client sends a request to a server that isn't running. The server is able to handle these requests when it is started. Do I understand correctly that you are talking about "real" inter-Process communication and not inter-Tread-Communication within the same project ? (IMHO, this would require completely different paradigms.) I understand that IPC is done with non-Lazarus projects in mind. Hence it is done to be used "straight forward" independent of the Lazarus Event Queue. If doing something on top of SimpleIPC it might be viable to consider Event Queue integration for Lazarus users, as well (but If you don't consider Lazarus this might be a completely unrelated issue). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] simpleipc issues
On 09/15/2015 02:43 PM, Michael Van Canneyt wrote: With my paranoid mind I of course assumed you were hijacking the thread... Of course I was eagerly waiting on Ondrej to confirm that he was looking for thread support :-) :-) :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Enable LLVM?
On 07/30/2015 06:58 PM, Jonas Maebe wrote: Some results are interesting, like the lowercase(shortstring) function becoming a rather impressive vectorised jungle: http://pastebin.com/vpugp80e . Really interesting It would take a lot of expertize to do this manually. Did you check that it really works ? IMHO it might be a nice idea to use the ASM code to provide an optimized function that is used in the standard library for ARM. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/24/2015 12:13 PM, Den wrote: *Plan first, Then Code*: I believe was said? ;) Tee or beer / cupboard or fridge :-) :-) :-) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/24/2015 12:13 PM, Den wrote: Perhaps we could work on a Standard instead of just on the Compiler itself? the normal RFC process ... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/22/2015 11:21 PM, Frederic Da Vitoria wrote: Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes. ??? ANSI C is a Declare before use language, too. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/23/2015 09:21 AM, Michael Van Canneyt wrote: If you want the features of C#, you should use C#, full stop. True for syntax variant features. But *some* syntax candy for common multi thread usage cases (e.g. a parallel loop) nowadays is a necessity. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Pascal Standard, and what we can do.
On 07/23/2015 10:34 AM, Michael Van Canneyt wrote: Support for a parallel loop is more than syntax candy, it is a fundamental language change and hence falls under 'compelling arguments'. I suppose that happily such syntax supposedly will be a pure extension and not interfere with the traditional Pascal syntax in any $MODE. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New FPC language/dialect MODE, Generics.Collections and new branch
On 07/17/2015 09:00 AM, Maciej Izak wrote: I think is good idea to discuss new dialect. The Code-aware String implementation could be much better than as well in Delphi as in fpc, but this only makes sense when the TStrings type (and it's descendents) and the interface to many libraries are done appropriately to that paradigm (and hence rather differently than right now). Nonetheless the user could would (in close to all instances) not need to be modified, nor would the performance be degraded in a noticeable amount. You might want to read details here: http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] no exceptions from arithmetical operations on AArch64
On 05/29/2015 08:37 AM, Jonas Maebe wrote: The compiler adds an explicit comparison to ensure that in case of an integer division by zero, a run time error is raised anyway. The same is done on PowerPC, which doesn't trigger an exception for integer division by zero either. As jumps in many cases are slow due to queue issues, this might be a severe performance hit. How much slower is the code after introducing the check ? Can the check be disable for high performance code snippets ? What does gcc work on that behave ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] no exceptions from arithmetical operations on AArch64
On 05/29/2015 10:22 AM, Edmund Grimley Evans wrote: There may be cases in which you don't need to know about the exception immediately. In fact - especially with high-performance applications - there are cases where the algorithm you are doing guarantees that the divisor is not zero, so testing does not make sense. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/14/2015 12:28 AM, Marco van de Voort wrote: No, since the that coder decides what he wants to offer up for inclusion, not the community. For obvious reasons, a single person is less able to see the consequences of a design decision than multiple analysts can. So that principle often results in unnecessary failing of basically excellent ideas. http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support Yes. That is a good example of a monologue. Not really, as in this mailing list I have been explicitly requested to write that text. Otherwise I would not have bothered to invest the offer (knowing that rather likely it will not have any consequences). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/13/2015 11:16 AM, Sven Barth wrote: You do know that there exist other synchronisation primitives beside the event queue? And since the TParallel.For itself is a blocking call I highly suspect that they *don't* use the event queue, but TEvent and similar instead. If using other synchronization primitives but the event queue might interfere with e.g. the LCL's Application.ProcessMessages mechanism. IMHO it already is not a nice implementation that the fpc event queue needs to be handled in parallel with the LCL event queue (which is buried within the Windows API when running in Windows, but coded explicitly in Pascal when running in Linux). Creating yet a third potentially parallel active synchronizing mechanism for multi-core support hidden in a library sounds not like a good idea to me. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 06:43 PM, Marco van de Voort wrote: Will the fpc library provide the appropriate classes for doing TParallel.For as described ? That will depend on when you submit that patch :-) This of course triggers my standard answer to such wording: It does make sense to first decide whether you want to drink tea or beer before opening either the cupboard or the fridge. Meaning that - regarding the limited resources - a community should first discuss exactly what effort (what kind of implementation in detail) would make sense, before anybody bothers to start coding. I do know that you thing along very different lines (and do provide fantastic work as a result :-) ). But the (IMHO) abysmal design (much too closely following Delphi) of the Unicode support shows the negative result of lacking research before starting coding (see http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) -Michael (more a researcher than a coder ;-) ) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 05:49 PM, Sven Barth wrote: Their own .Net compiler has shown that one can't simply map the Delphi language to the CLR 1:1 and expect something seamless. We see that with FPC's JVM support as well. So using a variant of the language that embeds itself into the framework is a much better approach. ... defying any portability. Hence making the programming system a hoax. Horrible ! Of course fpc is doing a hard fight with the effort to do a write once run everywhere system ( - http://www.lazarus-ide.org/index.php?page=about : Lazarus and Free Pascal strives for write once compile anywhere). But IMHO it's worth the effort. And for the widgetsets: The VCL was never designed to be cross platform in contrast to te LCL. It would have meant immensely more work for Embarcadero to port the VCL to Mac, Android, etc. than to buy a third part solution and to market that. Of course they could have used the CLX, but there they would have first needed to port it to a more modern Qt version. The Lazarus team (similar as the fpc team) took on with this effort and did an excellent (but tedious and still unfinished) job. This proves that it is possible, but Embarcadero just bought the Firemonkey library instead. Firemonkey might be a nice options for projects that (independent of the target device) are suppose to show a floating GUI design. But this should be a decision of the program designer and not forced by lacking features of the programming system. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 05:39 PM, Sven Barth wrote: Why should that interfere in any kind?! Behind the scenes it's propably using TThread anyway... Because Foreground code (here the calls made by the visible code the user creates to use TParallel) and the background code in the threads that TParallel might create, communicate (i.e. the Thread notifying the foreground code about a state such as ready) via the Event-Queue and for this the foreground code need to call CheckSynchronize(). But CheckSynchronize() needs to be manually done by the user in a pure FPC project. Only with projects using the LCL (or mse-gui or whatever framework), this is done without the user explicitly creating code for this. How else should SW.Stop; in the example work ? OK, TStopWatch.Stop; might call CheckSynchronize() in a loop with a timeout definable as a property of TStopWatch. This hopefully will not interfere with other CheckSynchronize() calls done e.g. by the LCL. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Xe3 Parallel for
Seemingly Xe3 provides a parallel loop feature to support fast
multi-Core applications
try
// counts the prime numbers below a given value
Tot:=0;
SW:=TStopWatch.Create;
SW.Start;
TParallel.For(2,1,Max,procedure(I:Int64)
begin
if IsPrime(I) then
TInterlocked.Increment(Tot);
end);
SW.Stop;
Memo1.Lines.Add(Format('Parallel For loop. Time (in milliseconds): %d -
Primes found: %d', [SW.ElapsedMilliseconds,Tot]));
except on E:EAggregateExceptiondo
ShowMessage(E.ToString);
end;
So they did not use the Prism syntax (parallel for / future), but (again)
introduced something new incompatible to everything.
Will fpc follow ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
Ooops - Delphi Xe8 -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 02:21 PM, Sven Barth wrote: They don't /own/ Prism. They merely license it, so what the Oxygene developers do and what the Delphi developers do are two different things. IMHO it's really silly that they provide different Pascal Dialects and Widget frameworks for different targets such as CIL (-Prism), Windows (-VCL), Mobile (Firemonkey only). fpc /Lazarus is a lot more portability friendly on that behalf, even if there is still a lot work in progress (several targets, and conceptually questionable (Unicode support - supposedly not worse than with Delphi). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Xe3 Parallel for
On 05/12/2015 02:21 PM, Sven Barth wrote: In the end I suppose that support for that TParallel class will be based on patches welcome once anonymous functions are supported. OK. As this is a kind of thread support, I assume that it might interfere or be related with with the CheckSynchronize() mechanism (for making use of the TThread.Synchronize() and TThread.Queue() based Event queue. (This is why I monitor the threading related stuff an Delphi and other locations). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] executing code snippets
Hi Linux and Java experts, My son is about to start a project that aims to research variations in small code snippets that are automatically generated by a kind of compiler. Of course he uses fpc to do the testing system, that also includes the compiler. Now he needs to start the code snippets. As the system needs to do billions of starts of such snippets, which are very small, saving them in files as an executable does not seem appropriate. We discussed the protection features done by the MMU hardware and agreed to try two different ways to accomplish the task of running the code snippets in a sandbox. 1) The traditional Linux way would be to have the main process create the code to be started in a RAM area *as X86-64 native code* and then use fork() with the appropriate options to start it as a newly spawned process. Here the question is how to use fork() (from fpc) for exactly this: i.e. the code area needs to be writable data for the parent process and protected code for the child. (Linux experts, please...) 2) The modernistic way would be to have the main process create the code to be started in a RAM area *as Java Byte code* and then call a Java just-in-time engine (as a DLL) to execute it. Here the question is how an already initialized, extremely lightweight Java engine can be called from fpc to execute a Byte Code sequence residing in the parent's RAM, in a protected way. (Java experts, please...) Thanks in Advance, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] BOOL
On 12/14/2014 04:51 PM, Marco van de Voort wrote: More importantly, TRUE is generally defined as !FALSE, and vice versa IMHO, (usually, ubiquitously ) FALSE is defined as a binary zero of appropriate bit count (hence unambiguously) , while TRUE is defined as not FALSE and hence it's binary representation is an implementation detail of the compiler and/or the processor the code is compiled for. (E.g. the 68 K processor can set a variable according to a condition code. In this instruction It uses all bits zero for FALSE and all bits one for TRUE. A compiler might or might not follow this paradigm. A colleague of mine recently had been hit by this fact, as he called a C function in a DLL by a Delphi program. In Delphi, TRUE is all bits set while in (Microsoft) C TRUE is 1. Now, in C (which does not feature a native boolean type, but boolean operators) a *decent* boolean decision is e.g. if (a). But the silly C programmer did if (a ==TRUE). Now the boolean variable a imported from Delphi was presumed as FALSE instead of TRUE. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RawByteString Insert etc.
On 12/05/2014 10:51 AM, Hans-Peter Diettrich wrote: IMO the Insert procedure should change the encoding of the string-to-insert into the CP of the target string. Else the target string can become unusable, containing an mix of characters from different codepages. While a RawByteString can have any encoding, it cannot have two encodings at the same time. Is there a decent (regarding multi-element codes such as ubiquitous in utf-8) way at all to do Insert with arguments specifying *element* position ? (As discussed already multiple times, there is no use in re-defining Insert and other such functions in a way that they use other enumeration than element-position.) The common agreement is that the user is discouraged to do any assumptions about element position specifications (other than 1 = start of the string and High(Integer) = as high as possible). Any such value needs to be taken from a calling Pos() or Length(). BTW, the documentation should be updated to RawByteString arguments. Which kind of RawByteString ? AFAIK from your mails in the last few days, with Delphi RawByteString is kind of dynamic, while with fpc, RawByteString is statically defined to be something similar to a byte array. (BTW can in Delphi RawByteString take a 2 byte encoding such as utf-2, which is the default String in Delphi and if used that way so is pos(MyRawByteString) counting in Bytes or in Words ?) OTOH, I understand that insert, Pos, Copy, Length, Delete, Concat etc are built-in functions of with the arguments are virtually handled as if they had the non existing DynamicString Type and - if two arguments with different encoding brand are given - do *appropriate* auto-conversion. Otherwise no conversion of the input data to a fixed (i.e. the default String) type is forced (which would be done if using a normal function with String as argument type). Hence for RawByteString the behavior is undefined. As we already learned, the behavior of RawByteString usually is undefined, anyway, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 12/03/2014 05:02 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: - It does not result in additional conversions. It does, e.g. in searching or sorting of StringList, when it can contain strings of different encodings. The choice of a unique encoding for application strings (maybe CP_ACP, UTF-8 or UTF-16) eliminates such conversions. If multiple encoding brands are involved, a system without DynamicString also will need to do conversions. So DynamicString does not impose *additional* conversions.- So the Checking Overhead is nothing but a rumor. (Remember, I don't suggest dropping the standard statically typed paradigm, altogether, as close loops of course work best in that way. The rumor is the unimportant Conversion Overhead, i.e. how often a check leads to a conversion. When no check is required, conversions consequently cannot ocur at all. Please re-read the text I wrote. - If in the user-code DynamicString is not used, the compiler creates the same code as before. So no overhead. - If DynamicString is used (in user-Code or in a Library interface), but only a single encoding brand is used everywhere where statically encoded strings are in place (a single program-wide string representation as you suggested in you previous mail) the only runtime overhead imposed is that at the locations where DynamicString is used (i.e. not in any close loops) an additional check for the EncodingType variable is implemented by the compiler. Here (unless the user actively decides to create string variables with encoding brands other than the program-wide default) at runtime the code *always* finds that no conversion is necessary and acts as if the String would not be dynamic, but already correct. The overhead of checking is obviously at most some 5 ASM instructions and hence unelectable regarding the function call assigned to entering the library function in question. RawByteString cannot serve two different purposes :-( As I pointed out as well: A variable' encoding brand can't be static and dynamic at the same time. This is the cause of the major misconception imposed by Delphi regarding RawByteString. And this is why I would leave RawByteString aside (as it is / as it is assumed to be / whatever) and for any improvement use a completely new Type name and a CP_ANY constant / value. In *Delphi* it is used as a polymorphic string, capable of *holding* actual strings of any encoding. But when assigned to a variable of a different encoding, a conversion may occur that converts the string into the declared (static) encoding of the target variable. Seemingly rather close to what I suggest as DynamicString. But (see http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) with a dynamic String the encoding brand number of such String would not be allowed to ever be written into the EncodingType field in the string header. If this would be true, why do the Delhi Docs discourage making decent use of the dynamic feature of RawByteString ? Anyway. A dynamic String type only makes sense if it is used in as many library interfaces (and TStrings). This is not done in Delphi and in Delphi this is not nice, in many cases restricting the user to make use of these libraries, but not as critical as with fpc, where you need to consider portability issues. In *FPC* it currently is used somewhat close to your idea, i.e. no conversion occurs in both an assignment to *and from* an RawByteString to some other AnsiString. As said, to avoid ambiguity, I vote for adding yet another string type name (e.g. ByteString denoted by CP_BYTE) that is *known* to disallow any conversion (and leave RawByteString as close as possible to the moving target Delphi presents). I understand the FPC attempt, to allow *at the same time* for the new (encoded) and old (unencoded) AnsiString behaviour, where no automatic conversions are allowed. But this would require at the same time, that e.g. all string literals *also* are stored in that (immutable) encoding, and that this encoding can *not* be changed at runtime, while DefaultSystemCodePage *can* be changed. I feel that this (simplified) attempt can't result in a decent paradigm. It is close to impossible to completely describe the behavior in an understandable way and it's prone to a lot of ambiguity. That is why I tried to invent a concept that I suppose might work and will not break (much) existing code. It is intended to be straight from ground up (it is not even necessary to assume that the content of a String is printable/readable, but it should easily work for that application.) It would allow for making flexible use of Strings with understandable and easy to use syntax candy, and would not impose restrictions to portability any more. IMHO it would not impose (noticeable) performance degradation, either. -Michael ___ fpc-devel maillist
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 12/03/2014 12:52 AM, Hans-Peter Diettrich wrote: You forget that Jonas refers to *dynamic* string encodings, unknown at compile time. ??? In you other mail you pointed out that fpc (other than Delphi) does not provide *dynamic* string encoding with RawByteString (and where else would it be supported ?). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 12/03/2014 12:52 AM, Hans-Peter Diettrich wrote: In Delphi *no* string can have an dynamic encoding of CP_NONE or CP_ACP, If you really do have Dynamic strings, obviously, the *definition* (i.e. CP_...) of such strings is strictly static (just for compiler use) and never cant be used as the *dynamic* notation of the *current* encoding (in the EncodingType field). IMHO a different implementation is not workable. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/28/2014 09:15 PM, Hans-Peter Diettrich wrote: You suggested to use string as UTF-16 on Windows, and UTF-8 on Linux. That's what I understand as a unique program-wide string representation (not sourcecode-wide, instead program as *compiled*). Then I cannot see any need or use for another DynamicString type. I already did understand your meaning and I understand that this unique program-wide string representation is better than having the libraries' APIs (including TStrings) force a fixed string encoding brand, independently from the OS we compile for (and selectable $mode specifications). But I don't *suggest* this way, as it is not very versatile and hampers portability. As said I *suggest* using DynamicString in such cases. Nonetheless, the types simply called String might be done in the way you suggest. Nothing can be broken, as long as the Delphi behaviour is undefined. That of course is is correct, but just follows the poor excuse Embarcadero offers for the flawed implementation of RawByteString (which as we both agree will never be fixed). (In fact there are many instances that old flaws have been deliberately reproduces for not breaking compatibly.) Applied to FPC/Lazarus code (compiler, libraries, IDE...) this means that it's obviously easier to *prevent* possibly different static/dynamic encodings, instead of *checking and reacting* on such flaws throughout the entire codebase. OK. Kill the Type RawByteString and the constant CP_NONE and the usability of it's value $. I do vote for doing so and instead provide new types such as ByteString, WordString, DWordString, and QWordString denoted by the constants CP_Byte = $FF01, CP_Word = $FF02, CP_DWord = $FF04, CP_QWord = $FF08. Apart from that, every encoding-tolerant code will execute much slower than code without a need for checks and conversions everywhere. As I pointed out I don't agree at all. - The check is only two ASM instructions - It does not result in additional conversions. In fact in appropriate cases it can avoid a huge count of conversations (especially when calling libraries, e.g. by means of TStrings) - in pure user code, the check is only done if DynamicString really is used in the user code, hence only when the user knows what to do. In fact commonly degradation = 0% - When calling libraries (e.g. via TStrings), the check is very small regarding that a function call is done as a result of the same statement. Estimated commonly degradation = 0,01 % So the Checking Overhead is nothing but a rumor. (Remember, I don't suggest dropping the standard statically typed paradigm, altogether, as close loops of course work best in that way. That is why fpc would need to define an additional type name (e.g DynamicString) and encoding brand number (e.g. CP_ANY = $FF00) for a decently usable type for intermediately holding a String content. This again would make *FPC* programs incompatible with Delphi. As I decently explained this would not brake any backwards compatibility, even if TStrings uses this type. - The new type is just additional, so its pure existence can't break anything: you don't need to use it in user-code, if you don't want to. - The use of DynamicString in the interface of Library functions does not break anything, as it is (to be) constructed in a way that provides full compatibility. Please do show any code (not containing RawByteString) that is not compatible when using the DynamicString paradigm as described in http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support#Analysis . Maybe the page needs to be improved. While fixing the RawByteString flaw would at least allow to *compile* FPC code with Delphi, the use of an different encoding value would definitely prevent compilation of such code with Delphi. What's the more serious incompatibility? IMHO this would be much more dangerous than introducing a decently working new DynamicString type. RawXxxString can be used for really uncoded data as done with old-style strings in a lot of applications. Such a feature would be appreciated by many users, indeed :-) While I would happily follow you suggesting making indecent use of this type impossible ia the fpc compiler, I don't think it's very dangerous to re-introduce the abysmal Delphi compatible behavior of RawByteString (may as well the documented as the the undocumented features). But why do you say would be appreciated ? Is it not possible to use RawByteString in a way the name suggests, by never bringing it together with any String variable of a different encoding brand and hence avoid any conversion - be same intentional/documented/useful or not. Anyway: I added a sentence in the introduction of the wiki page, explaining the paradigm a little more explicitly. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 12/02/2014 01:05 PM, Michael Schnell wrote: But why do you say would be appreciated ? Is it not possible to use RawByteString in a way the name suggests, by never bringing it together with any String variable of a different encoding brand and hence avoid any conversion - be same intentional/documented/useful or not. Of course you can't use any TStrings sibling (such as TStringList) in such code, as with Delphi, TStrings is based on a statically typed String brand. This would be made possible by introducing DynamicString and using this type for TStrings and friends. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/29/2014 07:55 AM, Jonas Maebe wrote: Exactly the same goes for converting strings with code page CP_NONE to a different code page: your program is broken when it tries to do that, While accessing an array beyond its bounds is not detectable at compile time and accessing an array beyond its bounds when range checking is switched off is technically not detectable at runtime, and hence *undefined* cant be avoided, the attempt to convert strings with code page CP_NONE to a different code page is easily detectable by the compiler, as we have predefined string variable type brands types here. Thus, if the outcome is *defined* *to* *be* *undefined* it can and should result in a compiler error message. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: proper interpretation and implementation of Unicode Support
On 11/28/2014 08:19 PM, Hans-Peter Diettrich wrote: In that discussion I found several errors, which are not detected by the compiler nor handled in the RTL. In the concrete entry the illegal use of the *generic* CP_NONE identifier is mentioned. That's why I felt a need to address several specific topics in above draft. Yep. You can't do a type brand the encoding of which is as well static as dynamic. This is what causes the complete mess introduced by RawByteString (and Delphi and in fpc). So IMHO the only way to go is to suggest to the users (or force them) use the type RawByteString (i.e. CO_NONE) exactly as the name suggests: no encoding brand is known, so it can't be auto-converted in any other encoding, and it can't preserve the encoding of anything that is assigned to it. This said, we don't have any (pseudo-) dynamically encoded type any more, and hence the encoding-type (and element-size) field in the string header does not make any sense any more any can be dropped altogether. But as the implementation (in Delphi and) in fpc already provides encoding-type and element-size fields, I suggest using them for an additional decently dynamic type DynamicString (CP_ANY = $FF00), which (IMHO) can be introduced without braking any compatibility or introducing any noticeable performance degradation, and allows for doing versatile code (including standard library APIs). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote: The universal paradigm would allow for extensions (e.g. UTF-32, multiple 16 Bit Code pages, an additional fully dynamic String type, n-byte un-encoded string types), as I described in the Wiki page. Even if feasable, such arbitrary string storage can dramatically increase the number of implicit string conversions. Of course it can do harm on that behalf, if the user is silly enough to *explicitly* define variables in a brand without thinking about what he is doing. But this exactly the same when he just uses the stuff currently offered by Delphi and fpc. If you arbitrary define code pages for variables for your 8 bit (ANSI) strings you will enforce many conversions. Currently in Delphi if you don't define special code pages anything will be UTF-16. So no unnecessary conversions. In fpc (and maybe Lazarus, as well) I suppose the way currently in the works is (when not changing the Default behavior by certain options): - when compiling for Windows, String is UTF-16, and the RTL and LCL ubiquitously use String: So no unnecessary conversion - when compiling for Linux, String is UTF-8, and the RTL and LCL ubiquitously use String: So no unnecessary conversion, either. If this is done in the libraries (e.g. RTL and LCL) and in user code, this would allow for as little conversions as possible and thus best performance. Here, you would need different library binaries which might or might not be a problem. But of course the portability is very questionable (including, but not limited to the fact that the result of pos is different)- When (on top of this) doing the interfaces to libraries (including TStrings) with DynamicString (encoding brand CP_ANY), no additional conversions would be necessary, as - because all other Strings use the same encoding brand (either UTF-16 or UTF-8, depending on the OS) and hence the dynamic encoding of all DynamicStrings used would always be exactly that brand. Hence, IMHO, this would nor harm at all, as the overhead the compiler needs to implement to just check the dynamic type brand and find that no conversion is necessary is extremely small. But now the user has a choice ! - If he does not do anything regarding the encoding brand of his strings, he will not notice the existence of the DynamicString Type at all. Not even Performance-wise. (But he might encounter portability issues.) - if he decides that he wants to use a dedicated encoding brand in all or parts of his code, he of course needs to know what he is doing. This can result - in improved portability (if decently done) - in improved performance (if decently done) e.g. by using on-byte strings for compact storing the information and two-byte strings for e.g. search loops, or using the best fitting encoding in the loops in the user code while allowing auto-conversion when accessing the libraries in case the underlying OS enforces a different encoding. - in disastrous increase of auto-conversions and thus performance degradation, (if not decently done). An *efficient* implementation would be based on a single program-wide string representation, with different encodings being handled only in an exchange with external data sources. Yep. But it would result in severe user code portability issues (see above). IMHO using DynamicString at the correct locations would not be (noticeably) less efficient but a lot more versatile. Cassandra After all I have the impression that the known RawByteString flaws will never be fixed in Delphi, in order to encourage the users to take the step to UnicodeString. Now the question is whether these flaws are fixed in FPC, or whether Lazarus will become the first project that definitely requires an complete move to UnicodeString, for reliable operation. For best support of non-UTF-16 platforms I'd suggest to fix the flaws... /Cassandra I also don't think we will ever see a fix for the poor implementation of RawByteString (avoiding the word flaw and the suggestion of a bad purpose), because it would brake existing user code. Regarding fpc, correcting the flaws and keeping the name RawByteString would result in incompatibility issues vs Delphi and breaking code that will be ported from Delphi. That is why fpc would need to define an additional type name (e.g DynamicString) and encoding brand number (e.g. CP_ANY = $FF00) for a decently usable type for intermediately holding a String content. (see Wiki - http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) RawXxxString can be used for really uncoded data as done with old-style strings in a lot of applications. Even if seriously flawed auto-conversion might be implemented in fpc for RawByteStrimg (for Delphi-compatibility), the user can easily avoid it by not directly combining RAW and differently statically encoded strings in an operation. -Michael
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/27/2014 07:29 PM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: E.g. there are (are least two Code pages for UTF-16 (LE, and BE), that would be worth supporting. You are confusing codepages and encodings :-( That is why I put goose-feet around Code pages. I used this wording because fpc (and Delphi ?) uses it abbreviated as CP in the constant name CP_UTF-8, CP_UTF16 and CP_UTF16BE) [ see Jonas post: CP_UTF16 and CP_UTF16BE can be returned by StringCodePage() when called on a unicodestring, and that's it. ] See it as a multi-level protocol for text processing. Yep. I see that is is workable and I understand the (supposedly mostly historical) reasons. But IMHO not a good (i.e. crafted from ground up) concept. It's known that the Delphi AnsiString implementation is flawed,... And hence it's frustrating to see that fpc needs to follow for compatibility reasons. That is why I suggested an improved implementation (see - http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support). While the seriously flawed Delphi compatible use of the dynamic encoding-brand (and bytes-per element) information (only implemented with RawByteString) can be left at it is and a decent implementation with a new DynmicString Type (CP_ANY) should be crafted. I see no problem in using the same names and values. Delphi documents clearly state: ... I fear that there will be code that relies on the flawed behavior of RawByteString (it's a feature, not a bug) and using the same name with different behavior would brake same. And a really usable DynmicString would not adhere to that description. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 05:25 PM, Sven Barth wrote: So seemingly you could do MyStringType = type AnsiString(CP_UTF16), and seemingly the size information is set according to this. No, you can't, because the RTL does not handle that. For AnsiString the element size is *always* 1. It's hardcoded. AFAIK Delphi even does a compile error if you use CP_UTF16. Thanks for the clarification. I now understand that the Element Size field in the String header is quite dummy, as under the hood there are two completely separate concepts for one-byte-Strings and 2-Byte Strings and none for other Element sizes. This to me is not obvious at all, as the language syntax and the String header data structure suggest a more universal paradigm for multiple string type brands, that each have an element-size6 and code-ID-number setting, handled by a common infrastructure. The universal paradigm would allow for extensions (e.g. UTF-32, multiple 16 Bit Code pages, an additional fully dynamic String type, n-byte un-encoded string types), as I described in the Wiki page. The dual mode concept of course does not provide such extensibility, and so I stop thinking about this (and bothering the community), and am happy that it just works as it is. Thanks again, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 05:37 PM, Jonas Maebe wrote: invalid (in the meaning of undefined) in both FPC and Delphi. Sorry (I am not a native speaker). But to me undefined and invalid have completely different meanings (in this context). An Invalid use of the language would result in an error (compiler or runtime), while an undefined language construct would result in something that might work in some way, but there is no guarantee that the outcome is always the same (e.g. in another instance or another compiler version). CP_UTF16 and CP_UTF16BE can be returned by StringCodePage() when called on a unicodestring, and that's it. I now do understand (see my reply to Sven). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 09:30 PM, Hans-Peter Diettrich wrote: So seemingly you could do MyStringType = type AnsiString(CP_UTF16), and seemingly the size information is set according to this. Not in Delphi XE. Thanks for the clarification. I did have some hope that fpc would be (or could be extended to be) better than Delphi on that behalf. I now do see the reason that resulted in the (to me rather queer) Naming AnsiString for the code page aware string type. I erroneously supposed the syntax that finally would be used would be something like MyStringType = type String(CP_UTF16), with no restriction to ANSI, but the CP_ constant defining as well a code page as an Element size, as suggested by the language syntax while working with string using auto-conversion, and by the structure of the string content header. There still might be room for (fully compatible) improvement (as I described in the Wiki), but it's even more difficult to do than I supposed. Thanks again, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 07:13 PM, Hans-Peter Diettrich wrote: Not all codepages have a fixed number of bytes per character. The string preamble contains the *element size* (1 for AnsiString), just like with every dynamic array. Sorry for sloppy wording. Of course I did mean element size (Character here obviously is not printable item). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ThousandSeparator
On 11/26/2014 01:54 AM, Mark Morgan Lloyd wrote: How does that look when hand-written on a cheque? Supposedly this is a non-breaking space, that does not allow to be replaced by a line-break (nbsp; in HTML) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/24/2014 10:45 AM, Michael Schnell wrote: . I'll post the wiki paper on this tomorrow. Please see a preliminary version of the text - http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support#Three_more_RAW_types . (Please use a new thread for any discussion on this... ) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Trying to understand the wiki-Page FPC Unicode support
I fail to understand some of the text. It seems to be unavoidable to use the name ANSIString even though I always though up when seeing a thing called ANSI containing Unicode (e. g. UTF8String = type AnsiString(CP_UTF8) ). Seemingly here the bytes per character setting implicitly is thought of as a port of the code-page definition. correct ? In section Dynamic code page: When assigning a string to a plain AnsiString (= AnsiString(CP_ACP)) or ShortString, the string data will however be converted to DefaultSystemCodePage. The dynamic code page of that AnsiString(CP_ACP) will then be the current value of DefaultSystemCodePage (e.g. 1250 for the Windows-1250 code page), even though its static code page is CP_ACP (which is a constant 1250). This is one example of how the static code page can differ from the dynamic code page. Subsequent sections will describe more such scenarios. 1) A short String does not have a Code page notification so for this static code page can differ from the dynamic code page does not seem to make much sense. 2) I fail to understand how with this explanation that seems to force auto conversion for assignments between types with different code page settings (also for CP_ACP) the static code page can differ from the dynamic code page can happen. In fact this disaster seems to be able to happen (see section RawByteString) if assigning a string with a static code page X1 to a RawByteString (hence no conversion) and then assigning that RawByteString to a string with a static code page X2 (no conversion again). In fact I assume that without abusing RawByteString such intersexual strings can't be produced, otherwise this would be rather disastrous for normal users. In section RawByteString: the results of conversions from/to the CP_NONE code page are undefined. In effect the behavior is exactly defined in this section As a first approximation. Does that mean it is due to be changed ? Is there a cause why not keep the described behavior (just don't any conversion ever). Of course this can produce intersexual strings. Is this great harm ? If yes I think assigning a RawByteString to a string with a static code page should be completely forbidden at compile time or result in a runtime error if the code page does not match. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 11:40 AM, Mattias Gaertner wrote: Ansistring supports only one byte per character code pages. Even more confused. Am I wrong thinking that with code aware Strings, for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not right, than due later) ? What is a Code page notification? Do you mean code page information? Yep. that it does *not* talk about ShortString. OK. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 12:09 PM, Sven Barth wrote: In Delphi (and FPC) CP_ACP corresponds by default with the current system codepage (e.g. CP1252 on a German Windows). OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as String(CP1252) but different from String without brackets which in turn is the same as String(CP_UTF16) ? Correct ? CP_UTF16 is not supported, because AnsiString only supports 1-Byte character strings (and UTF-8 as the odd one) and not 2-Byte character strings. I still don't understand. The wiki article seems to suggest that it is about a type called ANSIString that features a dynamically settable code page information. From discussions about Delphi and FPC, I only know a String type with a dynamically settable code page information that also features a dynamically settable Bytes per Character information and hence does support 1, 2 and 4 Bytes per Character. (e.g. UTF-8, UTF-16, and UTF-32). The difference to Delphi currently is that for FPC String=AnsiString(CP_ACP) and for Delphi String=UnicodeString (aka 2-Byte string). I understand that you mean (e.g.) Delphi XE. But what version of FPC is currently. Am I wrong assuming that in the svn we do have the NewStrings library that supports dynamical code-page *and* byte-per-character settings and hence supports e.g. CP1251, UTF-8, UTF-16, and UTF-32 ? So I seem to understand the meaning of String(CP1252), String(CP_UTF8), and String(CP_UTF16) (which seems do be the Delphi notation), but I seemingly don't get the exact meaning of AnsiString(CP_ACP) or AnsiString(CP1251) In the end, what the definition of String without brackets is, might be due to a settable compiler option and/or the OS the compiler is set to create code for. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 12:13 PM, Mattias Gaertner wrote:
In mode delphiunicode String=UnicodeString.
I see.
So even in Delphi XE where UnicodeString is denoted by CP_UTF16, the
value of the constant CP_UTF16 is not the same as the value of the
(constant or) variable CP_ACP, (while OTOH using the value of CP_UTF16
in a type or variable definition performs the same as using 0 {is
CP_DEFAULT name of the appropriate constant ?} ).
I understand that fpc with mode delphiunicode is supposed to work in
the same way.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 12:10 PM, Mattias Gaertner wrote: the results of conversions from/to the CP_NONE code page are undefined. ... because CP_NONE is not a real code page. So you understand result as what you would get when printing. In the context of this wiki page I would understand result as the binary content of the variable in question. Is this undefined in the meaning of not predictable by the user in the current version of fpc, or in the meaning of due to change when updating fpc. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
After re-reading yet another question: In section String concatenations there is no mentioning about auto-conversion. For statically typed Strings it's rather obvious that they will be auto-converted if appropriate. Technically - if differently encode - they seem to be converted to Unicode and the result is converted to match the target. Regarding RawByteStrings there has been the definition a RawByteString has exactly the same behavior as assigning that AnsiString(X) to another AnsiString(X) variable with the same value of X: no code page conversion or copying occurs. Seemingly this is not true for the intermediate results of concatenations. Here the dynamical encoding information seems to define the fact and type of conversion. If this is the fact it should be mentioned. (Whether or not this makes sense is another question: is the code information of RawByteString meant to be NONE (i.e. RAW) or dynamic (i.e. complex) ). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trying to understand the wiki-Page FPC Unicode support
On 11/26/2014 03:05 PM, Sven Barth wrote: OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as String(CP1252) but different from String without brackets which in turn is the same as String(CP_UTF16) ? Correct ? There is no String with brackets. You can only use AnsiString followed by brackets, not String. And String in Delphi 2009+ is the same as UnicodeString which is a different compiler internal type than AnsiString(CP_UTF16) would be if it would be allowed. While both AnsiString and UnicodeString have the current codepage and the character size in their header record the code page is only used for AnsiString and the size can not he influenced in any way (for an AnsiString it's always 1 and for a UnicodeString it's always 2). OK. So what is the notation in Delphi (and hence supposedly in FPC with mode delphiunicode) to define a variable with the (static) string encoding type CP with XXX = 1252, UTF8, UTF16 ? I found this: CP_ACP = 0; // default to ANSI code page CP_UTF16 = 1200; // utf-16 CP_UTF16BE = 1201; // unicodeFFFE CP_UTF7= 65000; // utf-7 CP_UTF8= 65001; // utf-8 CP_ASCII = 20127; // us-ascii CP_NONE= $; // rawbytestring encoding So seemingly you could do MyStringType = type AnsiString(CP_UTF16), and seemingly the size information is set according to this. There is no UTF-32 string (at least not in the sense of a compiler provided type). I see (It's a shame). Thanks a lot for your patience, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/23/2014 04:31 PM, Michael Van Canneyt wrote: What about RTL with UTF8 as default? I am nearly done with the would-be designdocument Wiki text, you seemed to want to see done on a suggestion for an extension of the string type variants, that allow for e.g. (1) TStrings siblings and (2) GUI libraries to work for all string encoding brands without unnecessary conversions. I'll extend the examples to the RTL... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/23/2014 05:28 PM, Marco van de Voort wrote: I meant in the way Mattias proposed, continueing making the default string type utf8 on Windows. As with Windows, the OS requires API access with UTF-16 encoded strings this would force lots of auto-conversions, not only in the RTL but with any GUI Library, as well. Same would be true for making the default string type utf16 (or whatever) on Linux. OTOH using different default string types on different platforms auks for severe compatibility problems when trying to do portable programs. Catch 22 :-( . (I myself vote for killing the type String completely and allow/force the user to do a Type definition for String himself that is used in his code, e.g. in a central unit.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/24/2014 10:26 AM, Michael Van Canneyt wrote: How do you reconcile this with the fact that pascal should be easy, and it should be usable for teaching ? .. Let's not get carried away, please... keep it simple. I do know that this is a decent argument That is why I put my text in brackets with an I myself vote for Maybe a way to allow the user to define the project-wide default encoding branding for the unqualified type String can be invented (e.g. OS-Default if not explicitly set) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/24/2014 10:41 AM, Michael Schnell wrote: Maybe a way to allow the user to define the project-wide default encoding branding for the unqualified type String can be invented (e.g. OS-Default if not explicitly set) Obviously this asks for a versatile String type (not existing in Delphi) for the interface of any code that is accessed by but not included in the user project. I'll post the wiki paper on this tomorrow. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/21/2014 09:53 AM, Marco van de Voort wrote: The versatile string type is vaporware. There is no designdocument, Do you want me to create a document ? I could easily do it. But as it would need compiler magic to work with, I don't have any chance to do the necessary patches. So I think it would be not nice at all to force any documentation on you without intending to do the work myself. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/21/2014 10:44 AM, Michael Van Canneyt wrote: But as it is, without anything for anyone to work with, your ideas are simply dead-born childs. Right you are and Marco is right that it is nothing but Vaporware right now. I did post a kind of documentation draft here to provide a base to start a discussion on. The discussion never led to a feasible point, but as there also was an agreement that it would not be doable of viable to go this way, and as you seem to be interested, I will do a Wiki article in the weekend. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/19/2014 06:46 PM, Marco van de Voort wrote: Not old Delphi compatible. One can go new delphi compatible, and make everything 2-byte as much as possible. Of course I did mean compatibility to New Delphi Strings. But here (seemingly) TStrings (and with this TStringList) works on a single pre-defined (2-Byte) encoding. And hence any other encoding (as well 2 Byte as 1 Byte) needs time consuming conversions in and out. Changing this would need a new versatile String Type that is not available in Delphi and hence not compatible. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/19/2014 09:12 AM, Marco van de Voort wrote: But I meant that even if you use utf8string in many places as soon as you stuff it in a container like tstringlist, that is gone. (forced ansi conversion, since tstringlist's interface is defined using plain string(0)) AFAI Understand (having done some decent research on this) the STringList forcing time consuming conversions) with Codepage aware Strings is only solvable by inventing an additional fully-code-dynamic String type usable as the basic interface for TStrings. IMHO, this is rather easily doable, but not Delphi compatible (See some former discussions.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
Considering the multiple discussions recently here done on the New Strings, that also introduce multiple compiler-relevant brands of a single type, IMHO there are some restrictions to be payed attention to, if the user is enable to use both ref-counted and not ref-counted Objects. Otherwise we will be facing some dangerous ambiguity. One way to avoid the ambiguity is to only provide a single brand TObject type i.e. the choice would be completely dynamic by a property IsRefCounted to TObject. If the runtime overhead for this is considered to be too big, two TObject Types (or brands of the TObject type) could be provided. But here additional considerations are necessary: The two brands need to be incompatible. A simple assignment of one to the other needs to be forbidden If such assignment is supported by the compiler, some kind of automatic conversion needs to be implemented (see New Strings encoding conversions) To decently support lists of such objects (TList), there are some alternatives: (1) different incompatible lists types are provided for either brand (2) TList is provided with only one brand and auto-conversion is forced (This is how NewStings work with TStrings in Delphi, IMHO inappropriately) (3) An additional type is provided that is fully dynamic and hence supports all brands (This is how I would prefer NewStings to work with TString) (4) My favorite here: The ref-counted type is compatible meaning that ...(a) you can assign a not ref counted object to a variable of the ref counted type brand. Here (e.g.) the ref count is set to -1 meaning not ref counted ...(b) you can't assign a ref counted object to a variable of the not ref counted type brand ...(c) TList is provided only for ref counted TObjects. Auto-conversion is done (setting the ref-count to -1) when moving a not ref-counted object into the list. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 01:27 PM, Michael Schnell wrote: I forgot: ...(b1) you can't assign a ref counted object to a variable of the not ref counted type brand: this will result in a runtime error (as the ref counted TObject type can hold not ref-counted objects by ref-count = -1) ...(b2) you can assign a ref counted object to a variable of the not ref counted type brand, if the source has ref-count = -1. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 01:58 PM, Sven Barth wrote: - no change in reference count when assigning a refcounted object variable to it - no change in reference count when assigning it to a refcounted object variable - no change in reference conut when assigning between weak variables Thanks for the explanation. Delphi introduced weak variable ... Continuing their abusing of well defined keyword from other languages. In C weak means - for externals: if the linker does not find the reference it writes a NULL instzead of aborting the link process with an error message. - for globals: if the linker finds another global of this name it does not use the weak ones. It aborts when it finds duplicates that are both non-weak. not similar at all :-( -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 03:09 PM, hinsta...@yandex.ru wrote: I believe you overcomplicate it No. We are going to run into the same mess with incompatible brands of the same types as with New Strings :-( -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 03:33 PM, hinsta...@yandex.ru wrote: I believe that whoever came up with new strings overcomplicated it Consider Java and C# : they do not store encoding in string variables Yep. dynamically encoded Strings are a nice feature if done appropriately. But I don't think they are strictly necessary. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 03:56 PM, hinsta...@yandex.ru wrote: Whatever; I disagree refcounted descendants of non-refcounted objects should be assignable to any variable of parent type; just like any variable is assignable to a variable of parent type And what about TLIst ? If TList is done for not ref-counted objects you loose the ref counting when storing and retrieving them or you simply don't know whet you get out. If TList is done for ref-counted objects, you need an appropriate conversion when storing, as you might pull them to a ref-counted variable.. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/29/2014 04:17 PM, hinsta...@yandex.ru wrote: I suggest leaving TList from FPC RTL as is. It works with pointers, so leave it be. OK. Repeating the argument for TObjectList. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 10:44 PM, Boian Mitov wrote: In general the C/C++ notion of doing as little in the language as possible, and as much in library has worked very well for it over the years. Yes, pluggable languages concept has existed at least since C ;-) . I agree, and as I said has worked well. I just took a look at C++ Threading Building Blocks (TBB - http://en.wikipedia.org/wiki/Threading_Building_Blocks) that seemingly woks along these lines and provides MultiThread / MultiCore support stuff like parallel for. Something like this would be great for fpc, as well but of course is not due to be discussed right here. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance advantage to use them) and hence are seldom used right now. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC (modeswitch arc off - the default; or maybe better a local directive) all instance variables are considered weak While I do have a vision what weak means here, can you give an exact description ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 11:26 AM, Jonas Maebe wrote: I think that a cycle detector should be an independent component, just like heaptrc is an independent add-on to detect memory problems in regular programs. So you suggest cyclic references should be forbidden (erroneous programming technique). Are they ? Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular class and turn it into a reference counted class. Reference counted and non-reference-counted classes are different language entities with different behaviour and different code generation requirements, and hence should be completely unrelated. So there simply would be a ref-counted variant of TObject you can inherit from use as an option ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 11:26 AM, Jonas Maebe wrote: (e.g. suppose that inherited method inserts self into a linked list). Or using TList with it ? Would we need an alternate TList for ref-counted objects ? -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proof of Concept ARC implementation
On 10/27/2014 11:37 AM, hinsta...@yandex.ru wrote: I think we should just roll out this feature to FPC trunk and let people test it; so those who are interested in it would test it and detect potential problems in practice rather than in thought experiments Hmm. The potential TList problem to me seems a little bit similar to what Embarcadero (IMHO frivolously) did with the new Strings. The List Classes (TStrings siblings) force a certain encoding. You can use them to store differently encoded strings but this will force very expensive conversions. You of course could use (i.e. do) TStrings work alikes for different encoding, (separately for all might need), but the multiple brands of the String type introduce a huge PITA. And fpc seems to be forced to blindly follow. Here we might get two incompatible brands of the TObject class. This might ask for some thinking about the consequences. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote: Maybe; however I am asking about reference counted objects feature. Sorry for the fuzz. (Your contribution was a direct reply to my mail about parallel loops.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/13/2014 04:14 PM, hinsta...@yandex.ru wrote: I thought Svan Barth said that he considered implementing it Regarding this, Maybe, Success in implementing should be preceded by a decision if and how this feature does make sense regarding the possible addition danger it offers (see the other contributions in this thread). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/14/2014 11:50 AM, Sven Barth wrote: It's a proof of concept implementation to have real code to work with instead of just theories. Also it's in a separate branch, so it doesn't interrupt any existing code except one explicitly uses that branch. Sounds good. -Michael (curious...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error when trying to compile code using macros
On 10/11/2014 06:04 PM, Jonas Maebe wrote: Macro's never replace text in the middle of an identifier. Does the optional extended FPC macro processor not support a concatenation syntax (such as ## with the C macro preprocessor) ? In theory it could be possible to use the gnu C macro preprocessor in certain cases. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion: reference counted objects
On 10/13/2014 02:37 PM, hinsta...@yandex.ru wrote: Any success yet? Any chance this feature will be in FreePascal 3.0 ? I don't suppose anybody is working on a parallel loop language feature. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
