Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/18/2016 12:40 PM, Ondrej Pokorny wrote: No, the equation includes everything along with everybody's interests. Example: You spend X hours to write documentation for A that saves Y hours to Z users that otherwise had to study the code. Then you can compare X to Y*Z. That was my initial proposal leading to "extremely hard to define", as (due to no intended and hence measurable revenue) the developers don't have any idea about the count of users and the effort they need to get their work done. As an extreme you would say: no documentation at all is best, as that means no hours to create it and there supposedly will be at least a single user who is able to make some small benefit from the project and hence the positive ratio is infinite . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/15/2016 08:50 PM, Florian Klämpfl wrote: It is very very simple for a non-profit/OSS project: more man hours earned back than those which were invested. that would completely ignore the interest of the users of the project. (Which in commercial projects can be measured in the revenue.) So not a friendly attitude at all. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/15/2016 03:30 PM, Marco van de Voort wrote: And an investment in manhours to make that happen that IMHO will never be earned back. I can't contradict. But in fact "earned back" is extremely hard to define when comparing two far distant edges of a non-profit project. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/15/2016 03:29 PM, Marco van de Voort wrote: As said: I (unsuccessfully) tried. So you can't operate a text editor? I unsuccessfully tried to create an environment that lets me see the modified help text (we already did discuss this some years ago). AFAIR, I did send (you ?) a modified help text for "CheckSynchronize()" (in fact a "patch" as it was the complete small chapter). (Of course this was not for the Lazarus help files, but RTL.) Maybe it now is included. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
On 04/13/2016 01:41 PM, Mattias Gaertner wrote: Why do you think that? If that would be the way the function StringCodePage would need to check if the encodeing imposed on the string (e.g. a String constant) (i.e. the final meaning of CP_ACP) would be the same as the value of the variable DefaultSystemCodePage which has been set at this start of the program. I looked at the code of StringCodePage, and it does not do so. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
On 04/13/2016 11:08 AM, Sven Barth wrote: The code pages that are relevant here are only single byte code pages (e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store UTF-16 data. StringCodePage(s) with an unqualified String return 0 (which is "CP_ACP", and seemingly means "Default"). But how to determine what encoding this default is, if (as we found) it can't be DefaultSystemCodePage and can be UTF16, which is dynamic, while the default for unqualified strings is static and *never* UTF-16 ? Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
On 04/13/2016 11:08 AM, Sven Barth wrote: The code pages that are relevant here are only single byte code pages (e.g. CP1252) or UTF-8, *never* UTF-16 as a AnsiString can not store UTF-16 data. I see. And using 8 bit encoding as the brand for not the explicitly user-defind "String" type does make sense for a compiler that is supposed to create executables for multiple OSes does make prefect sense. But AFAIK, Unicode aware Delphi uses UTF16 for the not the explicitly user-defind "String" type. (While AFAIK, not Unicode aware Delphi can't handle UTF8.) So this is not compatible to either of them. In fact I am not asking for such compatibility (let alone that the two Delphi variants are even more incompatible to each other), but we need to be aware of the issue. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
BTW. according to the said wiki page (at the end of the page) I am wrong assuming that DefaultSystemCodePage is a constant introduced by the compiler. Now I still don't know whether/how the default encoding for the type "String (which is different from DefaultSystemCodePage according to the wiki) is depending on the arch/OS the compiler is built for. (I only tested on Linux and here it rather obviously is UTF8. I assume on Windows it's UTF16 for Delphi compatibility). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] wiki page "Better_Unicode_Support_in_Lazarus"
There was a discussion in the fpc -pascal mailing list about a question a user (tobiasgiesen) asked (among other things) about storing strings of a certain encoding brand in a TStringList. Here Juha recommended to read this page -> http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus Now I did some test and asked ob that list and found that the default code page for the type "String" and with that the definition of of TStrings and with that the working of TStringList.Add and friends depends on the setting of "DefaultSystemcodepage". I understand that DefaultSystemcodepage is set when compiling the compiler (e.g. to UTF-8 on Linux and (supposedly) to UTF-16 in Windows). So I suppose Lazarus can't do anything about that. Or are there plans to use different compilers /RTL variant to allow for "Better_Unicode_Support_in_Lazarus" (project depending potentially better performance or better portability and Linux, explicitly using e.g. native pos() results instead of introducing CodePointPos(), ...) ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 09:34 PM, Marco van de Voort wrote: Maybe you do remember that (with your help) I once tried to contribute to the fpc help. Sorry, can't remember any patches, so it can't have been too serious! As said: I (unsuccessfully) tried. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 09:28 PM, Marco van de Voort wrote: It is the conjecture that the content will actually improve because of it that I find highly doubtful. Absolutely agreed ! An unmanaged Wiki would be highly dangerous. A complete managing system on top of the standard Wiki software would be required. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 01:37 PM, Graeme Geldenhuys wrote: FreeBSD has. OSX is based on BSD, So maybe this is not really Volunteer driven :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 01:12 PM, Graeme Geldenhuys wrote: ... and we are talking about Lazarus documentation here Of course at this location we are. But a documentation decently usable by the Lazarus "customer" needs to cover (at least) IDE, LCL, the language, the compiler, RTL, and the most common packages. Anyway: just dreaming. Volunteer driven systems never get there. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 12:30 PM, Graeme Geldenhuys wrote: What's so hard about this: Maybe you do remember that (with your help) I once tried to contribute to the fpc help. I failed to do this in a decent way (I finally sent in the text per mail, maybe it had been included in the next release of the fpc help (at least a year later). I id not dare to check. I'm not going to try to contribute to the help until I'm retired (which is not that far away ;-) ). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 12:18 PM, Graeme Geldenhuys wrote: Currently with the wiki, rubbish can be added and no review is done! The wiki is the best of the worst. Of course (and as I said) the wiki for the help needs to be managed. The writer needs to see what he did (at best integrated in the help view of his local IDE), but for others to see (i.e. a release) one of the "powers" need to review it . Of course the standard Wiki software does not provide the necessary features (such as only "personal" update until review/release, enforcing certain rules for providing decent conversion to the target help text formats. That is why I said: a lot of work. No it does not make much sense to discuss this here, unless somebody with a lot of spare time stands up and says "I'll take it on" ;-) . - Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 11:26 AM, Graeme Geldenhuys wrote: Yes, it's called "fpdoc" and have been around for years! Of course I do know this. I did play with it. Its a kind of "Write only memory": you don't see what you did. (Unless you go a very hard way to be able to compile the complete help system on your local PC.) It's a perfect means to shy away any volunteers. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/11/2016 11:26 AM, Graeme Geldenhuys wrote: Wiki's are only good for knowledge base - adding random thoughts as pages - loosely linked together by cross-links. It is terrible as a help format/medium. While I do see your point I can't think of any other authoring system that might be able to allow for possible volunteers to do contributions (as has been the wish of some previous posters). Of course strict rules would be needed to be defined and (at best automatically) be enforces to allow Wiki pages to (automatically) be converted to help content. That is why it's obvious that setting up such a system would be a lot of work and would bind a lot of manpower for a decent amount of time. So supposedly no chance. :-( . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Bashing the developers
On 04/09/2016 04:24 PM, Vojte(ch C(ihák wrote: Therefore I'd like to say here (loudly) that I was always (and I'm now) happy in Lazarus and FPC community (forum, ML, bugtracker) and developers and other people always helped when I needed it. Thank you. +1 !!! While of course the Lazarus system suffers from some historical shortcomings, imported from several Delphi versions and introduced by the IMHO not perfectly drawn line between the fpc RTL and the LCL, everybody needs to be happy that there is Lazarus in the rather great state as it is. Of course non - standard targets (like deeply embedded stuff, Rich internet applications, just to name a few) are less actively supported than the normal Windows/Linux/Mac Desktop. But work is done at many frontiers. Thanks AGAIN, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus Digest, Vol 99, Issue 32
On 04/09/2016 04:07 PM, Giuliano Colla wrote: Because without a minimal amount of documentation all this valuable work risks to be useless, because: - nobody except a few core developers know of its existence - nobody except the developer itself knows how to use it There already have been lots of discussions on a reform of the help system that (e.g. by using a single managed Wiki exclusively as the root of the articles) is open for volunteers to provide fixes and additions and actually see "live" what they did without waiting for the next Lazarus release. AFAIK this is a too great task to be considered doable in near future. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
On 04/08/2016 02:22 PM, Sven Barth wrote: It should either be in /etc/fpc.cfg or ~/.fpc.cfg there is one in /etc/fpc.cfg it's rather long but it does include the lines -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/* -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd22 i.e. without the /local". in fact in /usr/lib I do have /usr/lib/fpc/3.1.1/units/i386-linux/ "fpc" comes up with Free Pascal Compiler version 3.1.1 [2016/04/05] for i386 so $fpcversion = 3.1.1 and $fpctarget = i386-linux might be correct. *Later:** ** **deleting a seemingly broken ~/.fpc.cfg file **did the trick. ** ** **Thanks a lot for your help!** * -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
On 04/07/2016 04:30 PM, Michael Van Canneyt wrote: I have this in my fpc.cfg, it is 2 lines long: In my lazarus/trunk dir (created by svn), there is no fpc.cfg file. Do you suggest it should ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
On 04/07/2016 04:33 PM, Mattias Gaertner wrote: On Thu, 07 Apr 2016 16:25:26 +0200 Michael Schnell <mschn...@lumino.de> wrote: On 04/07/2016 04:19 PM, Mattias Gaertner wrote: What -Fu paths do you have in your fpc.cfg? I did suppose something like this. Am I supposed to manually edit this file even for the unmodified svn d/l ? FPC does not care where the sources are coming from. You need a valid fpc.cfg, usually /etc/fpc.cfg . I do have this. Here multiple times $fpcversion and $fpctarget are used which supposedly are provided by the compiler. Can it be that the compiler uses wrong values for those ? How can I check that ? (I did make FPC=`pwd`/compiler/ppc386 install INSTALL_PREFIX=/usr and hoped that would provide for this, and I suppose it did some time ago, as ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
On 04/07/2016 04:19 PM, Mattias Gaertner wrote: What -Fu paths do you have in your fpc.cfg? I did suppose something like this. Am I supposed to manually edit this file even for the unmodified svn d/l ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
On 04/06/2016 09:47 AM, Michael Schnell wrote: It happened to me (again) :(. I resolved a lot of unit referenced to fpc RTL units by defining links for the files in /usr/lib/fpc/3.1.1/units/i386-linux/rtl (I suppose I should not do that this way, but I don't know another :( ) But later in the make process LCL units and resource files are requested. I could resolve a lot of references creating links in some LCL directory, but at some point this stopped working. Is it even possible to compile Lazarus with fpc 3.1.1 ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Cant compile the IDE with the most recent fpc (3.1.1)
It happened to me (again) :(. After upgrading fpc to the latest svn version, I can't compile the latest svn version of Lazarus. The problem (first) occurs with RegisterFCL. (Currently the error is "Can't find unit db used by RegisterFCL", but there had been other units before it did not find. For a test I moved two of the to the dir it in fact searches for fpc units: -Fu/usr/lib/fpc/3.1.1/units/i386-linux/rtl ) Seemingly a unit search dir for some of the fpc stuff is missing. How to tell the Lazarus make process about those ? thank, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Testing Rapberry Pi 3 performance
[fpc-devel] Bug 29760 on FPC 3.0 Win64 -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
On 04/01/2016 01:23 PM, Sven Barth wrote: "it" meant the GUI, I see. I misunderstood that with "only with Windows Store Apps" you wanted to exclude "normal" Windows services. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
On 04/01/2016 01:13 PM, Sven Barth wrote: However classical WinAPI can't access it. You can access it only with Windows Store Apps and then only one at a time. Though you can runs these platforms headless as well without problems. That is not true (and a very common misconception). A colleague of min already did run Windows services done with Delphi on Win IoT. The complete Windows API seems to work if you don't use GUI functions (which would be called widgets in Linux). Timers and TCP/IP do work . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
On 04/01/2016 08:58 AM, Michael Van Canneyt wrote: Some years ago they announced that the sever could run "without GUI". In fact "Windows IOT" is windows 10 without the GUI API (i.e. you can run Aervicesm but you can't run applications). So this is viable/sensible/possible in the end. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Xamarin becomes free and open-source
On 03/31/2016 08:30 PM, Anthony Walter wrote: I thought this was newsworthy and of interest to us: Am I wrong feeling that the (IMHO rather viable) CIL (aka".Net") initiative, once launched by Microsoft is declining due to the ubiquitous rise of Java ? In fact Microsoft took Silverlight to grave, recently I did not hear much about Mono and Moonlight, Open sourcing Xamarin to me seems just a sign that nobody can earn any money with same, so it's just another indication of the thesis. The fpc community never seemed to have much interest for CIL (Embarcadero started two questionable attempts with "Delphi for .Net" and the acquisition of Oxygen). fpc instead seems to be rather far into creating Java/Dalvik Byte/Word code -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Testing Rapberry Pi 3 performance
On 03/25/2016 12:17 PM, Graeme Geldenhuys wrote: A word of caution, there is a major bug in FPC 3.0 regarding floating point values (see the FPC mailing list), so I wouldn't recommend anybody upgrade to FPC 3.0 at this point - at least until 3.0.2 is out. This issue has been fixed in FPC Trunk already though. They say: "This happens only on Win64 with FPC 3.0 " -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Testing Rapberry Pi 3 performance
On 03/23/2016 03:32 PM, David Taylor wrote: But with "only" 1 GB of memory, 64-bit may be no better than 32-bit. The hardware, though, is 64-bit with the advantages that brings in memory access speeds. I've seen nothing of the Raspberry Pi cards which I use which would benefit from a 64-bit version. I do know that with X86 the memory efficiency with 64 is a lot worse than with X32 and might result in speed degradation due to worse cache usage. I have no knowledge if this is similar with aarch64. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Testing Rapberry Pi 3 performance
On 03/23/2016 03:00 PM, David Taylor wrote: Using the RPi-3 is a significantly more pleasant experience than the RPi-2, even just headless when compiling things. Highly recommended. I did have some minor issues with Jessie, with the serial port on the RPi-3, and with gpsd not suto-starting. But still no "official" 64 bit OS, yet :-( -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/18/2016 05:59 PM, Alfred wrote: Hello, I would like to inform you that Lazarus / FPC runs smooth on an Odroid-C2 under aarch64 (arch linux). Proof: https://drive.google.com/file/d/0B96fg3TpL5RDWnJiMUwyQ21hM00/view?usp=sharing GREAT !!! Many thanks for the good work !!! +1 ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Firefox
On 03/04/2016 07:50 PM, Larry Dalton wrote: Is anyone running a lazarus program on a Firefox browser? What is this supposed to mean ? AFAIK, there is an fpc to java script compile somewhere, but I don't know the state Not so closely related to Firefox: there also is an fpc to java byte code compiler (designed for doing Android apps), but I don't know the state either. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/03/2016 07:18 PM, Florian Klaempfl wrote: I ordered also one in the hope using it to play with fpc aarch64. But currently it does not look good as it seems that it is not only a matter of the kernel but also the firmware. At least I didn't unwrap mine yet because of this, without aarch64 support I see no use for me in it. A friend of mine uses BeagleBone and he always upgrades the devices to a standard Debian distribution. I don't see why this should not be possible / viable with RPI . And I suppose there is an aarch64 Debian. (In any case it should be possible to build it (a time consuming process ;-) ) So this hold run on a RPI3 for testing purpose. Supposedly some 64 Bit drivers for certain hardware on the RPI might be no yet available. but this should not hamper fpc / Lazarus testing . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/03/2016 12:33 PM, Bo Berglund wrote: And they claim not so much is to be gained with 64 bit mode since RAM is just 1GB (currently). I suppose similar to X86-64, with aarch64 the speed advantage vs 32 bit is debatable. Some applications that really do 64 bit calculation might get a lot faster Some applications that use loops with a large code footprint might get slower, as the 64 bit code might be bigger and hence more cache loads might be necessary. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/02/2016 05:09 PM, Michael Ring wrote: AFAIK This is the default mode on RPi for now, same for ODroid C2, it also currently runs a64 cpu with a a32 kernel, 'real' 64bit support will come later. So obviously the a64 hardware can run a32 code :-) . Hence I suppose an a64 Linux distribution will come with the ability to run a32 user programs (but I did not yet read about this) . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/02/2016 05:09 PM, Michael Ring wrote: AFAIK This is the default mode on RPi for now, same for ODroid C2, it also currently runs a64 cpu with a a32 kernel, 'real' 64bit support will come later. So Alfred will only be able to run 64 Bit Lazarus programs after updating the OS to a 64 bit version. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Aarch64 as CPU target for RPi3 with Linux as OS
On 03/01/2016 09:45 PM, Alfred wrote: While preparing fpc(laz)up for my RPi3, Choosing a64 as CPU target I am exited to see that there is a very cheap testing platform for a64 arch ! Question: can a64 hardware and Linux run a32 programs (like X64 systems can run X32 programs) ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Microsoft Acquires Xamarin
On 02/24/2016 09:59 PM, Dmitry Boyarintsev wrote: Skepticism: what software became better after acquisition by Microsoft? Sarcasm: Delphi Language became C# -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Mode DelphiUnicode
Please see the forum thread "non Unicodode application" (and don't reply to a thread message wit ha new topic). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?
On 02/15/2016 07:23 PM, Giuliano Colla wrote: The result is to make Application.ProcessMessage not 100% reentrant, because of a Glib2 bug. Would you suggest not to handle "the same" event ? How should you detect that its the event already in the works or the next occurrence ? In the case I've stumbled into, when next message eventually comes (after 1722 iterations over the previous one) the program crashes for a SEGFAULT, most likely generated by a stack overflow. Anyway, IMHO it's not a good idea to fight a (potential) bug (in "Glib2" whatever this exactly means) by implementing a completely queer behavior in Application.ProcessMessage. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/15/2016 12:03 PM, Juha Manninen wrote: The real complexity of Unicode is beyond encodings Yep.This I learned from the discussions. E.g. even with a technically perfect UTF string implementation, the problem that exactly the same printable text can be encoded in multiple ways can't be overcome. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?
On 02/13/2016 12:27 PM, Giuliano Colla wrote: At least under Qt widgetset, it may happen that calling Application.ProcessMessages from within a Message Handler will cause the same message which was being processed to be processed again, the handler called again and Application.ProcessMessages being called again, thus originating an endless loop and a consequent stack overflow. When calling Application.ProcessMessages from within a Message Handler the *next* event in the event queue should be handled. If *the*event*already*being*handled* pops up again, that would be a bug. But of course "the same" message might have pushed by some thread and also needs handling. Here the same handler might be called recursively. This of course does need additional stack space, but not infinitely . The result is to make Application.ProcessMessage not 100% reentrant, because of a Glib2 bug. Would you suggest not to handle "the same" event ? How should you detect that its the event already in the works or the next occurrence ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 06:13 PM, Juha Manninen wrote: On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell <mschn...@lumino.de> wrote: I think that it is *very* desirable to provide configuration options to provide full backwards compatibility (while still allow to use as many of the new features as possible when explicitly writing coding for this). Uhhh... Michael Schnell, how is it possible you behave like a complete newbie with FPC's String encoding issues, after so many years of arguing about it in various mailing lists? because of this: On 02/12/2016 03:50 PM, Michael Van Canneyt wrote: Then you are, as they say, f*d... On 02/12/2016 06:13 PM, Juha Manninen wrote: ... were answered in the wiki pages I linked to you, and they are obvious after just minimal testing. This is what I did assume and just wanted a confirmation for, so that I can send this information in a compact and approved form to the said friend . If you find a bug then let us know, otherwise please show some positive attitude. The new UTF-8 system "just works" in most situations. Sorry I did not intend to express any negative attitude, but on the contrary am very happy that Lazarus/fpc can provide exactly that functionality (8 bit Strings - including TStrins, pos , etc - in a 64 Bit application) that (AFAIK ) is not possible with Delphi (which I don't have). I remember you repeated the same arguments against FPC's new String type in FPC lists during many years again and again. Let's not do the same here. IMHO your memory is incomplete on that behalf. On the contrary I argumented against the "intermediate" Lazarus way of using UTF8 *without* "new strings" (which - as you correctly say, seemingly is exactly hat my said friend would like to use (but here, he does not care about the LCL GUI functions). In fact I always was pro "New Strings", Later I argumented against the way New Strings have been implemented (very close to the "sloppy" way Delphi does this), which (among other IMHO not really good stuff) does not provide for using TStrings for "uncoded" / "unkowinly coded / "transparently coded" 8 bit strings. As you might know I did a description of an IMHO better way to do this here: http://wiki.lazarus.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] non Unicodode application
Hi Experts, A friend of mine wants to port an application from Delphi 7 to a be a Lazarus 64 Bit Windows application. This (huge) application only features a very limited GIU, but uses strings lot for "uncoded" characters, going in and out via TCP/IP. Any automatic type conversion would kill the application. So it would be necessary that fpc is configured to use the (old) 8 bit Strings. These might be used with UTF8 encoding for the GUI stuff (and for some limited locations in the business-code with *explicit* conversion). Is this possible with the current version of Lazarus ? As I lost the clue on the planned path regarding code-aware strings: will this be possible with future versions of Lazarus ,as well ? Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?
On 02/12/2016 03:17 PM, Mattias Gaertner wrote: IMHO, Michael, you should not redefine words. It confuses people. Reentrant means it can be called again, while it is still running. It does not need to be thread-safe. Sorry that was not me. The subject here is " thread save " ,so I tried to explain exactly the difference you mention. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote: Just use RawByteString as stringtype for all parameters and variables in calls where you don't want code page conversions to occur. This would mean rewriting the complete application. This obviously is not desired . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:
Tish...
{$define String:=RawByteString}
and you are done.
I'll let him know...
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:
On Fri, 12 Feb 2016, Michael Schnell wrote:
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:
Just use RawByteString as stringtype for all parameters and variables
in calls where you don't want code page conversions to occur.
This would mean rewriting the complete application. This obviously is
not desired .
Tish...
{$define String:=RawByteString}
and you are done.
I don't thinks this is true.
Many built-in functions and RTL functions and classes (such as "pos" and
"TStrings") explicitly use "string" as parameter and property type. If
they are not re-compiled they will not work at all or not as expected .
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?
On 02/10/2016 10:12 PM, C Western wrote: My understanding is Application.ProcessMessages has to be reentrant ... As calling Application.ProcessMessages is only allowed from the main thread it does not need to be reentrant = thread-save. Of course it can be called recursively and it hence is reentrant in that meaning. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 02:57 PM, Juha Manninen wrote: And yes, often the same arguments were repeated by the same person who started this thread. At the time I did those researches and discussions, my colleagues here were interested in porting their Delphi application to Linux using Lazarus and I tried to help. They finally decided do delay the task, and now, as we have Windows 10 IOT, they supposedly are not interested any more at all, as Delphi applications (services without a GUI) do run on Win 10 IOT Now a friend of mine is faced by a similar task. But here he wants to keep a (small) GUI and he does not want to go for Linux but for 64 Bit. But the challenge is rather similar, and again there *might* be hope to convert a professional application and programmer team from Delphi to Lazarus. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 05:37 PM, Dmitry Boyarintsev wrote: In this particular case (of porting Delphi 7 code straight to FPC 3.0.0) is a matter of backward compatibility. Yep. Not only to D7, but also to legacy fpc and Lazarus versions, that (as we all know) were modeled after D7 (and friends). I think that it is *very* desirable to provide configuration options to provide full backwards compatibility (while still allow to use as many of the new features as possible when explicitly writing coding for this). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
This does sound good. :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 05:23 PM, Mattias Gaertner wrote: If your friend use string literals in Delphi they are encoded in system code page. Here might be some traps. He will easily be able to handle this . Thanks a lot ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:54 PM, Juha Manninen wrote: Sure there is hope. See the new UTF-8 support: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus I'll let him know... And of course I will take read this myself, too. In fact he does not want "Better_Unicode_Support" but *no_unicode_support* ;-) But maybe this is possible somehow The only problem comes if you depend on Windows system codepage a lot. That's why there is : http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode The code does not depend on Windows system codepage at all. The just receives text (characters) from TCP/IP, converts it using databases and some "embedded"/"realtime" conditions and sends it out via TCP/IP. Not windows or other codepages "implicitly" involved. If some o the work needs codepage conversion, this is done explicitly in user code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:54 PM, Juha Manninen wrote: Both Delphi and FPC now support 64-bit. I don't know how that relates to dynamic String encoding. . http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus AFAIK, any 64 bit Delphi forces UTF-16 Unicode and cant do what is described in the wiki page you mention. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:54 PM, Juha Manninen wrote: Sure there is hope. See the new UTF-8 support: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus This page says: "This page covers Unicode support in Lazarus programs (console or server, no GUI) and applications (GUI with LCL) using features of FPC 3.0+. " "RTL with default codepage UTF-8" That would mean that the type "String" is 8 Bit ? That would mean that 8 bit Strings are used in TStrings and hence in TStringList ? That would mean that (e.g.) storing 8 bit "String"s in a TStringList would not do any conversion at all ? And it would mean that pos() and friends work on 8 bit Strings (and wist simple byte-positions and length) ? If string constants and strings coming from and going to the GUI are implicitly converted, I suppose this is manageable. Is all this is here to stay, I think my friend could use Lazarus and fpc for his task. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:55 PM, Mattias Gaertner wrote: True, although the wording might be misleading. FPC 3.0+ does not arbitrarily change encoding of strings. That's why the LCL can use UTF-8 in AnsiStrings even without the new UTF-8 mode. It then works pretty similar to FPC 2.6.4. This is exactly what I seemed to remember from multiple discussions in multiple forums, and this is why I recommended my friend to take a look at Lazarus/FPC. the LCL *can* use UTF-8 How to set it to do so ? (I may be able guess, but as I said I am asking for a pal who is rather new to Lazarus/FPC, so explicit pointers are appreciated. ...) even without the new UTF-8 mode. How to set this mode when compiling with Lazarus ? What mode do you think is more appropriate when most work is done on strings that just have no or an unknown encoding ? Thanks a lot ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] non Unicodode application
On 02/12/2016 03:53 PM, Mattias Gaertner wrote: Your friend can use the LCL for the GUI with disabled UTF-8 mode. Sounds great ! He has to check (convert) the strings between his TCP/IP code and the LCL controls (e.g. UTF8ToSys). As he has only a small GUI this should be easy. No problem. The current D7 code does this,anyway, it just converts to/from ANSI with the appropriate code page,and now would need to convert to/from UTF8 . The new UTF-8 mode is easier for new projects. Many old projects still use the old mode. So chances are high that it will be supported the next years. Am I correct assuming that "The new UTF-8 mode" is this http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus ? We will try to find out if this mode or the "old" is more suitable for the task in question. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
On 02/04/2016 11:06 PM, Graeme Geldenhuys wrote: It depends on the developer I guess. ;-) I (mostly with Delphi) did use as well AsyncPro as Indy as Synapse (and once LNET) I found Indy rather hard to use. But it can successfully be made doing lots of stuff . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
On 01/31/2016 11:10 PM, Anthony Walter wrote: Thanks for the idea Bo. I'll put it near the top of my queue. +1 IMHO the knowledge about the (great) thread Features of Lazarus are by far not spread wide enough. The "lesson" should include: - Motivation for the usage of threads: - - long winding calculations - - blocking sockets and other hardware / system interface - - exploiting multi-core hardware - Different programming Paradigms for Main Thread and Worker Threads - - Main thread: Event driven (never sleep ! ) - - one-shot Worker threads - - cyclic Worker Thread - - - "wake up" e.g. by blocking interfaces,TEvent or CriticalSection - - - polling with sleep (trading performance against latency) - Worker Thread to Main Tread Events: - - TTherad.Synchonize - - TThread.Queue - - Application.ProcessMessages (IMHO less important since we have TThread.Queue in FPC 3.x) - - using "Event data transport classes" to be used as an argument of TThread.Queue - Data integrity - - "Thread safe" - - CriticalSection - - TThreadList - Creating a Thread pool to prevent overhead for creating and destroying worker threads. - Advanced: - - Threads and DLL/so ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
On 02/01/2016 12:47 PM, Bo Berglund wrote: Blocking sockets is where I am now... So Porting AsyncPro would be a great exercise :-) !!! This is an exceptionally useful tool, great open source code once done by a professional tea, but done in a Windows-only and outdated way (not using TThread.Queue, but Windows messages and "procedure... message" instead. Mending this and using decently portable blocking Socket and Com-Port (TTY) components would do the trick. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Free Pascal and Lazarus learning center
On 02/01/2016 03:00 PM, Bo Berglund wrote: And very complex to hack into as well. If I can provide any help., please let me know. So I turned to Indy10 now Not a good idea IMHO, Indy is exceptionally complex. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is porting Delphi program using AsyncPro to fpc/laz possible?
On 01/21/2016 10:42 AM, Bo Berglund wrote: I could probably rip out the APro component and replace it with a TCPIP socket one instead since the RS232 is not going to be used anymore. The beauty of AsyncPro is that it provides the same user interface for serial and socket component. Hence a serial port could be local or done with a "ComServer" device without a problem -Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is porting Delphi program using AsyncPro to fpc/laz possible?
On 01/21/2016 01:25 PM, Mark Morgan Lloyd wrote: I didn't say anything wouldn't work. Sorry. I took "issue" for a potential problem Copying data tends to introduce a significant performance hit, which is why many OSes try to avoid it by passing pointers. The typical result of passing pointers is to introduce the possibility of buffer overflows, because the lower-level (and more privileged) code doesn't (or can't) apply application-specific tests. Right you are. That i why the second method - if carefully done - would create less overhead. Nonetheless with any transfer to the main thread, a new buffer needs to be allocated. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is porting Delphi program using AsyncPro to fpc/laz possible?
On 01/21/2016 11:38 AM, Mark Morgan Lloyd wrote: That of course is a significant issue. I don't see what could prevent this from working. The simple method would be to create a new buffer for the data to be transferred to the main thread and copy the data already received in a "static buffer" there. If you want to avoid copying you could transfer the data in the receive buffer (which later would be freed) and allocate a new receive buffer for the next receive. I don't understand the "OS" issue, that you speak of . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is porting Delphi program using AsyncPro to fpc/laz possible?
On 01/21/2016 10:09 AM, Bo Berglund wrote: . which implements an *event driven* serial comm port, which can switch between serial and sockets communications. The incoming data are dealt with in the OnTriggerAvail event. So these are the only specific items used by me, but obviously in the background there are a whole lot of things going on... I tried to trace the tree of used units starting from the TApdWinsockPort and it just grows and grows. Seems like a project I could not do on my own. Has anyone here tried/succeeded? Implementing Event triggered behavior (such as AsyncPro) no great problem. I did several test on that (in a *portable OS independent* way). IMHO the best way to go is: - Do the receiving in a Worker Thread based on a blocking (serial or socket) receive function (i.e. the thread always hangs in the receive and only does some work when (at least) a character has come in) .This is exactly how AsyncPro works. - The Thread collects the appropriate amount of data (based on dynamical settings provided to the class. This is exactly how AsyncPro works. - Once the appropriate data is collected you *create* a "transfer object" (an instance of a transfer class that allocates and includes buffer for the data (not just a pointer if the buffer could be reused by the thread ! - You also could use newly allocated managed buffers for data collection, avoiding doing a copy -). This object provides a "APdataavailable" procedure that is to be called to extract the data and (of course) a destructor that frees the buffer. - You do TThread.Queue providing the transfer object's APdataavailable procedure. After that you don't need to store the pointer to that transfer object, as it will free itself (including the data buffer) later in the main thread. - The APdataavailable procedure will be executed as an event in the main thread. It will call the appropriate event handler defined as an AsynPro property. - The last statement of the APdataavailable procedure (after calling the user event handler) will be just "free". have fun, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Can I build a Lazarus GUI program only with fpc installed?
On 01/21/2016 09:51 AM, Bo Berglund wrote: ditch the platforms that would not allow me to install Lazarus... It should be possible to link a project against the LCL without completely installing Lazarus or using Lazarus on that platform This does not even require cross compiling. The project is just source coed. You can develop it on an appropriate platform (best as similar to the final target as possible). Then (provided you already do have a compiler and the RTL on the target system, plus the required Linux Widget Set stuff) you can copy the source codes of your project and the LCL sources onto the target system and compile via command line. So you will generate the fully featured GUI based program. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Is porting Delphi program using AsyncPro to fpc/laz possible?
On 01/21/2016 10:09 AM, Bo Berglund wrote: I have a device comm simulation program created in Delphi 7 (or maybe 2007), which uses TurboPower Async Pro components for the serial and TCPIP communications. It is used for production testing and also for development purposes. On Windows of course Now I would like to port this to the Raspberry Pi environment so the simulator could be placed in a small package and replicated easily. You would be my (and many others') hero if you port Async Pro to Linux and provide the result publicly. This has been requests already multiple times. IMHO this is one of the greatest shortcomings with Lazarus/fpc (even though of course there are alternatives). Let me know if I can be helpful on that behalf. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
On 01/18/2016 11:26 AM, Michael Van Canneyt wrote: The bad idea was that HTML became the standard for remote GUI. HTML = HyperText Markup Language And a web GUI is anything but text these days. ... requiring a decently statefull (instead of connection-less) protocol -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
On 01/18/2016 01:41 AM, Graeme Geldenhuys wrote: 1. Most websites are unusable without Javascript The HTTP protocol cripples TCT/IP disallowing the server to spontaneously send anything . So without scrip the browser is dead by design. -Michael (IMHO, http was the worst idea ever...) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
On 01/15/2016 06:29 PM, Anthony Walter wrote: On a programming web forum someone said regarding Lazarus: On just cursory review, looks compelling. However, I get so little call these days for native/desktop applications. Seems everyone wants web now. Of course it would be great if Lazarus would offer support for designing the GUI of a "Rich Web Application" (e.g. by providing the appropriate components and a Browser based WISYWig preview). But this of course is a completely new project and lots of work to do. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
On 01/18/2016 11:13 AM, Sven Barth wrote: The requirements back then were different. You didn't have highly interactive code running in the browser like you have today and for that HTTP was perfect. Of course you are right. The consequence being that a new protocol (not connection-less) for browsers should be invented and made the next standard But IT departments are too lazy and insist o keeping their restrictive firewalls and http proxies, hence preventing any such development . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Can I build a Lazarus GUI program only with fpc installed?
On 01/17/2016 09:09 AM, Bo Berglund wrote: If I install only fpc is it then possible to build a GUI program from sources without also installing Lazarus (on Linux target)? Of course: if you create your of GUI. Alternatively you can also use MSE instead of Lazarus (I suppose there are some more fpc aware GUI libraries out there). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Web vs desktop development
On 01/18/2016 12:00 PM, Dariusz Mazur wrote: We write our business application as web from several years. Its the same as desktop version, and development are done parallel as 90% of both version have the same source code. And i have some others consideration: In a perfect world, the LCL would allow for defining a web GUI so that the code and GUI define files are 100 % identical, simply choosing a different Widget type (just dreaming...) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] UTF8String and UTF8Delete
On 12/12/2015 07:21 PM, Jürgen Hestermann wrote: As said: The docu in the wikis is very confusing and contradicting, fully understandable only for those who already know the details. This is obvious by the always repeating and long winding discussions on that issue. It supposedly can't be avoided, as, IMHO the concept introduced by Delphi is really flawed and not decently usable for a development environment that is supposed to support portability. When I had been requested to, I wrote a wiki article describing a concept that (IMHO) could solve the problem - while not breaking existing Delphi or Larzarus/fpc applications (unless the do very low level access to strings), and not introducing noticeable overhead. But of course this this is not along the lines of Delphi (e.g. it defines a new type and uses it for Strings and hence in many classes and functions). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] "NoGui" or "Service Application"
On 12/09/2015 11:45 AM, Mattias Gaertner wrote:
Please take a look at the NoGUI widgetset. It does not use another
Queue.
If it does not use "another queue" but the one provided by the fpc RTL
(i.e. does not install it's own queue), and (obviously) does not use a
queue that is related to a GUI, it does not provide a queue art all.
So it does not provide an Event-Handling infrastructure and this (in
according to my terms) means it is not a ("Delphi Style") application,
hence not a "Service Application".
What code? It only contains the basic methods to let it compile. Any
LCL interface must have at least that.
This is what I assumed (and heard from those who tried it): It only
provides for compiling but does not offer any functionality.
The NoGUI allows to compile a LCL application without a GUI. It has a
few lines of code to connect the RTL.
If your intention is to say that just using the name NoGUI and
"silently" update it to something that is "active" (and with that a
"Service Application") would be more sensible than creating a newly
named Widget Type / Application Type, I don't have any problems with
that. I just though of a new name to prevent the possibility to break
any existing code.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] "NoGui" or "Service Application"
On 12/10/2015 01:42 PM, Mattias Gaertner wrote:
So it does not provide an Event-Handling infrastructure and this (in
according to my terms) means it is not a ("Delphi Style") application,
hence not a "Service Application".
A service needs more than an event queue. See the lazdaemon package.
The discussion here was about it *not* being a (Service-) *Application*
if anything above making it an *application* makes sense (e.g. providing
means to communicate with a corresponding GUI application or typical
installation mechanism for configuration) this could be added
independently.
The first step is to provide the infrastructure for "embedded" (not in
the sense of "no-OS", as the term is used in the Wiki) Applications for
e.g. headless Linux devices and Windows 10 IOT.
CreateTimer and SendMessage are currently empty methods. The chance of
breakage is small.
OK.
I'll take a look if the working "interface" unit I already have somehow
can be synchronized / merged with the NoGUI code in the svn
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/08/2015 05:49 PM, Mattias Gaertner wrote: As I said, that's a straw man. I bet in 3 years from now you will find a distro without an official FPC 3. Meaning I should wait another three years ? No real problem with me. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/08/2015 05:59 PM, Mattias Gaertner wrote: For example? TTimer is implemented using the timeout in checksynchronize(). Application QueuAsyncCall is implemented using TThread.Queue. A new application type requires a design time package. That means after installing the package, the application type is selectable from the list of possible application types ? Choosing that application type will set the appropriate defines for compiling the sources ? Correct ? Where can I find documentation on this ? The widgetype list comes from the simple list, but a user can set any value. If you extend the LCL it will be more comfortable for the user. Of course I would like that finally the most comfortable option is offered to a potential user. What's the difference between a "General Service Application" and a "Service Application"? I chose the name "General Service Application" rather than the former suggested name "active NoGui", as I think that is more understandable for users that might need it. It is "General" because the code is independent of CPU arch and OS. So it (hopefully) will run on Windows, any Linux, and the new Windows IOT. (I don't have MAC, OS2, BSD, Android ect, but if fpc application run it should work) (AFAIK, fpc does not yet provide support for Win IOT on ARM) It is "Service" because it does not attach to any GUI library. So it will run on a headless Linux and on Win IOT (which in fact is a headless Windows 10). it is "Application" because it (hopefully) supports the Event programming paradigm, including a dedicated mainthread, TTimer, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall, SendMessage from a worker thread to the main threads to be received via "procedure message" etc, working in the same way as a Windows or Linux-GUI application, without the user needing to bother about the infrastructure that manages the event queuing. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/09/2015 11:45 AM, Mattias Gaertner wrote: Application QueuAsyncCall is implemented using TThread.Queue. What is wrong with the current implementation? Nothing. But it uses another Queue. Queue handling needs OS calls for waiting. I want to avoid to do any OS Calls so I simply use what the RTL offers for exactly this purpose. Many concepts are explained here: http://wiki.lazarus.freepascal.org/Extending_the_IDE Lazarus contains several examples of such design time packages. Maybe instantfpclaz.lpk is a good start. Thanks ! I will tale a look. Since FPC/Lazarus is cross platform, it usually works the other way round. For instance "Windows Service Application" for platform dependent, just "Service Application" for cross platform. I have no problem with choosing a different name. If you say just "Service Application" is OK, it's absolutely fine with me. NoGUi has already a dedicated mainthread, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall. Only SendMessage and TTimer are missing. I started working on the "active NoGui" project years ago, as at that time there was a chance that I would need to use it (But I could not talk my colleagues into the fpc/Lazarus direction.) Bo seems to have done some testing for his NoGUI project but seemingly what he found was not up to his needs. (I found similar requests every few month in the mailing lists, but seldom somebody instated so strongly on finding exactly something that closely resembled my old project.) . So it might - or might not - be viable to publish it by decently integrating it in the Lazarus environment. In fact I would not like to try to re-use the NoGUI code, especially as I seem to remember that I read about several shortcomings of same (I did not yet check myself). Is there a documentation on what exactly NoGUI is supposed to provide ? (I suppose this "Service Application" might replace "noGUI", but of course same should stay in place for legacy projects. ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] "NoGui" or "Service Application"
On Wed, 09 Dec 2015 12:17:55 +0100 Michael Schnell<mschn...@lumino.de> wrote: On 12/09/2015 11:45 AM, Mattias Gaertner wrote: Application QueuAsyncCall is implemented using TThread.Queue. What is wrong with the current implementation? Nothing. But it uses another Queue. Queue handling needs OS calls for waiting. I want to avoid to do any OS Calls so I simply use what the RTL offers for exactly this purpose. Please take a look at the NoGUI widgetset. It does not use another Queue. [...] NoGUi has already a dedicated mainthread, TThread.Synchronize, TThread.Queue, Application.ProcessMessages, Application.QueueAsyncCall. Only SendMessage and TTimer are missing. [...] In fact I would not like to try to re-use the NoGUI code, What code? It only contains the basic methods to let it compile. Any LCL interface must have at least that. especially as I seem to remember that I read about several shortcomings of same (I did not yet check myself). Is there a documentation on what exactly NoGUI is supposed to provide ? The NoGUI allows to compile a LCL application without a GUI. It has a few lines of code to connect the RTL. (I suppose this "Service Application" might replace "noGUI", but of course same should stay in place for legacy projects. ) I guess implementing TTimer and SendMessage only needs a few hundred lines. I see no problem adding that to the NoGUI widgetset. As requested (and decent indeed), I herewith start a new thread and will answer tomorrow. Thank for caring, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/09/2015 11:27 AM, Juha Manninen wrote: Michael Schnell, please don't hijack this RC1 thread for your General Ooops I did it again. :-( You are absolutely correct (I got carried away by the answers I got, I intended to provoke just a Yes or a No) I'll stop answering here. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/09/2015 11:51 AM, Mattias Gaertner wrote: Meaning your argument is flawed, because it can be prolonged to infinity. Don't wait for releases. Start coding now and tell your users what FPC version is needed. Coding is done. It works. I'll Stop talking about it. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/08/2015 05:03 PM, Mattias Gaertner wrote: On Tue, 08 Dec 2015 16:44:49 +0100 Michael Schnell <mschn...@lumino.de> wrote: [...] AFAIK, the existing Widget Type is selected in the IDE by setting it in "Additions and Overrides" and/or by selecting an appropriate application type when creating a new project. Of course I can't modify the IDE to support this. Of course you can, it is open source. Yep. But it might be a lot of work just finding out what to do and it might be dangerous that something not obviously related is broken. You can either extend the nogui widgetset and send us the patch. Or you can start your own widgetset. I need to start a new widget type (i.e. a new interface unit), as the working mechanism is rather different from all existing widget types. There is no arch or OS dependent code, it just does calls to the fpc RTL. Either by creating your own "LCL" package, e.g. "MSLCL" or by extending the LCL. If it's possible to distribute it in a package, I don't object at all. Right now I don't see how a package would be able to have the IDA allow for selecting a new application type and/or to allow for selecting a widget type in "Additions and Overrides", but if there is a documentation on how to create such a package this could be a good way. Depends on how you want to maintain/promote it. I don't have a preference on that. In the end, I want to allow users to be able to create a "General Service Application" in the IDE when starting a project and to modify the widget type of an existing project to be a "General Service Application". Moreover I would like to allow others to help improving the code by providing patches to be included in some svn. (But I can't manage an svn - I already failed several times trying.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/08/2015 04:19 PM, Mattias Gaertner wrote: The Lazarus team is glad to announce the first release candidate of Lazarus 1.6. This release was built with FPC 3.0.0. The previous release Lazarus 1.4.4 was built with FPC 2.6.4. Great ! So there will be a Lazarus release that relies on fpc 3.x. That means that I now can start the final phase of the "General Service" Widget Type (formerly called "Active NoGUI"). Obviously it will not be in the first 1.6 release, but happily the Lazarus releases are scheduled a lot more often than the fpc releases, so I will not have to wait another three years until the code might be published. But as the interest of the average Lazarus user is on Desktop applications rather than on Services I think there is no hurry, anyway. (Sorry, Bo :-( ) At some point of time I would like to have the code included in the svn (or somehow else be generally available for those who might want to use it or help to improve it (Bo ?!?!?! :-) :-) :-) ). So now I think it's time to ask how to proceed. Of course I do have a working code base for a first version of the thingy. But how to make it usable ? AFAIK, the existing Widget Type is selected in the IDE by setting it in "Additions and Overrides" and/or by selecting an appropriate application type when creating a new project. Of course I can't modify the IDE to support this. For compiling, the Widget Type is defined by a "$define" value this is adhered to in the source code. Of course I can't modify the "general" source code of the LCL to have it consider a new Widget Type (by introducing some lines that make it visible) How to proceed ? ` -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Release Candidate 1 of Lazarus 1.6
On 12/08/2015 05:09 PM, Mattias Gaertner wrote: That's a straw man argument. Every single revision of FPC is published. Many projects use and/or support FPC 2.7+ since several years. The code relies on TThread.Queue. The first released version of fpc that (hopefully) has TThread.Queue is 3.0. A Lazarus user who wants to use the Widget Type should not be forced to use a not yet released version of fpc. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] How to destroy object / component by itself?
On 12/03/2015 09:26 PM, Krzysztof wrote: How to destroy object or component in its own method You can do a "pseudo-finalizer" method in an object that just ends by "Free;". Here you (e.g. ion a thread) can create an object and queue that function via TThread.Queue, TThread.Synchronize, or Application.QueueAsyncCall. Now the object is automatically freed without you needing to bother about saving it (i.e. a pointer to same) in a variable. (AFAIK implementing "real" finalizer methods - supposedly just syntax candy for exactly this) has already been discussed in the FPC developers message list) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
On 12/04/2015 10:44 AM, Sven Barth wrote: Why do you assume that every software written in Lazarus/Free Pascal is automatically an open source one? I don't assume "is" but I assume "should be", as I consider closed source projects as a fraud against the highly valuated fpc and lazarus team members. pen source software of course can be payed for customer projects, but any obfuscation of the true working of a program in neither "nice" towards the customer nor sensible, as a decent hacker will crack it, anyway. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
On 12/04/2015 09:29 AM, Richard Mace wrote: My idea was, in my application, I could periodically check to see if a decompiler was running and then my app could perform an operation, such as maybe closing. Why should open source software need a decompiler ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Detecting when decompiler is running
On 12/04/2015 02:09 PM, Marc Santhoff wrote: 1. Protect your program using checksums Don't connect the computer that holds the sources to the Internet. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 12/01/2015 09:01 PM, Den wrote: Doesn't Cairo have a hardware acceleration backend? Is there *any* GUI based widget type in Lazarus that does not attach to a backend that in the end triggers the primitives to be handed via an OS API and with that sent a graphic-hardware driver and with that has them rendered by a GPU if available ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] recent Message Delivery Failures
On 12/02/2015 10:54 AM, Graeme Geldenhuys wrote: For the last few days I have been received "message delivery failures" for somebody in the Lazarus mailing list. same here. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 12/02/2015 10:50 AM, Graeme Geldenhuys wrote: Explain "graphic primitives"? Do you mean API for things like Elipse drawing, Line drawing, Text output etc. Exactly. Especially text rendering is a very time consuming task that is used a lot when rendering the GUI of a usual desktop application. If so, then yes, fpGUI is such a widgetset. fpGUI's "develop" branch is switching over to using AggPas for *all* those graphics functionality. Line drawing, text rendering, anti-aliasing, alpha blending, vector graphics etc. This is turn makes fpGUI very portable with little effort, It's really great to have this, allowing for an extremely portable hardware and OS independent development tool. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 11/30/2015 03:27 PM, Aradeonas wrote: Obviously, if you want non standard speed, you need to consider non standard complexity. Yes I think like this.As I guess your products are not for end user client so you could use flash without any problem In fact they are for end users, but the software is just part of a huge system and installing the flash player is really a relatively small issue. :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 11/30/2015 11:35 AM, Aradeonas wrote: I am working on a specefic GUI that need to be too fast Why do you think there is anything faster than the standard GUI ? Of course there are very special circumstances that would allow for some other GUI system to be faster. - It could be a very restricted GUI. Here a TUI (Text based user interface) could be faster (drop the LCL and see FPC's TUI library) - It could be a very complex threaded GUI. Theoretically you can do a multithreded application and have multiple threads each attach to it's own instance of the OS GUI API. With this, the GUI functions as well in the user program's library, as in the external Widget Set Library could work in parallel on multiple CPUs of an appropriate hardware. But this is not supported by Lazarus. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 11/30/2015 12:58 PM, Aradeonas wrote: Where can I read more about this? The LCL uses the Windows API or a Linux Widget Set API, and both are highly optimized to use the hardware Graphic processor for all provided functions (such as rendering Text and standard objects). If you need advanced high speed graphical Features (such as zoom/pan/move/3D views of objects residing in the memory of the GPU), you need to use other libraries (not being called "GUI") such as Open GL, SDL or - less "basic" - Flash) So according to what you say problem may be using one handle per control so resizing will make flickering. Is there anyway to disable this like fpGUI or mse? Flickering and speed are completely different issues. Usually flickering is suppressed by triple buffering, reducing the speed by needing more CPU time. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Fast GUI
On 11/30/2015 12:26 PM, Aradeonas wrote: I need controls that has animations and images that need to be fast in painting. I checked everything I know, the best result for graphical function is BGRABitmap but it is slow for high resolution painting so the best result I can get is with OpenGL and hardware and now I made it work. LCL for standard jobs is very good but if you want animations or fast painting it use much CPU and flicker and ... . So the best thing I can guess is hardware acceleration for specific jobs but I want to ask if you know one or is it sane or not . The normal GUI functions do use the hardware acceleration as they should. so no chance for a great improvement here. The only way is multithreading to use multiple CPUs in parallel. In fact we (company) do this using Delphi. But Lazarus (or Delphi) can't do this on their own. So we did Flash animations (-> https://en.wikipedia.org/wiki/Flash_animation ) and have the flash player (dll) display them in appropriate rectangles placed in the normal GUI of the program. A lot of work creating this (especially as supposedly will you need a realtime communication to feed your flash windows with new data), bu7t the result is excellent. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
