Re: [fpc-devel] RFC: customvariant handling in variants.pp and fmtbcd.pp
Could I ask why is there needed VarDataInit ? (only for my interest ;-)) A good question. Formally it is not needed, but in general initializing variables before use remains a good idea. Here the TVarData is passed to VarDataCastTo, and after initializing we can be sure that VarDataCastTo won't find garbage in remaining 4 bytes of structure if it accesses them for whatever reason. Thanks for explain Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)
- Original Message - From: Hans-Peter Diettrich drdiettri...@aol.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, 14 April, 2011 15:12 PM Subject: Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject Skybuck Flying schrieb: Anyway if somebody could take a look at all of this and make some sense of it that would be great/nice, saves me some time and could clear some confusion (?) ;) Before looking at your code, I'd know the role that your project plays at all. Is it only about making the FPC code compilable by Delphi, as the first stage in the FPC bootstrap? Yes. Plan is as follows: 1. Compile free pascal compiler sources without free pascal rtl and instead use a bootstrapping rtl. The bootstrapping rtl is a mix of Delphi's own RTL (which is implicitly present and doesn't require any additional files/sources) and any RTL inconsistencies/extensions placed in my own mini extension RTL which is currently simply called unit_skybuck_types.pas LOL. 2. Once free pascal compiler is compiled towards an executable by Delphi it should then be possible to compile Free Pascal's own RTL with Free Pascal. An alternative idea could be to start working on compiling the Free Pascal RTL with Delphi as well. This would be possible by renaming all conflicting files, so at least no unit name conflicts like system.pas. However if this would work is doubtfull because of potential type conflicts but perhaps Delphi allows types to be overriden or redeclared or overloaded. That in itself could actually be an interesting language feature/extension. (I shall post this idea later on on usenet as well) Such a language feature would be nice to solve unit type conflicts, for example some unit defined TSomething and now another unit wants to define TSomething as well, however because the unit scope is in affect this is not an issue... For other units it's also not an issue because they could simply write: unit1.TSomething and unit2.TSomething however that does require putting the unit name in front of it. Perhaps a type override could specify which TSomething to prevail for example: uses unit1; unit2; type TSomething = unit2.TSomething; override; Then in the rest of the unit TSomething from unit2 would be used without having to write Unit2.TSomething all the time. It could also have written the following: TSomething = SomethingElse; override; This will override the type from unit1 and unit2 so that unit3 can use that namespace/type for itself. 3. Once the RTL is compiled use the original RTL sources and/or RTL binaries to recompile the free pascal compiler so it's fully self-hosting and self-compiling. (Etc) (I am a little bit exciting about this potential new language feature so I am cutting this short, but this is basically the plan ;) =D). In this case it would be easier to use an older Delphi commandline compiler, from the time before the Ansi-To-Unicode move, or simply an I don't do command line compiling, I hate it, working with the command line is freaking slow. I don't think ansi will be much of a problem, it's kinda cool to have a unicode compiler... Perhaps it will be the first in the world, or perhaps not... who knows (for real lol) ? legacy FPC. You also could try to make the FPC sources compile by gcc - The whole idea is to not require FPC to do any development, all development done on/in Delphi IDE and then final stage compile with FPC for non-supported-delphi-platforms. GNU Compilers are slow, furthermore they are not object-oriented as far as I know/last time I checked so they totally out-of-the-question. The least I would want is record with properties support, not yet sure if Free Pascal has that record-language-feature but if not then Tobject could be used for that. And thus oo needed. Furthermore class support is nice. but I'd delay any such attempts to the time, when there doesn't exist any immediately applicable compiler any more. Let me know if there is a pascal to c converter or object pascal to c converter or object/pascal to cuda/opencl/glsl/cg converter because as far as I know it don't exist or it's really shitty (delphi to c converter). In other words the time for me has already come to attempt it ;) =D and thus this project came to be ! ;) =D and ofcourse it will be most handy for the future. And now I go post that language/type override idea ;) Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Android native application with local webserver
On 04/14/2011 05:12 PM, Dariusz Mazur wrote: I've implement message queue (like in Windows), also VCL/LCL style communication with widgets. TThread.synchronize was reimplement, because there is many Main thread - per each session. All enough to use the same source do build desktop and web application. GREAT !! Would it not make sense to make this a new LCL Widget Set ? server work in own thread, each request in own, each session (whole application for one user) in own communication between request thread and session threads are done via FIFO queue So the Server is the Main Thread, No , I mean this is main thread of listen socket Sorry I can't follow you here :-( . which is supposed to do most of the Office Logic work, office logic and changes in used widgets (controls) is done in session thread, and when computing if finished, request thread prepare response, based on new state of visible widgets, there are mutexes, to coordinate flow between this two threads. Is this invisible to the application programmer, so that (s)he sees just one thread with no need to synchronization ? including handling the TTimer events. IMHO, it's not a good idea top do the Office Logic stuff directly in the threads that are fired by the single requests, as this will ask for huge problems with mutual access of commonly used data, which the user does not really want to handle with a great count of CriticalSections or similar synchronization stuff. I feel that it would be good to have the requests transformed to main Thread Events, so that a normal (= not thread aware) user is able to do the programming seeing only a single thread. In my attempt single session (like desktop application) work in own thread. In session can be use inner threads, events, modal windows etc. similar like in desktop. Sorry I can't follow you here :-( . I don't think so But when browser send request, server don't response at now, only wait 30s and then (if its nothing to respond) send message to browser with order to repeat request. OK. If the program works only on request and the java code does a long sleep, the CPU use will be decently low. But of course this will not provide a very agile experience to the user. Why. When server want to push to browser response earlier (response took less than 200ms including ping), when browser (user) want ask, then send new request, no one wait Sorry I can't follow you here :-( . (Julian, can you help ?) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] helper feature finished
Am 14.04.2011 22:29, schrieb Florian Klämpfl: Am 13.04.2011 12:11, schrieb Sven Barth: Am 12.04.2011 21:41, schrieb Sven Barth: The latter change is not yet commited (I will do that tomorrow), but the implementation of the flag and the removing of current_syssym are already commited. Done. Looks good to me now. So imo it can be merged. Jippieh :D Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)
Skybuck Flying schrieb: Before looking at your code, I'd know the role that your project plays at all. Is it only about making the FPC code compilable by Delphi, as the first stage in the FPC bootstrap? Yes. Okay, so far. 3. Once the RTL is compiled use the original RTL sources and/or RTL binaries to recompile the free pascal compiler so it's fully self-hosting and self-compiling. This can be accomplished already, without any modifications to the FPC code, by using FPC instead of an Delphi compiler. The whole idea is to not require FPC to do any development, all development done on/in Delphi IDE and then final stage compile with FPC for non-supported-delphi-platforms. Development can be done in whatever IDE you like. This is absolutely independent from the compilation and linking of the developed code. When you want to use FPC as an alternative compiler for Delphi, then you'll have to make it output binaries in a way that the Delphi linker can use. In order to make use of further targets, as already supported by FPC but not by Delphi, you'll have to update the Delphi RTL accordingly, and you must add linkers, debuggers etc. for all these targets. Here the Delphi license gets into the way, so that you'll have to implement a new Delphi-compatible RTL from scratch. This suggests to me that your approach means much work without any practical use, you better create that RTL first, so that it can be used already in the compilation of FPC itself. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)
In our previous episode, Hans-Peter Diettrich said: Development can be done in whatever IDE you like. This is absolutely independent from the compilation and linking of the developed code. When you want to use FPC as an alternative compiler for Delphi, then you'll have to make it output binaries in a way that the Delphi linker can use. In order to make use of further targets, as already supported by FPC but not by Delphi, you'll have to update the Delphi RTL accordingly, and you must add linkers, debuggers etc. for all these targets. Here the Delphi license gets into the way, so that you'll have to implement a new Delphi-compatible RTL from scratch. This suggests to me that your approach means much work without any practical use, you better create that RTL first, so that it can be used already in the compilation of FPC itself. IMHO you'll describing problems he'll never reach. After he gets a Delphi compiled FPC, he still needs to make the resulting product _work_. If I understood it correctly, this (making the Delphi compiled FPC work stable enough) was the problem with earlier attempts, and the unicode version won't make it any easier. It could be bugs in Delphi, it could be bugs or assumptions in the FPC code that only surface with Delphi, but either way, this has to be examined, and that is way more difficult then cobbling up a bit of replacement code here and there for places that Delphi can't yet compile. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)
Marco van de Voort schrieb: When you want to use FPC as an alternative compiler for Delphi, then you'll have to make it output binaries in a way that the Delphi linker can use. In order to make use of further targets, as already supported by FPC but not by Delphi, you'll have to update the Delphi RTL accordingly, and you must add linkers, debuggers etc. for all these targets. Here the Delphi license gets into the way, so that you'll have to implement a new Delphi-compatible RTL from scratch. This suggests to me that your approach means much work without any practical use, you better create that RTL first, so that it can be used already in the compilation of FPC itself. IMHO you'll describing problems he'll never reach. After he gets a Delphi compiled FPC, he still needs to make the resulting product _work_. That's exactly my impression, as outlined before. It may be easier to start a project from the easy side, but chances are high that it will never reach the goal, when the difficulties increase with every futher step. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Can't build FPC what can be a reason?
13.04.2011 8:12, Paul Ishenin wrote: make clean all OPT=-g -gl -gw -godwarfsets I do it also on Windows 7/win32. I tried both 2.4.4 and 2.5.1 as the starting compiler. this compiles: make clean all this does not: make clean all OPT=-gwl Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Announcement: Free Pascal CompilerDelphi XEPortProject (type override idea)
On 14/04/2011 15:10, Skybuck Flying wrote: Anyway if somebody could take a look at all of this and make some sense of it that would be great/nice, saves me some time and could clear some confusion (?) ;) Before looking at your code, I'd know the role that your project plays at all. Is it only about making the FPC code compilable by Delphi, as the first stage in the FPC bootstrap? Skybuck Flying schrieb: Yes. Plan is as follows: snip 2. Once free pascal compiler is compiled towards an executable by Delphi it should then be possible to compile Free Pascal's own RTL with Free Pascal. Why? Free Pascal already compiles its own RTL - why do you need to do this? What advantage would there be in tying FreePascal to a Windows only compiler, when it is already cross platform - the RTL already compiling on multiple platforms? An alternative idea could be to start working on compiling the Free Pascal RTL with Delphi as well. Why? What advantage would this have? The FreePascal RTL is not radically different from Delphi in many ways, so what advantage would this give? And we are not talking about GUI here at all - we are talking about fundamental types and such. GUI is a completely different subject, as the toolkits API would be built with the basic building blocks for each target. 3. Once the RTL is compiled use the original RTL sources and/or RTL binaries to recompile the free pascal compiler so it's fully self-hosting and self-compiling. It already is. Am I missing something here? legacy FPC. You also could try to make the FPC sources compile by gcc - The whole idea is to not require FPC to do any development, all development done on/in Delphi IDE and then final stage compile with FPC for non-supported-delphi-platforms. There was a Delphi IDE plug-in that did this - would that just not be, you know, simpler? GNU Compilers are slow, furthermore they are not object-oriented as far as I know/last time I checked so they totally out-of-the-question. What does that have to do with anything? The compiler being OO has nothing to do with the capability of the compiler to compile OO code. Honestly, even the explanation isn't making what you are trying to do make any more sense than it did before you started. So, can you please explain exactly what you are doing - without digressing and assuming we already understand? Because, really, I don't think we really do - at least not all of us ;-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
