[fpc-pascal] {$WARNINGS OFF} isn't local
Using FPC v2.6.3 the {$WARNINGS OFF}, {$HINTS OFF}, and {$NOTES OFF}
directives affect all subsequently compiled units as well. That seems
wrong. Delphi limits the effects of those to the current compilation
unit, which is what I'd expect. Is this intentional?
Sample code:
Test.dpr --
program Test;
uses
Unit1 in 'Unit1.pas',
Unit2 in 'Unit2.pas';
begin
end.
Unit1.pas -
unit Unit1;
interface
implementation
var
Var1: Boolean;
end.
Unit2.pas -
unit Unit2;
interface
implementation
var
Var2: Boolean;
end.
---
Compiled with
fpc Test.dpr
Produces this output:
Free Pascal Compiler version 2.6.3 [2014/11/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling Test.dpr
Compiling Unit1.pas
Unit1.pas(10,3) Note: Local variable Var1 not used
Assembling (pipe) Unit1.s
Compiling Unit2.pas
Unit2.pas(8,3) Note: Local variable Var2 not used
Assembling (pipe) Unit2.s
Assembling (pipe) Test.s
Linking Test
27 lines compiled, 0.1 sec
2 note(s) issued
But if I add a {$NOTES OFF} declaration just before the var block in
Unit1.pas, the output is instead:
Free Pascal Compiler version 2.6.3 [2014/11/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Darwin for i386
Compiling Test.dpr
Compiling Unit1.pas
Assembling (pipe) Unit1.s
Compiling Unit2.pas
Assembling (pipe) Unit2.s
Assembling (pipe) Test.s
Linking Test
27 lines compiled, 0.1 sec
--
Craig Peterson
Scooter Software
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On May 26, 2014, at 7:47 AM, Michael Schnell mschn...@lumino.de wrote: neither we are compatible with 3rd rail or radphp. I never heard somebody call one of these Delphi. RadPHP was originally marketed under the name Delphi for PHP. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On May 26, 2014, at 2:52 AM, Michael Schnell mschn...@lumino.de wrote: I understand that anonymous functions is some kind of syntax candy for stuff that - with some additional typing - could be done without, OpenMP support is about allowing parallel work - especially useful on the now ubiquitous multi-processor boxes - by means of the rtl. parallel loop and future is about syntax candy for parallel execution - e.g. via OpenMP. So my question was about the real target of the discussion. I am interested in anonymous functions specifically. See my second post in the thread for why. OpenMP support would be a nice feature, but even if it were Delphi/VCL compatible, it only gets me half of my goal, and I only included the threading support first because it was shorter to describe. Replacing our usage of fibers/coroutines is a *much* more pressing issue. In any case, neither Free Pascal nor Delphi support OpenMP right now, but Delphi does support futures and parallel loops using the OmniThreadLibrary, which requires anonymous methods. Getting anonymous methods into Free Pascal is a much more manageable short term goal than waiting for OpenMP support to be specified, implemented, and debugged. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/26/2014 8:43 AM, Michael Schnell wrote: Nice ! I did not know that. I understand that you mean this without the Prism compatible syntax candy for t futures and parallel loops ?!?!? Yes. The syntax isn't as nice, but it works: Parallel.ForEach(1, testSize).Execute( procedure (const elem: integer) begin if IsPrime(elem)then outQueue.Add(elem); end); http://otl.17slon.com/tutorials.htm -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/26/2014 10:02 AM, Dmitry Boyarintsev wrote: Ugh, but with anonymous functions replacing ShowMyDialog vs ShowMyDialogDone, you're in much worse positions. It's likely that you would have to the duplicate code. I'd assume that after modal dialog code is somehow matches to some other code in the system. Model-View-Controller pattern comes into play. The dialog itself is just a way to get a confirmation from a user to do an actions. It's likely that the same action could take place without a confirmation from a user. So, with anonymous functions, you'd need to duplicate the same action code across the system. (Anonymous functions are just for here-and-now usage). No reason to enumerate the cons of code duplication. Dmitry, no offense, but you're making a lot of assumptions about our code with no basis to do so, and I'm honestly not interested in getting into a philosophical debate about the correct way to develop software. There are cases where anonymous methods will work well and cases where we'll have to split it up. It's a tool that I'd like to have available, not something I'm going to cram where it doesn't belong. Using a threading for GUI control is generally bad idea. Most of standard GUI APIs (OSX, Windows, *nixes) have a note in 90% of their functions - do not use in multiple threads. Introducing threads to handle GUI is potentially dangerous (due to all threading syncing issues) and an overhead. Most of solutions doesn't really need threads, as well as usage of threads increases resources consumption. Fibers are cooperative threads, not pre-emptive ones. They're the way GUI APIs worked in the past (Windows 3.1, MacOS Classic) and GUI APIs generally still support them just fine. Recent releases of OS X have started having trouble with it, but older ones worked just fine. There are no synchronization issues because there isn't more than one running at the same time. So making a choice of changing the code to use Fibers, rather than using ShowDialog / DoneDialog was not so good after all. Right now you're in position to change the code code from Fibers to something more portable... And yet again using ShowDialog / DoneDialog is one of the options. Cocoa already has what I'm asking for built in to Objective C language and the Cocoa/sheets API. Many of the functions that show dialogs, that previously would have had ShowDialog/DoneDialog behavior, accept Objective C blocks now, which are very similar to how anonymous methods would work in this context. In any case, we've already done the ShowDialog/DoneDialog thing and it was unpleasant to work with and resulted code that was much harder to understand. Anonymous functions are bad for unit testing. Why? Because they do exist only at the place of the call and depends on the state of at the time the call. And thus they cannot be tested separately without the caller. *GUIs* are bad for unit testing. *Threading* is bad for unit testing. Anonymous functions are an implementation detail and are no better or worse for testing than ShowDialog/DoneDialog or OpenMP would be. In the cases where we'd use it for things like parallel loops, I'd test the outer function as a whole, and the inner functions that it calls. I don't need to unit test the anonymous function separately just because it has function in it's name. You might as well be arguing that I should break out every for loop and if statement into its own function that I can test it separately. Having an ability to test a complex code separately (outside the execution environment/application) is a big benefit. Again, you're assuming things about the testability and structure of our code that have nothing to do with the discussion at hand. What if you switch from OmniThreadLibrary to OpenMP (or whatever other threading library) that doesn't provide support for anonymous functions. What if you'd need to write a separate application, that doesn't have the requirement to use threads. Using the regular code (in procedures or methods) reduces the number of changes you'd need to do. Switching from OmniThreadLibrary to some eventual OpenMP implementation would involve removing the anonymous function syntax and turning it into a regular begin..end block for a parallel for loop. That wouldn't involve any visible changes to the objects themselves because that's all encapsulated in the outer function call. The chances of our code being reused in something that doesn't use threads is non-existent, and irrelevant either way. I've mentioned it before OmniThreadLibrary doesn't require you to use anonymous functions. Even if that's true, it would significantly reduce the expressiveness of the resulting code, and I don't know how true it is because the author has specifically said that he doesn't support FPC because of how intrinsic anonymous functions are to the design. -- Craig Peterson Scooter Software
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/23/2014 2:09 AM, Michael Schnell wrote: rather simple: - declaring the event method as something like closure resulting it having it do an auto-free on exit. more advanced (needing the RTL to provide pool of threads to fire on demand): - parallel loop and future support like in Prism (In fact I don't see anonymous functions - see thread topic - here.) I'm not sure exactly what you're asking/proposing. Yes, there are alternative syntaxes for closures that might be more Pascalish, but I want something that's compatible with Delphi because we need to keep using it on Windows for the foreseeable future. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TZipper and special file names like atenção.txt (#26213)
Nice. I can do it, opening a new issue in bugtracker. Filename encoding in zip files is poorly defined. The current APPNOTE.txt says that the only valid encoding is OEM 437, with UTF-8 if a bit is set in the header, but those were recent additions, and in practice Windows applications will generally use either the OEM or ANSI codepage of the current system locale, and files generated on Unix will be UTF-8 but won't have the language encoding bit set. Abbrevia's zip encoding/decoding tries to handle the issue in as compatible a manner as possible. It stores the original filenames as OEM/ANSI based on the current system, and stores a UTF-8 copy in an extended header so there's a known way to decode it when changing locales. When reading it has to use lookup tables to guess if the filenames are likely OEM or ANSI. On Unicode-enabled Delphi releases it's fully Unicode enabled; on FreePascal and older Delphi releases it only supports ANSI filenames but still does proper encoding/decoding. The relevant code is in AbZipTyp.pas in TAbZipItem.SetFilename and TAbZipItem.LoadFromStream if you want a reference. It's under the MPL, but I'm the original author and I'm happy to relicense it if someone else wants to incorporate the code into paszlib. https://sourceforge.net/p/tpabbrevia/code/HEAD/tree/trunk/source/AbZipTyp.pas -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TZipper and special file names like atenção.txt (#26213)
On May 23, 2014, at 8:26 PM, silvioprog silviop...@gmail.com wrote: 2014-05-23 15:50 GMT-03:00 Craig Peterson cr...@scootersoftware.com I have a question. Adding this extended header, can I open/uncompress the zip file normally in programs like 7z and WinRAR? Yes. The appnote describes the format for the extra field, which is extensible so multiple records can be stored and applications can skip over any they don't understand. 7-zip doesn't use it, but doesn't have a problem with it. I'm not sure about WinRAR, but WinZip will use the header if it exists. I didn't invent it for Abbrevia; it was originally designed by the Info-zip guys. -- Craig Peterson Scooter Software___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TZipper and special file names like atenção.txt (#26213)
The Info-zip project maintains an annotated Appnote that lists a bunch of the extra fields that various vendors use here: http://www.info-zip.org/doc/ -- Craig Peterson Scooter Software___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/21/2014 3:53 PM, Sven Barth wrote: While I consider bounties a valuable instrument for Open Source development I personally don't like them. Especially in the way you are mentioning it (no offence here!) it would put quite some pressure on me which I'm honestly not a fan of. No offense taken. I'm a bit uncomfortable with it myself because I don't want to disrupt the existing release plans, and things like generics and packages do seem like better uses for your time. Unfortunately there aren't that many people we could hire short term who understand the code and would be able to do it in a reasonable timeframe. Ideally I'd just like to give the money to Blaise to finish the work, but he didn't respond to my email. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/22/2014 2:35 AM, Michael Schnell wrote: For complex asynchronous events, I tested this: - Define a class (sibling of TObject) ) that holds some data and the procedure to be used in the asynchronous callback. - To through the callback event, create an instance and fill the data structure This is exactly the data marshalling I was talking about. Our application is heavily asynchronous and it isn't an exaggeration to say that there are hundreds of different calls with different functions and parameter lists. Having to define a new object, or even just a new method and record and fill in that data is a lot of code, and consequently there are plenty of cases that would benefit from more asynchronous behavior or parallism that don't do so. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/18/2014 2:34 AM, Florian Klämpfl wrote: I wanted only to point out that personally I would first work on OpenMP support than implementing anonymous methods (which I consider anyways very un-pascalish) and closures. That's fair. I wouldn't expect anyone who's philosophically opposed to the idea to work on it. The last time it came up it sounded like some of the other devs were interested, and there was at least grudging acceptance that it would eventually be added for Delphi compatibility. I'd just like to hurry that up. OpenMP support would certainly be nice, but it's also only half of the reason I want anonymous methods, and it doesn't seem like the timeframe for that would be any faster. To be honest, I see anonymous methods and closures not much earlier in a stable release: if they are not implemented and merged during the next few months, they will not go into the next major release (somewhere in 2015). Between major releases we have usually 3 years, so 4 years at least as well for anonymous methods/closures. I don't mind keeping a fork of a stable release with the feature backported, if that's what it takes, though obviously I'd prefer it to be in properly. Sven, if you're still following the thread, would a bounty help bump the priority enough for you to work on it before the 2.8 cutoff? Yes, that's what I meant. Closures/anonymous methods allow sometimes (in my eyes seldomly) some source line savings in modern pascal, no more no less. We'll have to agree to disagree on that. I think it's useful for encapsulating asynchronous callbacks and improving readability by keeping the callback code near the setup location and removing data marshalling scaffolding. I know our GUI design combined with the number of different asynchronous calls is rare in the Pascal community though, so I agree that for a lot of developers it won't be as large of a benefit. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/15/2014 12:58 AM, Sven Barth wrote: As Michal said, someone was working on that, but I didn't hear anything from him in the past year or so... maybe when I find the time and have some other topics removed from my list I'll look into reintegrating and finishing what he has begun... I sent an email to Blaine, but he hasn't responded. Vasiliy, the one who brought it up last year said he didn't finish his work either and wouldn't have time to, though he did point me to his repository at https://github.com/vkevroletin/freepascal/tree/closures-via-interfaces I don't want to step on toes, especially since we've already benefited significantly from the team's work as a whole, but I would really like to get this feature in. I'm happy to offer a larger amount than previous bounties, and I'm ok with it either going to one person or split up, and we can take it off-list if it would help. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/16/2014 9:13 AM, Dmitry Boyarintsev wrote: Just a suggestion. Try to rewrite the code not to use anonymous functions. The need for their support in FPC will go away. The code in question doesn't use anonymous methods yet, but I've already tried the alternatives and they are not an improvement. I don't really want to re-open the debate about their merits and syntax, but I can explain why I need them: 1) I want to use the OmniThreadLibrary. Setting up objects and thread descendents is fine in moderation, but it's too much of a hassle when you just want a quick parallel for loop. 2) Our application has multiple independent top-level windows, like a web browser. There is no MainForm. Each window can show modal dialogs that only disable that specific window. In a traditional Delphi/Lazarus app, showing a modal dialog looks something like this: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...) try if Dlg.ShowModal = mrOk then Do something finally Dlg.Free end; end; To make that work without blocking the rest of the application that needs to be split into two functions: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...); Dlg.ShowModalNonBlocking(ShowMyDialogDone); end; procedure TMyForm.ShowMyDialogDone(ADialog: TForm); begin if ADialog.ModalResult = mrOk then Do something ADialog.Free end; It's unwieldy with the simplest of dialogs, and gets much worse if you need to share state between the Show and Done functions, or if the dialog is only shown selectively. To solve that, years ago we started using cooperative threads (coroutines/fibers) in our GUI thread. I re-implemented ShowModal so it handles the details internally. When you call it it displays the dialog, just like the ShowModalNonBlocking() call would, but then switches to another thread that processes messages. When the dialog is finally closed the running thread switches back to the ShowModal call, which then exits like normal. As a result, even though we can have several independent modal dialogs up at once, the code is all identical to the first example. Everything is nicely encapsulated and sharing state before and after the dialog is trivial. Unfortunately, fibers introduce incompatibilities on both Windows and OS X, and are deprecated on OS X, so we need to stop using them. They are by far the cleanest approach, and I'd keep using them if I had any choice whatsoever. The second best alternative is to use closures and anonymous methods. The syntax isn't as clean, but at least everything is kept within a single ShowMyDialog call. In that case it would become something like: procedure TMyForm.ShowMyDialog; begin Dlg := TMyDialog.Create(...); Dlg.ShowModal( procedure begin if Dlg.ModalResult = mrOk then Do something Dlg.Free; end; end; Again, these examples are extremely simplified. The benefits are much greater when you need to use variables in the outer scope. In our application we have over 90 dialogs and almost 400 calls to ShowModal, so the easier I can make that the better. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi compatible anonymous functions
On 5/16/2014 11:18 AM, Florian Klämpfl wrote: Isn't using anonymous methods in this case only a work around for missing OpenMP support? Absolutely, but neither Free Pascal nor Delphi implement OpenMP. The OpenMP page on the Free Pascal wiki hasn't been significantly changed since 2008, which coincidentally is the last time Allen Bauer blogged about his Delphi Parallel Library. I'm looking for something that I can use soon, not in 5 years. Also, while I prefer the OpenMP proposals in the wiki, I don't see us dropping Delphi for Lazarus on Windows anytime soon. Short term we'll be too busy moving our Linux version over from Kylix and then re-porting our OS X version from LCL/Carbon to LCL/Cocoa. I still don't get how closures/anonymous methods help you to get rid of fibers? I mean, anonymous methods are only a short cut; closures allow you to capture the state of the variables of the outer scope even if the outer scope is left. But that's it? No, it doesn't completely replace fibers. That will require some very painful detangling and much uglier, asynchronous code. However, a majority of the usage is just doing calculations, showing a dialog, then doing something with the dialog results. In cases like that it should be relatively easy to do fairly mechanical conversions to something based on anonymous methods and closures. I'm not sure what you mean by the But that's it? though. Yes, they're just syntax sugar. The alternative is creating a second procedure (polluting the namespace), declaring, allocating, and initializing a record with the local state, then passing it to that second function. It's doable, and that's exactly what we did before I implemented the fiber support, but it's certainly not ideal. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Delphi compatible anonymous functions
Hi all, What's the current state of FPC's anonymous functions/closures support? Is anyone working on it? Is it something that a bounty would help with? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Create class descendant at runtime?
Hi guys, Does Free Pascal or any of the included packages have a way to create a descendant of a class at runtime? Before anyone tells me it's a bad idea, I know. I have an existing class-based registration scheme that I'm adding some dynamically loaded plugins to and the alternatives are all messier. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CAB file format
On 11/25/2013 9:17 AM, Marcos Douglas wrote: FPC has a lib to create CAB file format? Abbrevia can create CAB archives (Windows only) and the official releases support FreePascal. http://tpabbrevia.sourceforge.net/ -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] EMBT's FireMonkey framework with FPC
I ha On Jun 23, 2013, at 3:26 PM, Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: Anybody know if FireMonkey 2 (one included with Delphi XE 4) is still compatible [even with some manual tweaking of FMX source code] with Free Pascal? I haven't tested it, but I'm fairly certain it doesn't work in Free Pascal mode anymore, and even if it is with minor tweaks, it won't stay that way as they continue changing the language. If you're ok rewriting just just the UI per platform, you should evaluate RemObject's Oxygene too. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On 2/27/2013 6:41 PM, Graeme Geldenhuys wrote: Component vendors simply aren't interested in FPC, and those that are, are bought about by EMBT and made Delphi only. Eldos added support for Free Pascal to SecureBlackBox within the last couple of years. Indy supports it in their main repository. I added FPC support to Abbrevia in late 2011. I know we're not the only commercial software vendor to give up on Delphi for cross platform work, and Free Pascal's Delphi compatibility is the only thing that has made that possible. If you want to say delphi compatible, it must be all or nothing. Why? It should be driven by user needs and developer interest, just like it always has. I'd like to see anonymous methods because it would make porting the OmniThreadLibrary possible. The fact that they aren't supported doesn't make the existing generics and class helper support unusable. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Any way to find all descendants of a class?
In Delphi I can use the new extended RTTI support to build a list of all TForm descendants in my application (TRttiContext.GetTypes). Is there any way to do the same thing in Free Pascal without having to explicitly add each class to a list? I do have an intermediate class that all of our other forms descend from, so I can add something there if necessary, and I don't need it to be compatible with Delphi. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
On 6/25/2011 7:55 AM, Marco van de Voort wrote: Well, then explain why Delphi + XE has exactly the same problem. Delphi + gettext does, yes, but Delphi + resourcestring + resource dll does not. Resourcestring is a language feature; gettext is a third-party library. I'd expect them to have different semantics. As a language feature, the compiler/rtl should provide a way to translate resourcestrings and have it work correctly. The fact that FPC uses gettext and Delphi uses stringtables on the backend are irrelevant implementation details. What you are trying to do is implementation defined. Obviously, but it shouldn't be. resourcestring means I want to translate this string, but the code should work like a regular string. IMO, FPC's behavior breaks that contract. More or less. When localizing, the default windows resources model simply loads a resource dll (containing the localized data including copies of all forms, so an user can adjust e.g. the width of a text field) over the addresses where in the main .exe the original resources are. That's incorrect. Resource DLLs are loaded using LoadLibrary, just like regular ones, and then you pass that handle to FindResource/LoadResource to load the localized version. If you pass a nil handle in it will still return the original untranslated version. Delphi's DFM loading and resourcestring implementations hide those details, but they are explicit actions on the RTL's part. Hence their (gettext) behaviour in Delphi is exactly the same as in FPC. Don't confuse using gettext explicitly through _() and implicitly through resourcestring. In Delphi, accessing a resourcestring translates into a call to LoadResString(), which uses FindResourceHInstance to load from the translated DLL. On FPC, it just reads directly from a variable you can update with SetResourceStrings. The difference is that if you have a const reference to one Delphi does a separate pass that fixes those references as well with a explicit LoadResString calls during program initialization. It could just as easily use gettext() to retrieve the translated strings, and that's what dxgettext's AddDomainForResourceString does. If it AddDomainForResourceString doesn't update the const references properly, it's just because it isn't calling the routine that does those const fixups (System._InitResStrings). Basically, to get the correct resourcestring behavior, FPC would have to maintain a similar table of resourcestring const references, and when you call SetResourceStrings it would have to update those references too. It would require changes to RTL and the compiler (to build the table), but the gettext functions wouldn't be affected at all. This is getting pretty technical though. Would I have better luck on fpc-devel? -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] resourcestring and const arrays
In Delphi I can use resource strings with const arrays and everything works correctly. For example, if I have a resource DLL with translated strings and this will work: resourcestring SSunday = Sunday; const SWeek: array[0..0] of string = (SSunday); begin WriteLn(SWeek[0]); end; I've tried doing the same with FPC's GetText unit and SetResourceStrings. SSunday gets translated correctly, but SWeek doesn't. Is that something that should work if I'm early enough in the initialization order, an unimplemented feature, or something that's unlikely to changed? Thanks, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
On 6/24/2011 4:14 PM, Marco van de Voort wrote: No, this is a problem of gettext. It's a problem with FPC's resourcestring implementation, rather than something specific to gettext. I could use SetResourceStrings directly (objpas.pp) and it will have the same issue. For this to work you really need resource types that work based on replacing memory areas, or use _() What do you mean by replacing memory areas? Runtime patching? Does something exist that supports that? On Windows we're using resource DLLs directly, without going through gettext, so I really don't want to switch to _(). I don't mind low-level hacking though. ;) It looks like Delphi writes a table of these kinds of resource string uses and fixes them up during program initialization. If FreePascal had a similar table it could do the same thing as part of SetResourceStrings. Assuming Krzysztof is correct that the compiler flattens the references, I'm guessing replacing the FPC_RESOURCESTRINGTABLES section won't help either. If it would, I'd be happy to look into that approach too. If fixing this is correctly is a reasonable possibility, I'm happy to look into it myself, but I would like to hear how attainable it's likely to be first, since I've never worked on a compiler before. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] resourcestring and const arrays
On 6/24/2011 4:52 PM, Krzysztof wrote: I had similar problem, I think that this is because consts are filled when compiling and there is no way to change them at runtime. Try this trick with pointers: Thanks Krzysztof. That looks like the least invasive approach, so if I can't get them working correctly that's what I'll do. -- Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] {$R file} support on non-Windows targets
Does any version of FPC support the {$R file} syntax for resources on
non-Windows targets? I'd prefer that to Lazarus's LResources unit. I
have the impression that some work on it was done as part of Simon
Kissel's CrossFPC project, but I haven't been able to verify that. Was
work done and never completed? Is it a TODO that just doesn't have
anyone to work on it?
Thanks,
Craig Peterson
Scooter Software
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] {$R file} support on non-Windows targets
Is this Scooter Software that brought the awesome Beyond Compare 2 to Windows users? If so, I sure hope the query is because work on BC 2.xx or 3.x involves other platforms like Linux. ;-) Yes it is, and you must not be on the beta list. ;-) V3 is in public beta and the Linux port is already available. We're currently using Kylix, but we're looking into swapping out the compiler for FPC first, with a transition from CLX to LCL sometime later. http://www.scootersoftware.com/beta3/ Regards, Craig Peterson Scooter Software ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
