Re: [fpc-pascal] Best way to transfer data between applications?
Hi Jorge, Even if so, it won't solve many of the other problems I am trying to solve. On the other hand, do you have a Tarball available for download somewhere? (I checked the Google Code page, but no downloads, only SVN access it looks like). Thank you, Noah Silva 2012/11/1 Jorge Aldo G. de F. Junior jagf...@gmail.com i reiterate that my Pascal-Actor-Model can do exactly what you are saying... writing a save file in background type of actor is trivial, and the synchronization is already done... 2012/10/31 Noah Silva shir...@galapagossoftware.com: Hi Aldo, Well it's not just synch problems with threads, I've found threads to not be so reliable under FPC for anything but trivial test cases. Sometimes the program is incredibly slowed when using threads. Also, Unix and Windows have to be treated differently, etc. - which is not entirely FPC's fault. Making separate applications gives a number of advantages (which I listed in my last mail). The need to send data structures back and forth is the only real disadvantage - but that's just trading for synchronization issues. As an aside, threads are one area where it seems ObjC has a huge advantage. I wish there was a way to just say something like RunInBackground(procedure) in FPC. Background threads not being able to touch the GUI, etc. makes it all but useless for many purposes. Of course for scientific computing type applications where problems can be partitioned neatly, threads make perfect sense and work relatively well. For things like I want to save this file in the background while the user continues to use the word processor, I've found they aren't anywhere near worth the trouble to implement in FPC - yet. For example, if I want only one instance of a daemon running, then I have to make it a separate process (reasonably anyway). If I want it to be 64bit, but the GUI has to be 32bit, then it has to be a separate process, etc. I will take a look at your framework, because I am interested in all sorts of new developments, but it's unlikely I will re-code everything to use a particular design pattern or framework. The original question I meant to ask was basically Is there an easy/mostly automatic way to transport data structures between processes, and from all the discussion on this list - the answer seems to be no. Encoding is one piece, data transfer is one piece, and the glue in-between (Class factories, etc.) is something one probably has to put together themselves. Either way, it makes everything more complicated to do something that is in principle relatively simple. Thank you, Noah Silva 2012/10/31 Jorge Aldo G. de F. Junior jagf...@gmail.com Hm... if you gave up using threads because of the problem with synchronization then you might have a look at my pascal-actor-model framework... its a set of classes that implements Hewitt's Actor Model Concurrency and its able to solve exactly that... http://code.google.com/p/pascal-actor-model/ Code can run assynchronously or synchronously, depending on your needs. theres a mainthreadqueue that lets actors talk to the main thread (where the GUI elements usually reside) using blocking (with timeout) protocol. All messages are actors and can be streamed across the network, etc.. (i am in the process of implementing distributed computing based on that actor model) etc... there are already a lot of components and the basic actor functionality is already working. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On Thu, November 1, 2012 00:24, Giuliano Colla wrote: Il 31/10/2012 14:45, Jonas Maebe ha scritto: On 31 Oct 2012, at 14:35, Giuliano Colla wrote: . . but if it doesn't it's a Delphi bug, I'd say. What are exceptions there for, if not for telling you that what you requested cannot be done? There are multiple ways to indicate a failure. Exceptions are a very expensive way for doing so, and generally should only be used in cases that are truly exceptional and/or indicate a fatal error. In other cases, using a special return value is generally much more appropriate. My bad. I hadn't realized that low level file operation such as FileOpen and FileCreate do not raise an exception on failure. I seldom use them, and only in connection with physical devices, where I always take care to verify the existence before attempting to read or write. So I just relied on a useless try-except construct. It's very unlikely that such a failure would permit a program to continue running, I'd call it a fatal error, so an exception would be welcome, but that's life... I don't agree with your statement that such an error wouldn't allow the program to continue running. Vice versa, there are many situations where the result may be used for a different behaviour of the respective program. As an example, you may use the return value from FileCreate for checking whether the user supplied a valid file name in his input to the program (and ask for another file name afterwards), you may also check whether you can access the respective file in read/write mode (and thus allow user to change the file) or you need to stick to read-only mode (and thus allow just viewing/reading the content), etc. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to transfer data between applications?
On 01.11.2012 03:30, Noah Silva wrote: As an aside, threads are one area where it seems ObjC has a huge advantage. I wish there was a way to just say something like RunInBackground(procedure) in FPC. Once anonymous methods are implemented (I don't give an estimate here though) you should be able to do something like that. Background threads not being able to touch the GUI, etc. makes it all but useless for many purposes. That you can't access the GUI is not a problem of FPC, but a design decision of the LCL (or better: the VCL which it is based upon). If you'd write a GUI toolkit yourself you could write it in a way that allows access from multiple threads (if the underlying GUI system (WinAPI, X11, etc.) allows it of course)... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Il 01/11/2012 09:28, Tomas Hajny ha scritto: On Thu, November 1, 2012 00:24, Giuliano Colla wrote: Il 31/10/2012 14:45, Jonas Maebe ha scritto: On 31 Oct 2012, at 14:35, Giuliano Colla wrote: . . but if it doesn't it's a Delphi bug, I'd say. What are exceptions there for, if not for telling you that what you requested cannot be done? There are multiple ways to indicate a failure. Exceptions are a very expensive way for doing so, and generally should only be used in cases that are truly exceptional and/or indicate a fatal error. In other cases, using a special return value is generally much more appropriate. My bad. I hadn't realized that low level file operation such as FileOpen and FileCreate do not raise an exception on failure. I seldom use them, and only in connection with physical devices, where I always take care to verify the existence before attempting to read or write. So I just relied on a useless try-except construct. It's very unlikely that such a failure would permit a program to continue running, I'd call it a fatal error, so an exception would be welcome, but that's life... I don't agree with your statement that such an error wouldn't allow the program to continue running. Vice versa, there are many situations where the result may be used for a different behaviour of the respective program. As an example, you may use the return value from FileCreate for checking whether the user supplied a valid file name in his input to the program (and ask for another file name afterwards), you may also check whether you can access the respective file in read/write mode (and thus allow user to change the file) or you need to stick to read-only mode (and thus allow just viewing/reading the content), etc. You may be right, but the try-except construct is there exactly to permit you to handle those situations. However I'd like to point out a significant inconsistency. Please give a look to the following piece of code: procedure TForm1.Button1Click(Sender: TObject); var MyFile: TextFile; AName: String; begin AName:= 'BadName.txt'; AssignFile(MyFile,AName); Reset(MyFile); Raises an Exception: EInOutError File not found end; procedure TForm1.Button2Click(Sender: TObject); var MyFile: Integer; AName: String; begin AName:= 'BadName.txt'; MyFile:= FileOpen(AName,fmOpenRead); = Just sets MyFile to -1 end; Both procedures perform exactly the same action, i.e. they attempt to open for reading the non existing file BadName.txt. The first one gives rise to an exception. The second one doesn't. Your considerations should apply to both, or to none. As it is, it's rather inconsistent. Just my 2c Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 01 Nov 2012, at 11:40, Giuliano Colla wrote:
You may be right, but the try-except construct is there exactly to permit you
to handle those situations.
However I'd like to point out a significant inconsistency. Please give a look
to the following piece of code:
procedure TForm1.Button1Click(Sender: TObject);
var
MyFile: TextFile;
AName: String;
begin
AName:= 'BadName.txt';
AssignFile(MyFile,AName);
Reset(MyFile); Raises an Exception: EInOutError File not found
end;
That depends on the state of the {$i+/-} directive.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Xcode
On 01 Nov 2012, at 05:38, Noah Silva wrote: 2012/8/16 Jonas Maebe jonas.ma...@elis.ugent.be FPC works with the assembler and linker of Xcode 2.x up to and including the latest Xcode 4.x, but with Xcode 4.3 and later you have to but with Xcode 4.3 and later you have to install them separately Really? I just had to link them from the appropriate folder in the XCode application bundle (to the global binary folder). Perhaps this is because I used to have 3.x on the same machine? No, that works with any Xcode version that has ever been released (although in the past the binaries were somewhere below the /Developer folder rather than inside the Xcode application bundle). However, it works in the same way that installing the hackintosh Mac OS X distribution on a generic PC works: in a completely unsupported and probably incomplete way, that may break at any time (e.g. in this case when the compiler/linker needs a file or utility that you forgot to symlink). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Il 01/11/2012 01:07, Jonas Maebe ha scritto: I'm personally not a big fan of having different behaviour across platforms when it can be avoided without too much trouble, In general I agree with you. I often debate with Lazarus team because, in order to provide native behavior they make it difficult to achieve consistent look and behavior on different platforms (which is just what I'm usually required from my customers). But I end up getting the worst of both worlds: inconsistent behavior where I need consistency, consistent behavior where I'd happily do without :-( and I doubt there's much source code around that relies on Kylix-specific behaviour. I'm among the unhappy former Kylix users, trying to carry on with a lot of unsupported Kylix code :-( Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Il 01/11/2012 11:43, Jonas Maebe ha scritto:
On 01 Nov 2012, at 11:40, Giuliano Colla wrote:
You may be right, but the try-except construct is there exactly to permit you
to handle those situations.
However I'd like to point out a significant inconsistency. Please give a look
to the following piece of code:
procedure TForm1.Button1Click(Sender: TObject);
var
MyFile: TextFile;
AName: String;
begin
AName:= 'BadName.txt';
AssignFile(MyFile,AName);
Reset(MyFile); Raises an Exception: EInOutError File not found
end;
That depends on the state of the {$i+/-} directive.
Which doesn't affect FileOpen behavior.
Giuliano
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to transfer data between applications?
On 01 Nov 2012, at 10:36, Sven Barth wrote: On 01.11.2012 03:30, Noah Silva wrote: Background threads not being able to touch the GUI, etc. makes it all but useless for many purposes. That you can't access the GUI is not a problem of FPC, but a design decision of the LCL (or better: the VCL which it is based upon). Or even better: the graphical toolkit the LCL is based on. E.g. on Mac OS X, Carbon requires that GUI manipulations happen from the main thread. Cocoa is more lenient, but even that one has a lot of restrictions and caveats when interacting with the GUI or graphics from secondary threads. Of course, the LCL can/could try to hide this from the programmer at the expense of a bunch of overhead. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 01 Nov 2012, at 11:50, Giuliano Colla wrote: Il 01/11/2012 01:07, Jonas Maebe ha scritto: I'm personally not a big fan of having different behaviour across platforms when it can be avoided without too much trouble, In general I agree with you. I often debate with Lazarus team because, in order to provide native behavior they make it difficult to achieve consistent look and behavior on different platforms (which is just what I'm usually required from my customers). In that case, using a framework that relies on a native widgetset is the wrong the approach. You would probably be happier with something like MSEGUI or fpGUI (well, apart from the fact that neither is VCL-compatible in any way). Trying to emulate Windows behaviour, or a mix of various platform-behaviours, on all platforms using native widget sets, now that would be a great example of the worst of all worlds. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 01 Nov 2012, at 11:53, Giuliano Colla wrote:
Il 01/11/2012 11:43, Jonas Maebe ha scritto:
On 01 Nov 2012, at 11:40, Giuliano Colla wrote:
Reset(MyFile); Raises an Exception: EInOutError File not found
end;
That depends on the state of the {$i+/-} directive.
Which doesn't affect FileOpen behavior.
No, because {$i+/-} dates back to Turbo Pascal and is specifically tied to the
standard I/O operations. The Delphi-ones only support result-based checking.
It's a completely new API with its own convention.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] convert floating point to bcd and vice versa
Hello, I need to convert floating point (Single and Double) to an array of bytes (BCD) and vice versa. Are there any existed implementation for it ? Thanks, Ido ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Il 01/11/2012 11:56, Jonas Maebe ha scritto: On 01 Nov 2012, at 11:50, Giuliano Colla wrote: In general I agree with you. I often debate with Lazarus team because, in order to provide native behavior they make it difficult to achieve consistent look and behavior on different platforms (which is just what I'm usually required from my customers). In that case, using a framework that relies on a native widgetset is the wrong the approach. You would probably be happier with something like MSEGUI or fpGUI (well, apart from the fact that neither is VCL-compatible in any way). Being stuck with a lot of Kylix code, I found it quite heavy a migration toward fpGUI (or MSEGUI). VCL and CLX are contiguous enough to allow a migration without too much hassle. Luckily even if the Kylix development is not possible on modern platform, it's still possible with a few kludges to run Kylix applications. One only needs to keep alive legacy platforms for development. Now I'm looking forward with interest to CustomDrawn, which should fit much better my needs, and I'm also trying to contribute, bounded by the limits of my available time (and capabilities). Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 2012-11-01 10:56, Jonas Maebe wrote: You would probably be happier with something like MSEGUI or fpGUI (well, apart from the fact that neither is VCL-compatible in any way). Which might not be a bad thing - depending on your project needs. VCL (and LCL) is too Windows centric, and has no place in Linux or Mac OS X platforms. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 2012-11-01 11:49, Giuliano Colla wrote: Being stuck with a lot of Kylix code, I found it quite heavy a migration toward fpGUI (or MSEGUI). Our company has invested lots of time and money in developing CLX (Kylix) applications. We have ported quite a few of them to fpGUI, and it was not that hard at all. - The UI is easy to recreate - The Kylix application code must be adapted no matter which GUI toolkit you use. Even so, most of the code can be reused as-is. fpGUI is different to VCL or LCL by design - but the general UI concepts are very similar. Everybody I have spoken to have said that picking up fpGUI is rather easy because of a very clear design and API. Kylix development is not possible on modern platform, it's still possible with a few kludges to run Kylix applications. One only needs to keep alive legacy platforms for development. Correct. We simply run Kylix IDE in a Red Hat 9 VM for continued development and application maintenance, but the applications themselves run just fine even on the latest Linux distros like OpenSUSE 12.2 or Ubuntu 12.10 - simply ship your app with the required *.so files and set the LD_LIBRARY_PATH before launching your app. We have Kylix apps that haven't been touched since 2003, and they still run on today's distros. Now I'm looking forward with interest to CustomDrawn, which should I've recently (about 3 weeks ago) looked at LCL-CustomDrawn. It is still years away form being usable in production code. Simple things like the default Cut/Copy/Paste popup menu in text widgets don't exist. Tabbing in reverse order between widgets don't work etc. The more you look the more issues you will find in LCL-CustomDrawn. This doesn't mean LCL-CustomDrawn in bad, it just means it is not near being ready to be used in real world applications. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Graeme Geldenhuys wrote: On 2012-11-01 10:56, Jonas Maebe wrote: You would probably be happier with something like MSEGUI or fpGUI (well, apart from the fact that neither is VCL-compatible in any way). Which might not be a bad thing - depending on your project needs. VCL (and LCL) is too Windows centric, and has no place in Linux or Mac OS X platforms. That is a matter of opinion, and other developers would argue the point. Over the years, Windows has gained a lot of things that were originally implemented by other OSes, as such it could be considered to be the standard bearer for workstation OSes. If that means that workstation UIs and widget sets are heavily influenced by Windows, that might be something best lived with. However I (for one) am strongly in favour of having at least one widget set that will run on top of X or even a frame buffer, discarding questionable cruft that has been pulled in by recent implementations of GTK etc. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
On 2012-11-01 12:33, Mark Morgan Lloyd wrote: That is a matter of opinion, and other developers would argue the point. When I say windows centric I mean LCL imitating the WinAPI in LCL-GTK2, LCL-Qt and LCL-Carbon. Most of the times that just doesn't fit. standard bearer for workstation OSes. If that means that workstation UIs and widget sets are heavily influenced by Windows, that might be something best lived with. As for UI. We have found with our company testing that as long as the UI is similar (no need to be identical to native UI), that is good enough for end-users to be able to use your application. Windows users have no problem learning to use iOS or Android devices or the millions of Web Apps (gmail, outlook.com, etc) - yet the UI is completely different to their desktops. Then you also get companies like Embarcadero[1] and projects like Qt[2] promoting the idea of custom looking UI to make your product stand out from the crowd. The ability to brand your application - a common marketing tactic. [1] VCL styles in the XE range of products, and Firemonkey styles. [2] Qt5 will have a new style, Forge, which will look identical on all platforms. However I (for one) am strongly in favour of having at least one widget set that will run on top of X or even a frame buffer, discarding I have renewed interest in targeting the Linux Frame Buffer, and with the same design changes, open fpGUI's design up for other possible backends like OpenGL, SDL, Cairo, Haiku etc with much less effort. A new branch of this development will start shortly. That would hopefully mean fpGUI can target Android and Raspberry Pi development with better performance from the GPU. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] convert floating point to bcd and vice versa
On 11/01/2012 12:22 PM, ik wrote: Hello, I need to convert floating point (Single and Double) to an array of bytes PByte(@YourVariable)[0] through PByte(@YourVariable)[SizeOf(YourVariable)-1] ? Or, if you have an array of SizeOf(YourVariable) bytes, you could do something like this: Move(YourVariable, YourArray[0], SizeOf(YourVariable)) (note that you might want to take endianess into account, but I don't know if this applies to floats as it does to integers) -- Ewald Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross-compiling FPC trunk to Win x64 fails using fpcup - make file problems?
Hi list, I wonder if the problems below are caused by wrong make files or problems in fpcup: (fpc trunk, Windows; fpcup compiles fpc x86+Lazarus fine, then tries an x64 cross compile followed by an LCL cross compile): Compiles along for x64 as shown here: C:/development/fpctrunk/compiler/ppcrossx64.exe -Twin64 -Px86_64 -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -FDC:/development/fpctrunk/bin/x86_64-win64 -FE. -FUC:/development/fpctrunk/rtl/units/x86_64-win64 -gw -gl -dx86_64 -dRELEASE ../inc/lnfodwrf.pp make.exe[3]: Leaving directory `C:/development/fpctrunk/rtl/win64' but then it starts to try i386 output:!?!? make.exe[1]: Entering directory `C:/development/fpctrunk' C:/development/fpcbootstrap/make.exe -C packages all make.exe[2]: Entering directory `C:/development/fpctrunk/packages' C:/development/fpcbootstrap/make.exe -C fpmkunit bootstrap make.exe[3]: Entering directory `C:/development/fpctrunk/packages/fpmkunit' C:/development/fpcbootstrap/gmkdir.exe -p units_bs/i386-win32 C:/development/fpctrunk/compiler/ppc.exe src/fpmkunit.pp -n -FuC:/development/fpctrunk/rtl/units/i386-win32 -FuC:/development/fpctrunk/packages/paszlib/units/i386-win32 -FuC:/development/fpctrunk/packages/fcl-process/units/i386-win32 -FuC:/development/fpctrunk/packages/hash/units/i386-win32 -FUunits_bs/i386-win32 -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src -Fi../fcl-process/src/win -Fu../fcl-process/src -Fi../fcl-process/src/win32 -Fi../fcl-process/src/dummy -gw -gl make.exe[3]: Leaving directory `C:/development/fpctrunk/packages/fpmkunit' C:/development/fpctrunk/compiler/ppc.exe fpmake.pp -n -FuC:/development/fpctrunk/packages/fpmkunit/units_bs/i386-win32 -FuC:/development/fpctrunk/rtl/units/i386-win32 -gw -gl Fatal: Can't find unit process used by fpmkunit Fatal: Compilation aborted ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiling FPC trunk to Win x64 fails using fpcup - make file problems?
On 01 Nov 2012, at 16:04, Reinier Olislagers wrote: I wonder if the problems below are caused by wrong make files or problems in fpcup: (fpc trunk, Windows; fpcup compiles fpc x86+Lazarus fine, then tries an x64 cross compile followed by an LCL cross compile): It's probably the same problem you had last time: the fact that make distclean does not work properly. In the mean time, it has been partially fixed in that running make distclean twice right after each other does clean everything. Try that and building then. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiling FPC trunk to Win x64 fails using fpcup - make file problems?
On 1-11-2012 16:11, Jonas Maebe wrote: On 01 Nov 2012, at 16:04, Reinier Olislagers wrote: I wonder if the problems below are caused by wrong make files or problems in fpcup: (fpc trunk, Windows; fpcup compiles fpc x86+Lazarus fine, then tries an x64 cross compile followed by an LCL cross compile): It's probably the same problem you had last time: the fact that make distclean does not work properly. In the mean time, it has been partially fixed in that running make distclean twice right after each other does clean everything. Try that and building then. Thanks Jonas - meanwhile I did implement a radical distclean alternative. You're right, I should really check again with a clean slate (i.e. clean svn checkout). Anyway, great news about the double distclean fixing things, I can fairly easily use that in fpcup as a workaround rather than trying to duplicate things! Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] convert floating point to bcd and vice versa
On Thu, Nov 1, 2012 at 3:17 PM, Ewald bloody.middlefin...@yellowcouch.org wrote: On 11/01/2012 12:22 PM, ik wrote: Hello, I need to convert floating point (Single and Double) to an array of bytes PByte(@YourVariable)[0] through PByte(@YourVariable)[SizeOf(YourVariable)-1] ? Or, if you have an array of SizeOf(YourVariable) bytes, you could do something like this: Move(YourVariable, YourArray[0], SizeOf(YourVariable)) (note that you might want to take endianess into account, but I don't know if this applies to floats as it does to integers) Thanks -- Ewald Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-compiling FPC trunk to Win x64 fails using fpcup - make file problems?
On 1-11-2012 16:11, Jonas Maebe wrote: On 01 Nov 2012, at 16:04, Reinier Olislagers wrote: I wonder if the problems below are caused by wrong make files or problems in fpcup: (fpc trunk, Windows; fpcup compiles fpc x86+Lazarus fine, then tries an x64 cross compile followed by an LCL cross compile): It's probably the same problem you had last time: the fact that make distclean does not work properly. In the mean time, it has been partially fixed in that running make distclean twice right after each other does clean everything. Try that and building then. Thanks, Jonas, changing fpcup to run make distclean 2x seemed to fix this. (Leaving some LCL x64 problems but that's another story) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why opening a file for write fails in fpc 2.6?
Il 01/11/2012 13:09, Graeme Geldenhuys ha scritto: On 2012-11-01 11:49, Giuliano Colla wrote: Now I'm looking forward with interest to CustomDrawn, which should I've recently (about 3 weeks ago) looked at LCL-CustomDrawn. It is still years away form being usable in production code. Simple things like the default Cut/Copy/Paste popup menu in text widgets don't exist. Tabbing in reverse order between widgets don't work etc. The more you look the more issues you will find in LCL-CustomDrawn. This doesn't mean LCL-CustomDrawn in bad, it just means it is not near being ready to be used in real world applications. I fully agree with you. CustomDrawn is at a very preliminary stage. I'm not even sure that the current implementation of LCL-CustomDrawn will ever lead to a usable thing. The approach is a brute force one: just one window for form, and redraw all the widgets on the full form each time something changes. Even cursor blinking is achieved by redrawing the full form. You can imagine how slow everything becomes when your window has a reasonable size, and is populated by a reasonable number of widgets. That's the problem of many open source projects. They're mostly created by developers which think to their applications, and take care primarily of what they need. CustomDrawn was originated by Felipe, who's mainly interested in his Magnifying Glass project. Once he manages to make it work on his target platform, he's more or less finished. But the same holds true for me. In my applications I don't use neither the Cut/Copy/Paste popup menu, nor tabbing (forward or reverse), so you may bet that if I contribute to CustomDrawn, be it the current implementation or a fully new one, those features will end up quite low in my ToDo list. That's the main reason I look with more interest to LCL than fpGUI. Simply because LCL provides already implemented much more features I need with respect to fpGUI, (at least up to the last time I evaluated fpGUI). When the time comes that I'm really forced to abandon Kylix, then I'll try to see if it's more work to implement what I need (and which won't certainly be there) on CustomDrawn (most likely stealing quite a lot from fpGUI), or to contribute to fpGUI, in order to get what I need. For the moment I've devoted the little time I have available to some contributions to CustomDrawn, because I have more confidence with LCL environment, and this makes things easier for me. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Best way to transfer data between applications?
I've added a source zip to the downloads section of the pascal-actor-model google code page. while it cannot do runinbackground(procedure) as you want, i believe it can be mimmicked using the TCreateInstanceAndConfigActorMessage message and a functor actor (functor is a kind of object that holds functions/methods, its a way to mimmick first class functions in a non-functional language like pascal because it allows to pass function references/contexts around as classes). This message can create an actor and pass config info to it in one go, with guaranteed message delivery and correct sequence. (This avoids the unbounded non-determinism problem). Actors usually sit in background doing work or idling. Theres an idle procedure that can be overridden and you can write message receiving methods that are triggered upon specific messages. Actors wont stop until told to stop. There are a lot of shortcut procedures in the actors.pas unit that avoids too much verbosity in the code. If an actor should stop by his own volition, you simply have to set Running to false after all needed work is done : Running = False; There is a request/reply model of message passing, but it should be avoided at all costs, because it basically stops the thread until the receiving thread replies (or the timeout expires), the end result is an almost sequential execution (Makes no sense usually). The main thread can wait for messages comming from the actors (with timeout). Its not an active wait (in the sense of a loop) but a passive wait done using TEventObject. Usually the correct point to wait for messages comming from the background actors is inside the application idle loop, via the idle timer. Example : lMessage := ReceiveMessage(500); // waits 500ms for a message to arrive To send message to actors : SendMessage(lMessage); In your example about saving files in background, you can write a file writer actor and send the content to him as a message. It will happly save the data to the file while the main thread is free to do whatever it should do, in parallel. I believe i should write documentation but i dont know how to use pasdoc yet :P 2012/11/1 Noah Silva shir...@galapagossoftware.com: Hi Jorge, Even if so, it won't solve many of the other problems I am trying to solve. On the other hand, do you have a Tarball available for download somewhere? (I checked the Google Code page, but no downloads, only SVN access it looks like). Thank you, Noah Silva 2012/11/1 Jorge Aldo G. de F. Junior jagf...@gmail.com i reiterate that my Pascal-Actor-Model can do exactly what you are saying... writing a save file in background type of actor is trivial, and the synchronization is already done... 2012/10/31 Noah Silva shir...@galapagossoftware.com: Hi Aldo, Well it's not just synch problems with threads, I've found threads to not be so reliable under FPC for anything but trivial test cases. Sometimes the program is incredibly slowed when using threads. Also, Unix and Windows have to be treated differently, etc. - which is not entirely FPC's fault. Making separate applications gives a number of advantages (which I listed in my last mail). The need to send data structures back and forth is the only real disadvantage - but that's just trading for synchronization issues. As an aside, threads are one area where it seems ObjC has a huge advantage. I wish there was a way to just say something like RunInBackground(procedure) in FPC. Background threads not being able to touch the GUI, etc. makes it all but useless for many purposes. Of course for scientific computing type applications where problems can be partitioned neatly, threads make perfect sense and work relatively well. For things like I want to save this file in the background while the user continues to use the word processor, I've found they aren't anywhere near worth the trouble to implement in FPC - yet. For example, if I want only one instance of a daemon running, then I have to make it a separate process (reasonably anyway). If I want it to be 64bit, but the GUI has to be 32bit, then it has to be a separate process, etc. I will take a look at your framework, because I am interested in all sorts of new developments, but it's unlikely I will re-code everything to use a particular design pattern or framework. The original question I meant to ask was basically Is there an easy/mostly automatic way to transport data structures between processes, and from all the discussion on this list - the answer seems to be no. Encoding is one piece, data transfer is one piece, and the glue in-between (Class factories, etc.) is something one probably has to put together themselves. Either way, it makes everything more complicated to do something that is in principle relatively simple. Thank you, Noah Silva 2012/10/31 Jorge Aldo G. de F.
