Re: [Lazarus] The future of the Lazarus IDE
IMHO, in the end it should be possible to do an application in an RAD-way (if desired), test it on a desktop (using the desktop Widgets for its GUI), scale it (by defining parts of the procedures as "Remote"), and finally (just by re-compiling) have it run as a combination of application-parts running as WEBASM in the browser (and used the browser for its GUI) and application-parts running on the Server as fully compiled native code. The infrastructure would need to automatically provide the communication means (shared objects, remote procedure calls, ...) via Websockts. -Michael -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] It's alive !
Wonderful !!! -Michael -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] alternative to web programming?
There are application that require a „stylish“ GUI for optimum user satisfaction, …. And there are applications that do their thing more or less on their own, requiring human attention only for configuration and service. -Michael -- ___ lazarus mailing list lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Using a component OBJ file in Lazarus?
On 12.06.2018 17:08, Sven Barth via Lazarus wrote: No. Delphi does *not* solve this by using dynamic linking. OK. I see. Thanks for pointing this out. Hence in such a (potentially problematic) case the suggested solution might be helpful even with Delphi. But as Bo's code seemingly works fin with Delphi, hopefully compiling the Dongle code into the Lazarus IDE will simply work as expected. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Using a component OBJ file in Lazarus?
On 12.06.2018 14:06, Sven Barth via Lazarus wrote: The dongle code would also be linked if it would be in a dynamic package and Lazarus would support them. Sorry, I seem not to be have been clear. The (potential) problem I want to provide a solution for is: not to link the Dongle code in the Lazarus IDE executable. (But have it usable in the compiled user application.) (Delphi does this by using the dynamic linking for the package the Delphi IDE uses, but this is of no concern when doing Lazarus.) That is why I suggest to avoid the Dongle code in the package altogether, and have it only dynamically linked late (on request, which only is supposed top occur with the user application). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Using a component OBJ file in Lazarus?
On 12.06.2018 11:30, Sven Barth via Lazarus wrote: Only because the code is part of a package that's loaded by the Delphi IDE does not mean that it also is one in the final Delphi program. Delphi package distributions more often than not also contain the DCU for static linking. Of course you are correct that in Delphi a package can be linked dynamically to the IDE (it can't be linked statically, as the IDE never is recompiled), but statically in the final executable. But Lazarus does not provide dynamic linking to the IDE in such a way. That is why the IDE needs to be recompiled when adding a package with "design time stuff". (IMHO this is not harmful at all.) Am I wrong supposing that this means that the package will be statically linked to both the IDE and the executable, and hence it content will be linked in with both ? AFAIU, there are means to control how the code is executed at runtime and how at design time, but this does not affect linking. Hence the dongle code will be linked in with the IDE and might (or might not) provide problems. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Using a component OBJ file in Lazarus?
On 11.06.2018 21:03, Bo Berglund via Lazarus wrote: On Mon, 11 Jun 2018 10:23:44 +0200, Michael Schnell via Lazarus wrote: You want to compile some 3rd party Dongle code in the IDE ? That is more than weired ! Sorry, I don't really know what you mean here... What is the reason for this comment? Unlike Delphi it seems like when one wants to add components to the development IDE palette in Lazarus one has actually to *rebuild* the IDE, there seems to be no otehr way... As fpc/Lazarus dos not (yet) provide run time packages, and IMHO it will ask for major problems when compiling the Lazarus IDE to contain the Dongle code, I suppose your best option is to replace the Dongle .OBJ file by a small pascal function and use this to build your package to allow it for compiling the IDE (providing the design time stuff) and the user program (providing the run time stuff). Now you need to "fake" the runtime package behavior by doing the said small pascal function in a way that it dynamically (not in the startup code !) loads and then uses a dll . The dll would be done in a way that it just forwards the call to the functions provided by Dongle .OBJ to same, and statically links to it. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Using a component OBJ file in Lazarus?
On 10.06.2018 15:11, Bo Berglund via Lazarus wrote: ... Build IDE: Exit code 2, Errors: 23 ... You want to compile some 3rd party Dongle code in the IDE ? That is more than weired ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Converting a component package Delphi->Lazarus using built-in converter?
On 08.06.2018 19:05, Bo Berglund via Lazarus wrote: This Delphi package is a collection of some 20 components and all of them have Register procedures inside of each source file. Are those really IDE-relevant packages (showing up in the visual component selection ) ? If not, they might be just Delphi "Runtime Packages" (a special kind of DLLs that can be attached by Delphi executables). The concept of "Runtime Packages" is not (yet) supported by FPC/Lazarus. That is why the IDE needs to be recompiled when installing a package that provides visual components. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] TMS Web core released - based on pas2js.
On 15.02.2018 22:22, Michael Van Canneyt via Lazarus wrote: Yesterday, TMS Software has released a tech preview of their "TMS Web core" product for Delphi. Great stuff indeed ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Doe fpc/lazarus already have System-Threading or is it planned
sorry -> http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.Threading -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Doe fpc/lazarus already have System-Threading or is it planned
Featuring "parallel loops", "future variables", etc, implemented via a thread pool that is transparent for the application programmer. -> http://docwiki.embarcadero.com/Libraries/Tokyo/de/System.Threading -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 05.12.2017 12:16, Martin Schreiber via Lazarus wrote: What is wrong with TDBGrid??? As I quoted, Graeme claims it's slow. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 05.12.2017 00:50, Graeme Geldenhuys via Lazarus wrote: DBGrid behaves slightly different to TStringGrid, and is slow. While for perfect performance / clearness / portability / ... , DBGrid supposedly should not be used in a production release, it might be very helpful when designing an application. Maybe the way to go is to do an RAD form with Debug I/O when drafting an application and in the process move any tested business logic code in non-visual units, and when deciding how the final GUI should work and look like do this in another Form, e.g. using "GUI-Mediator". Finally deactivate the RAD form, but keep it for reference. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 01.12.2017 20:43, Graeme Geldenhuys via Lazarus wrote: On 2017-12-01 13:33, Marcos Douglas B. Santos via Lazarus wrote: I believe RAD is the best way to code a GUI I'll even disagree with that - somewhat. :) http://geldenhuys.co.uk/articles/model-gui-mediator.pdf The article starts : After mastering OOP and Object Persistence, the next thing developers need to conquer is how to present their business objects in the GUI ... IMHO this is the best way to threaten away would be software developers from even starting to try to do any programming but have them do their living as windows cleaners. When (as a newcomer) starting to do any "business logic", it's essential to have a toolbox that allows for testing your work on the fly. And this (at best) does include a really simple way to add a GUI (this is called RAD), even if intending to use this only for your own purpose and deactivate it in any final version of the product. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 01.12.2017 08:22, Martin Schreiber via Lazarus wrote: For me Delphi is not the best RAD environment and therefore developments made with Delphi should not be used to disqualify RAD as a whole. Which are there other than Delphi and its siblings ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 01.12.2017 07:42, Martin Schreiber via Lazarus wrote: separating of GUI and business logic is perfectly possible with RAD. Yep. But you need to apply this discipline to yourself right from start of the project, as doing this afterwards is tedious. Unfortunately many projects arise from sloppy prototypes necessary as a proof of concept before officially starting the project. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 30.11.2017 12:09, el es via Lazarus wrote: It is not easy to break free from old, ... programming practices Nonetheless, IMHO RAD is a great way to start programming, as you immediately and painlessly can see (visualize) what your "business logic" software does and easily set parameters and triggers for your business logic. So you are not that likely to jump off the ship at an early stage. But education needs to make clear the limitations of this proceeding strong enough. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 30.11.2017 10:04, Michael Schnell via Lazarus wrote: e.g. a small embedded device or to allow running them as a service.. Of course another important "headless environment" is server applications with built-in Web server or sitting behind a standard WebServer. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 30.11.2017 00:02, Graeme Geldenhuys via Lazarus wrote: RAD style development is highly overrated... I do know that very exactly, been there often enough. RAD is great to create "small" applications, but with huge projects, you will very likely hit a limit where you wish you would not have started the project in an RAD manner. Nonetheless there are lots of 3rd party components for Delphi (and Lazarus if you can get them in source code) that prevent to do your projects using them in a non-RAD manner, as they provide or organize business logic but their components need to be "dragged on a form" and create some user interface there, instead of just providing hooks to have the user do his own GUI for them if appropriate. Porting originally RAD crafted projects to a headless environment (e.g. a small embedded device or to allow running them as a service) is possible (did that multiple times) but a real PITA. That is why a long standing wish is a fully fledged LCL Widget Type (just swap the Widget Type in the project's configuration in Lazarus and press compile), that provides no local GUI but some hook to optionally attach a remote GUI. MSE can do something like this via "ifi" (i.e. an external fpc program connected via some stream interface), more "generally usable" would be an application running in a browser (e.g. Pascal compiled Java script or WebAssembly) connected via HTTP/WebSocket, and a decently prepared way to use such "nearly remote" GUI for a Linux/Windows/Mac "service". -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 28.11.2017 11:28, Sven Barth via Lazarus wrote: Why should they? They are two completely different projects. From the LCL's point of view fpGui is a black box like GTK, Qt or the Windows API. OK, so in the end fpGUI *is* an external Widget set, only that it comes more independent of the OS distribution than WinXX, GTK, QT or Apple variants. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 27.11.2017 19:59, Graeme Geldenhuys via Lazarus wrote: (except for TLabel) To me TLable seems like very important to allow easy "porting" of applications from an other widget Type to fpGUI/LCL. Is implementing TLabel really that hard ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 27.11.2017 20:07, Graeme Geldenhuys via Lazarus wrote: Either way, it would be nice to see LCL-CustomDrawn and LCL-fpGUI widgetsets get some more attention. Is there any chance to unify them to a single Widget Type implementation that uses a low level graphics API (without an external Widget Set) ? AFAI understand, MSE-Gui does this very successfully. They even provide a functionality called "IFI" that allows for remoting the interface between the RTL (and the MSE-variant of the LCL) and the "custom drawn" library via a stream interface. IMHO this is a highly attractive way to provide an optional remote GUI to otherwise headless applications, while still providing portability and support for Delphi-typical RAD-style development. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 26.11.2017 18:32, Kostas Michalopoulos via Lazarus wrote: i am already working on a widget toolkit for a few years now which is written in C ... Most of my code is LCL specific This seems like a very peculiar combination to me. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] External/out-of-tree LCL widgetset
On 26.11.2017 17:13, Sven Barth via Lazarus wrote: Lazarus already contains a custom drawn widgetset that supports X11. I don't know its current state, but maybe it would be best to bring that up to speed and form instead of starting a new one. Some time ago I did play with the custom drawn Widget Type. I found that it was not yet complete but rather promising. AFAIK, not much has changed since then . Anyway I also would suggest to use this to build on. This will be a lot easier that do something completely new. In fact, Widget Types need to be known to the Lazarus IDE, as same is able to have the user select them and force them via definition of conditionals fed to the compiler. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 09.11.2017 11:12, Michael Van Canneyt via Lazarus wrote: We are busy creating this framework. Great. From the previous messages I got the impression it would be depreciated. But Rome wasn't built in a day. Obviously. I am not trying to hurry anybody. I am very happy with what Lazarus and fpc do offer. Nonetheless I think discussing improvements always does make sense. Thanks a lot ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 16:39, Michael Van Canneyt wrote: .. I believe that you should embrace the platforms you're using. That means: browser as client, webserver as server, and HTTP or websocket as the transport layer. This depends on who is "you" :) . I've already been doing some " Lazarus Community" work (I do have a working draft for an "application" Widget Type that does not do a GUI binding, as an extension to the NoGui Widget Type, but stop working on it due to the complexity of publishing any of it), and so "you" might be the creator of Lazarus means to provide such a framework managing the clint/server communication in some (yet undefined) user friendly way. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 14:15, Sven Barth via Lazarus wrote: Nope, WebAssembly and what pas2js does are two different things even if in the end both run in the browser's JavaScript engine. Of course I do know this. But AFAIK WebAssembly has been invented with JS in mind, so it might follow some paradigms, that are closer to JS than to Pascal (e.g. not strictly typed variables). So maybe some stages of the transpilation / compilation might be similar. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 13:12, Michael Van Canneyt via Lazarus wrote: ExtPascal way (or UniGUI for that matter) is the wrong way to do things. Interesting as a toy, but not suitable for a) Large, scalable websites b) serveless applications. Agreed ! But if doing a server based application (ore one that includes the web-server) that mainly does unattended, "embedded" work, and tghe GUI is only used for configuration and monitoring, such a toy-functionality might be useful, nonetheless. From the view of the application programmer, doing a Rich Internet Application with pas2js is a similar endeavor as Microsoft intended by Silverlight (which has been canceled some time ago) : Design an application and define "bridging points" that "somehow" shift the execution between server and browser. With Silverlight, both parts would be compiled to CIL byte code and run an a CIL (aka .NET) framework, with fpc, the server part would be compiled to a native executable while the Browser part would be compiled to JS (or maybe later to WebAssembly). The user source code would not necessarily need to contain much more than appropriate definitions of the bridging points (supposedly some kind of inter-class interface), and the Lazarus infrastructure would take care of the communication. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Applicationx
On 08.11.2017 08:47, Marcello via Lazarus wrote: Are there any information about it? I just found and watched -> https://prezi.com/upueosj4ep0q/pj-suite/?webgl=0 -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 12:28, Michael Van Canneyt via Lazarus wrote: It is the basic building block. I do agree that it is a very viable building block, but theoretically for "Rich internet Applications" there are alternatives: - WebAssembly (which as far as I understand is considered for fpc, and I suppose it might get started after pas2js is released, as it partly might be based on same. ) - using a 3rd party JS based GUI framework (like EXTJS/EXTPASCAL, which is very expensive/depreciated/dead), or e.g. "React", which might be not decently suited as a target for the Lazarus GUI builder. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 11:14, Mattias Gaertner via Lazarus wrote: A server is not needed. You can write standalone browser applications that work offline too. OK. Great ! Stand alone browser based applications might be one desirable type of application, but AFAIK, the more commonly required type of application would be server based. Sigh. Michael, sometimes I got the impression you are stuck in a loop. Use TFPTimer and TThread. You might be right :-) But it's not just me, but it's based on the Lazarus claim "write once, compile everywhere" which means that I can design and test an application in - say - Windows (using the "RAD"-way that once has been introduced by (Borland-) Delphi, and then tell Lazarus to create a server application with a browser GUI by just compiling my code. In a perfect world this should simply work, in a less perfect world, some tweaks might be necessary to optimize the thing for either platform to run on. - Communication between the Server application and the part running on the brower via a 3rd party web server. There are various ways since years. I do know. Some are depreciated, I feel at the moment WebSocktes is the way to go. But see above: the Lazarus user should not even see this, but the infrastructure would organize the communication in a (as good as possible) compatible way, by just telling Lazarus to compile the application as a server based application with a browser based GUI accessible via a web-server. - allowing for decent Debugging in Lazarus (e.g. via an optional built-in web server, which AFAIK already is in place) . Server debugging is already possible. But I agree, it could be easier. Client side debugging is working. You can use the browser's debugger to set breakpoints in the Pascal code and step through. I suppose you are talking about pas2js, running in a Browser, which is perfectly viable, of course. What I meant was debugging the server based part of the application (which accesses an attached GUI part done in pas2js. Here (AFAIK) a webserver unit that allows for attaching to a browser to display the GUI while the application (i.e. the "business code") runs under Lazarus, already is provided. so I don't assume any problems here. (While in Delphi AFAIK, this is a major problem). - Lazarus providing a GUI builder for the browser based GUI. That's a big topic. Some parts already work. As I already did some research om that (some time ago) I do know that is is a big topic :) . That is why I ask. Great to hear that it is worked on and something already is functional. Moreover IMHO a migration path from Java script in the Browser (pas2js) to using WebAssembly in the Browser should be considered. It has been started in FPC, but no one is working on that. So same state as since quite a while. Regarding that most decent browsers nowadays provide the WebAssembly framework, it seems viable to ask, but of course developing time is limited. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 08.11.2017 08:57, Michael Van Canneyt via Lazarus wrote: Normally, early december a RC version of pas2js will be released. I understand that the issue of this thread is using Lazarus to do a server based "Rich Internet" application that shows it's GUI in the browser. So pas2js is only part of the game. Other components would be - Allowing for an "Application" (out of the box providing TTimer, TThread.Queue/Synchonize etc.) to run on the server without any binding to a local GUI framework. - Communication between the Server application and the part running on the brower via a 3rd party web server. - allowing for decent Debugging in Lazarus (e.g. via an optional built-in web server, which AFAIK already is in place) . - Lazarus providing a GUI builder for the browser based GUI. Moreover IMHO a migration path from Java script in the Browser (pas2js) to using WebAssembly in the Browser should be considered. Any news about these topics ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] PlotFunction patch declined?
On 07.11.2017 10:55, Alexey via Lazarus wrote: https://bugs.freepascal.org/view.php?id=32653 wp wrote: >>Sorry I will not fix this one because it opens another Pandora to add features well-established in TAChart. Pls apply the patch. it makes several plots on one panel. What Pandora?? I don't know Pandora, I use Laz and LCL. -> https://en.wikipedia.org/wiki/Pandora%27s_box :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24.10.2017 11:29, Mattias Gaertner via Lazarus wrote: Are you kidding? If this is not appropriate, I suppose the general design of that functionality should be reconsidered, doing anything that needs a fast reaction in the worker thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Weird object variables access - fpc issue?
On 24.10.2017 10:48, el es via Lazarus wrote: [...] begin repeat until not ThreadNowInUse; // try ThreadNowInUse :=true; Busy wait actions are usually a very bad idea Better use a TTimer for such. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] FPVectorial
I rather unsuccessfully tried to use the pdf decoder example provided here -> http://wiki.lazarus.freepascal.org/fpvectorial . I needed to add the package fpvectorial to my project. Now I can do "use fpvectorial". The project needs "use pdfvectorialreader". To allow for this I needed to add the appropriate file / search directory (pdfvrsemantico\pdfvrsemantico) to the project. Then it did not compile, as "TvVectorialDocument" does not feature the property "EndPath" (and others). So for initial testing, I commented some four lines out and was able to compile the project. But when starting, I get an exception in what I suppose is Portuguese. I used 1.6.4. Is a newer Lazarus version improved on that behalf ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Kitto2 for Rich Internet Applications
On 28.09.2017 15:35, Marcos Douglas B. Santos via Lazarus wrote: https://github.com/EtheaDev/kitto2 Seems like an interesting project. I once did some rather successful tests with ExtPascal but gave up as ExtPascal seemed to be dead. Now at -> http://www.ethea.it/eng_news.htm we read: "September 2017: Kitto^2 and Kide^2 released under Open Source license!" So trying it with fpc/Lazarus seems viable. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] [ANN] Xavier for XML — Compatible with FPC and Delphi
On 20.09.2017 22:09, Marcos Douglas B. Santos via Lazarus wrote: In a perfect design, we may only connect all objects to work in a "task", call "run", and "they" will know what to do. They (Objects) will decide how to do. Not the programmer (the "controller"). Just objects sending messages for each other. Is that what the (language construct) "Interface" is supposed to provide ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 18.08.2017 14:26, Sven Barth via Lazarus wrote: Delete(), Insert() and Pos() I understand those, and "+", etc, are in the pipe for Array of Byte, as well. I suppose workalikes for the most important TStrings siblings, such as TStringlist (including sort and LoadFromFile) be doable on top of that. Might be good news for new programs. Legacy stuff will need to be ported appropriately (as already discussed here). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 18.08.2017 11:01, Graeme Geldenhuys via Lazarus wrote: On 2017-08-18 09:16, Tony Whyman via Lazarus wrote: Damn, should remember never to copy and paste from Wikipedia! Or simply use "plain text" emails To explain my mail above in plain Text: A 32 bit Unicode needs two UTC-16 codes when it's greater than 2^15 (and not 2^16) , because bit 15 in UTF-16 is used to denote that another word follows. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 17.08.2017 11:27, Sven Barth via Lazarus wrote: Why do you want to stuff everything and the kitchen sink into TStrings? To make use of the benefits the string type offers such as reference counting and lazy copy. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 17.08.2017 14:43, Sven Barth via Lazarus wrote: Yes it does, because without optimizations implemented and enabled the compiler would need to do this for each element access. But it does not need to do a function call. If getting the element size of a string is a pascal function it would be built-in. Moreover I suppose (or suggest) that pos() is a built-in function that in fact can use decently optimized code. Also a library function could use optimized pascal code that reads the element size, stores it in a variable and uses a pointer within the loop. Of course a user function would just do s[x] and see some degradation. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 17.08.2017 12:41, Tony Whyman via Lazarus wrote: Finally: "In UTF-16, code points greater or equal to 2^16 are encoded using /two/ 16-bit code units. 2¹⁵ ??? -Michael-- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 17.08.2017 12:41, Tony Whyman via Lazarus wrote: UCS-2 differs from UTF-16 by being a constant length encoding and only capable of encoding characters of BMP, it is supported by many programs." Rather obviously Embarcadero primarily had UCS-2 in mind as they created the "Unicode aware" Delphi. While it in fact does support full Unicode, keeping MyChar:=MyString[i] in place suggests to presume UCS-2 coded text for "unaware" programmers. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 17.08.2017 12:09, Bart via Lazarus wrote: Variables of the ordinal type Char are used to store ASCII characters." According to this wording, using Windows with ANSI character set would be a no-go. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 17.08.2017 11:29, Sven Barth via Lazarus wrote: Am 17.08.2017 11:11 schrieb "Michael Schnell via Lazarus" mailto:lazarus@lists.lazarus-ide.org>>: > > Maybe, Sven could answer to this mail in the other thread... > I provided an example in my answer to Tony Whyman in the same subbranch of the thread. I suppose you mean this: In a tight loop where one accesss the string character by character (take Pos() for example) this will lead to a significant slowdown as the compiler (without optimizations) will have to insert a call to the lookup function for each access. While I generally don't consider performance degradation as a backwards compatibility issue I do in this case, due to the significant decrease in performance. This is not applicable to the "DynamicString" discussed here. With that, "pos" would just need to use the "bytes per element" value taken (once) from the the String header, instead of a value supplied at compile time. I don't think that this can introduce a considerable performance hit. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 22:40, Sven Barth via Lazarus wrote: Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + are on the near term ToDo list. Supposedly "pos", as well. But that does not really help if we don't have a TStringList workalike, and supposedly several more library functions. That is why I feel empowering the string paradigm for such use would be more appropriate. (See the thread "dynamic string proposal"). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 20:26, Luca Olivetti via Lazarus wrote: Call me lazy but I don't want to reinvent the wheel and re-implement from scratch the functionality that a plain ansistring provides and TBytes to this day doesn't. So please continue in the thread "dynamic string proposal". Exactly this is part of what is discussed there. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
Maybe, Sven could answer to this mail in the other thread... On 14.08.2017 18:47, Sven Barth via Lazarus wrote: The main problem of such a dynamic type would be the inability to do fast indexing as the compiler would need to insert runtime checks for the size of a character. What "indexing" do you think of ? Could you give an example where such a difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 18:24, Mattias Gaertner via Lazarus wrote: This "dynamicstring" sounds like Rawbytestring times two. In fact I do suppose that the initial intention the Developers had with Rawbytestring, was something like this, but it never was implemented or documented appropriately. In fact I (no access to XE) don't know hat happens when you do Rawbytestring := SomeDedicatedString. With the DynamicString here the "encoding brand" and "bytes per element" are copied over. AFAIK Rawbytestring never is prone to autoconversion. The goal of DynamicString is exactly the contrary: do autoconversion when necessary. Any function accessing the inner chars of a "dynamicstring" has to handleRawbytestring codepages and unicodestring and array of byte/word/dword. In fact it has to handle the "codepage" etc that is denoted dynamically in the string header. Exactly like with any other string. Only that it can't be determined at compile time. This of course will introduce a small performance degradation (happening only when explicitly DynamicStrings are used). What do you mean by "accessing the inner chars" ? If you do SomeDedicatedString := Rawbytestring, AutoConversion is done necessary (i.e. the (static) encoding brand of the target is not equal the (dynamic) encoding brand of the source, and both are not "Raw" / "binary"). This of course needs appropriate compiler magic. If this is the price for avoiding some conversions, many programmers will become unhappy. I don't see, why. Michael, please tell me your proposal has some serious advantages. I don't see them. Matthias, thanks for taking the effort of evaluating the (weired) suggestion. The paper was the result of several discussions in the fpc forum started by users complaining hat their code did not work any more when compiling with a new version or fpc/Lazarus. - Code ported from older (not Unicode aware) Delphi or fpc versions: forced usage of Unicode functions (e.g. based on TStrings) was not compatible with their usage of one-byte-strings the coding of which was of no concern for the compiler (because it was not necessary) - Code ported from the intermediate Unicode aware Lazarus version that ran with the not Unicode aware fpc: all kinds of problems, a very popular problem at that time. - Code ported from newer (Unicode aware) Delphi versions: problems arising from UTF-8 / UTF-16 differences. And you could not have them just define their strings appropriately to have the Unicode aware fpc behave like the system they produced their code on, as (e.g.) TStrings forcibly requires UTF-8. Hence the ability to allow TStrings (and siblings and in fact any other library function) to handle any encoding / bytes_per_element the user choses for his string functionality, could be a solution. This in place (in fact rethinking the dull encoding-aware-string support Embarcadero forced on their users), the "String" paradigm can be enhanced to allow for additional functionality. E.g.: - Non-Text String elements (such as Bytes, Words, DWord, Qwords, ) - User defined encoding (the user would be enabled to supply the conversion functions with other string encoding brands he intends to use. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 17:55, Juha Manninen via Lazarus wrote: although Pos(), Copy() and Length() deal with CodeUnit resolution. I wonder how the new fancy string types would handle it without a performance penalty. This again is not in the scope of the paper, and supposed to stay as it is. S[x], Pos(), and friends work in terms of "bytes per element" bytes. The only difference to the current status is that with the "dynamic" string brand the content of the "bytes per element" field is not predefined by the variable declaration but can change when something is assigned to that (additional) brand of string variables (I feel that this is clearly stated in the paper). Hence for that (additional) brand of string variables the compiler needs to generate code to read this field when implementing the built-in functions. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 17:20, Juha Manninen via Lazarus wrote: Unicode is the standard now. We cannot ignore it, and we don't want to ignore it because it solves so many problems of the earlier solutions. If you create a new string type, you certainly must take Unicode into account. It is not "ignored", as it is handled by the conversion functions the functionality of which is not touched. The paper is just about storing the information in the strings (including the "encoding brand" and "bytes per element") fields. So the actual meaning of the stuff that is stored in the strings is beyond the scope of the paper. And supposed to stay as it currently is. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 15:33, Juha Manninen via Lazarus wrote: Why don't you implement such a system. This is all FOSS, free and open source. I would never dare to try to edit the compiler :-[ You are writing about encodings etc. which are part of codepoints, but you call them "characters". Why? Because the type for this stuff used in Delphi and and FPC is called "char". Is it possible you don't know Unicode beyond codepoints? In fact I did not explicitly talk about Unicode at all. the paper says it: "In this article, a "String" is thought of as a reference counted ordered array of a number of "Things" (aka elements). (I feel that this is what the name String suggests.)" ..."If the elements of the strings are printable characters or partial codes of UTF. OK, this is nice (provided the conversion functions are in place) and makes doing programs handling conventional problems very easy" ... Do you have plans to tackle also the complex issues of Unicode? Not at all. If not, then your efforts are useless because codeunits and codepoints are easy in any case. I know. The intention was to handle a completely different problem from that you suggest here. You use energy for a problem that does not exist. I wrote the paper because I once was requested to do so in the fpc forum. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote: For some unknown reason you want to store different encodings in a TStrings and fear the "time-consuming" and loss-prone auto conversions. It's obvious that a user using a different encoding brand in a string var than that suggested by TStrings (UTF-8 in fpc, UTF-16 in Delphi) implicitly triggers auto-conversion when handling the string. This has several consequences. It might be a really good idea when e.g. doing some code that in a loop needs certain operation that might be very fast with UTF-16 but TStringList would store the data in a more compact way. It might be time consuming when the conversion is done without being necessary. It might be error pone when the user stores some random stuff in the string that is not able to be handled by the conversion forth and back. In any case all this happens without the user being aware of, which might cause frustration. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote: Not if complicated things get more complicated. Please leave out the additional encoding brands suggested just as an afterthought in the paper. These are not the purpose at all but ()if the other stuff would be in place) just com as a natural enhancement. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 14:22, Alexey via Lazarus wrote: BTW, it will be good to have "Cstring" (or another name, not "dynamicstring") : ... You are missing the point the paper is supposed to be about: enhancing the versatility of the library functions such as those using TStrings. Not just creating another type of strings, which is nothing but a prerequisite for the main purpose. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 14:30, Martin Frb via Lazarus wrote: And that would still not be "char", but "codepoint" A char can be composed of several combining code points (each of them afaik, in the 32 bit range). So a char can have 96 or more bits. (And not all of them have a combined form). Unfortunately in Delphi and FPC the appropriate work-alike existing type is called Char (with certain extensions). It would cause major problems to drop that name for something else, even if that would be appropriate. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 13:17, Mattias Gaertner via Lazarus wrote: You are confusing people if you name your encodings like this. There also is no "official" Code pages named "Default" or "None", the naming "CP_DEFAULT" and "CP_NONE" has just been invented by Emparcadero. So I did the same and just brainlessly extended the existing "CP..." naming scheme. Your "dynamicstring" supports char, widechar, byte, word, dword, qword. Why not shortint or smallint? Why not boolean, single and variant? As pointed out this is just a draft of a proposal, prone to enhancement and improvement. What is the intention of your proposal? That is given in the instructional paragraph "The problem": "The most obvious candidate for pain on that behalf is “TStrings”. Only a fully dynamically encoded version of TStrings and friends would allow for a solution for many string encoding related problems, as the user can't modify the string encoding brand TStrings uses and hence will face the described problems when he uses TStrings with all but one of the String encoding brandings he can choose from. Enhancing the count of available encoding brandings is just a logical consequence of a less problem prone and more versatile (not implicitly restricted to printable text) overall string handling. -Michael (It's rather frustrating to discuss that obviously never will happen :-() -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
BTW.: This is off topic in the Lazarus list and would be an fpc issue. Moving it in one of the fpc lists would have the additional advantage that I am banned there, anyway, for having answered to similar questions. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 12:22, Juha Manninen via Lazarus wrote: You should stop writing in this thread now. I agree with Mattias. I perfectly agree with you. But you can't blame me for answering when asked. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] dynamic string proposal
On 16.08.2017 11:51, Mattias Gaertner via Lazarus wrote: Every Delphi/FPC type has a bunch of operators. Strings support :=, =, <>, >=, <= and [] for read and write. When you propose a new string type "dynamicstring" you have to define these operators. That is easily doable. The definition of := is discussed in the paper. (Only for := there is no accessible encoding definition for the left operand.) If the encoding branding is one of those that already exist, the current definition is used. For "new" encoding brandings, such as CP_Byte, CP_Word, CP_DWord, CP_QWord, the working of the operators is obvious. It somebody tries to compare a printable Text string with a string of binary elements, maybe the behavior is undefined. There is no QWord codepage. That would be confusing. Of course the term "Codepage" Embarcadero chose for the encoding identification is misleading in this context. That is why in the said paper it's called "encoding style" (which is not a really appropriate wording, either, but hey, it's just an initial suggestion and not yet a final documentation, and it had been clear from the beginning that it's in vain, anyway. ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 11:55, Mattias Gaertner via Lazarus wrote: 1,114,112 possible code points need at most 21 bits. Due to encoding at most 32bit. Sorry. Typo. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 11:32, Mattias Gaertner via Lazarus wrote: Anyone who wants to discuss the grand picture of strings in FPC for the millionth time should start a new topic. Right you are. And it will be by far too late and futile, anyway, because of the reasons discussed a million times. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote: Are you suggesting that internally TStrings should have different storage for all possible languages, Not at all. In the said paper I point out that a new fully dynamical string encoding brand would be introduced and same is used for TStrings. Everything else will not provide an improvement of the class of problems under discussion since years. -Michael (knowing that this will never happen) -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote: So it makes sense that TStrings should use UnicodeString internally to store its data. The Unicode standard is also the only standard that can support any language. But in fact "Unicode" is just a universal standard defining 64 bit entities. The encoding of those varies: UTF-8, UTF-16 high byte first, UTF-16 low byte first, 64 bit low byte first, 64 bit high byte first, fpc and Delphi do support several of those as a string encoding (and with that crating any number of problems). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 18:33, Mattias Gaertner via Lazarus wrote: Do you propose a string without the array operator [] ? I don't understand what you mean by this. Of course an appropriate "char" type for each string encoding brand could to be provided, hence a "CP_QWord Char" as an alias or a QWord. (Please keep in mind that in that paper (as explicitly pointed out) "String" is not a synonym for "printable text" but for "sequence of similar things". And here of course (at least in a 64 bit system) it's extremely appropriate to allow for 64 bit elements. And of course this is just a suggestion that could solve a certain class of problems but needs a big effort to do and verify the modifications in the compiler and the libraries.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 19:53, wkitty42--- via Lazarus wrote: what if 3 and 4 byte characters are required? will they also work in UnicodeStrings? UTF-8 and UTF-16 are just encoding variants for 32 bit Unicode "characters", storing them in n (or 2*n) Bytes according to a simple scheme. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 16.08.2017 10:58, Mattias Gaertner via Lazarus wrote: This thread is going out of topic. Please start a new thread if you want to discuss Delphi strings. You can't discuss fpc's string problems without mentioning Delphi, as they are a direct consequence as well of Delphi-compatibility as of Delphi-incompatibility. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 22:45, Graeme Geldenhuys via Lazarus wrote: How is that not "abuse"??? IMHO it's a major shortcoming to define "string" as "printable text". In fact the name "String" does not suggest this at all. A "string" in my understanding just is a sequence of similar "things". A string type was definitely not the right choice. Notwithstanding the discussion about the mere wording, this only would hold, if the system would provide a differently named non "printable text" basic type that comes with the features needed for such usage: reference counting, lazy copy, simple operators for concatenating and element extraction and replacement, built-in function for substring locating, ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 21:38, Ondrej Pokorny via Lazarus wrote: Furthermore, if you use(d) strings for binary data, just replace old string for AnsiString/RawByteString (and Char for AnsiChar, PChar for PAnsiChar) and you are good to go. Annoying but no big deal. This only works if all tools that you use do the same. And a major tool for handling strings is TStrings and it's siblings. You hardly an avoid using same. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 19:29, Luca Olivetti via Lazarus wrote: I has worked extremely well and reliably until fpc 2.6.4 (i.e. with string=ansistring). Does it not work in 3.x? I understand that storing uncoded Bytes in UTF8-Strings (hence in fpc) works as good as it always had, as long as all strings are defined with the same code branding as TSrings (and friends) is (i.e. UTF8), because there never will be a conversion. But it does not work in Delphi, as here TStrings is defined to be UTF-16. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 19:18, Graeme Geldenhuys via Lazarus wrote: Why can't that be changed to a UnicodeString or UTF8String IMHO, any implementation of TStrings that forces a conversion (just because the class uses TStrings and not due to a logical demand), is a contradiction to providing code aware strings at all. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The new kid is growing up fast
On 15.08.2017 21:40, Ondrej Pokorny via Lazarus wrote: Too bad that Eugene didn't decide to improve Lazarus Cocoa bindings :) Does he use fpc as a compiler ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 14:53, Mattias Gaertner via Lazarus wrote: Do you mean a 'char' is a string in your proposal? Nope. In my proposal there would be Chars for any statically encoded String Type, hence 1, 2, 4, and 8 byte wide. (As regarding statically encoded string (and char) brands, it's just an extension of the existing paradigm. I did not think about the necessity to also have a dynamically encoded Char type. If yes, it (like a string) would need the additional fields for encoding number and bytes_per_char, and the appropriate compiler magic to handle them appropriately (workalike to a on-element string). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: 3. The problem with string handling today is that it is not based on a consistent approach to the character type. If you clean up character handling then the model for string handling should become obvious. A string is after all no more than a container for a character array and which should be constrained to have the same character encoding. A string should intuitively represent a string of text regardless of how many bytes are used to represent each character and with dynamic attributes to tell you how it is encoded. 4. FPC should clean up Delphi's mess for it. If a unified string type follows a consistent model then it should be possible to make all Delphi string types synonyms. You will need to allow exceptions for legacy programs that insist on manipulating the bytes themselves - but that is not rocket science. There is also the issue of the Windows API and its insistence on Wide Strings - but isn't that why calling conventions such as cdecl and stdcall exist - to tell the compiler when it needs to reformat the call for a given API convention. see -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: Why shouldn't there be a single char type that intuitively represents a single character regardless of how many bytes are used to represent it. I suppose by "char" you mean "single printable thingy" with Unicode it's rather debatable what such a thingy is. Hence a Unicode singe char would need to be just be a Unicode string. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] The new kid is growing up fast
On 15.08.2017 13:19, Graeme Geldenhuys via Lazarus wrote: Just wanted to show you guys something. Great. CrossVCL seems to allow to easily port Delphi VCL applications to Mac and Linux. How to compare it against Lazarus ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 12:15, Michael Van Canneyt via Lazarus wrote: What does S[2] mean in your proposal ? Is it 1, 2, 4 or even 8 bytes ? Regarding the users' appreciation, the S[x] notation is decently incompatible between the different string types and compiler versions. There were hundreds of complains in all the appropriate forums and mailing list. So not much additional harm can be done, anyway. I suggest that it should be according to the character_size definition stored S, and the operation c := S[x] should transfer the appropriate count of bits, provided the type of c allows for taking them. This seems to be compatible to the current implementation of any 1-Byte brand and UTF16. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 12:11, Mattias Gaertner via Lazarus wrote:
It does not explain what the characters of DynamicString are, does it?
I don't understand what you are asking.
The element size and encoding of a Dynamic String ("CP_ANY" in the
document) are not predefined, but depend on the content:
http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support
-> Defining String variables and String types:
*CP_ANY* = $FF00 // ElementSize dynamically assigned // fully
dynamical String for intermediate storing string content // just
assigned to the Type or variable, never used in the "Encoding" field
in the string header.
Hence it stores the "branding" when it is assigned to from a string with
a fixed branding (such as *CP_UTF8*), and the content is auto-converted
if necessary when assigning form CP_ANY to a fixed branded string variable.
If (in your example) the data is read from a file, a CP_ANY Strings
based StringList would keep the encoding/char_size of the data as t is
in the file (it would need to somehow get to know the presumed encoding
of the file, anyway) and store that information in the
EncodingBrandNumber and ElementSize fields (which do exist in any
"NewString" variable, anyway), in each String read.
If the user assignes an element of the stringlist to a fixed branding
(such as *CP_UTF8*), the content obviously is auto-converted if
necessary when assigning form CP_ANY to a fixed branded string
variable, as usual.
In fact I suppose that the current implementation of TStringlist does
not use new strings to store the data on the heap, but I never said that
trying to implement such idea would not require a lot of work.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 11:52, Michael Van Canneyt via Lazarus wrote: This cannot be solved properly except by duplicating the classes unit. Sorry to disagree, but IMHO this can only be solved properly by defining an additional fully dynamically encoded string type and use same for TStrings (see -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) But I am perfectly aware that implementing this would be a huge effort (see other mail here), and nobody i entitled to ask for this. (I wrote the article just to elaborate what was discussed in the fpc mailing list at that time.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: In this case, I would argue that both are true. And the culprit obviously is Embarcadeo and not the fpc or the Lazarus team, who did their best to try to do a compatible and implementation that is really workable on the multiple supported platforms (which E$ did not feel necessary when they released the encoding aware strings). Maybe a better solution can be found, but who would want to nudge the fpc / Lazarus developers to invest a huge amount of time to create it and then make sure it is decently tested stable ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 15.08.2017 11:25, Michael Van Canneyt via Lazarus wrote: WideString/UnicodeString for those that want 2-byte characters. A codepage-aware single-byte string for those that want 1-byte characters. The shortstring is even still available. IM (often stated) O, this does not help as long as TStrings does not without forced auto-conversion support the string type the user is inclined to choose. This obviously requires an (additional) fully dynamic string brand. This (again obviously) is not the "Embarcadero way", but supposedly does not necessarily lead to incompatibility regarding the user code. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 14.08.2017 18:47, Sven Barth via Lazarus wrote: The main problem of such a dynamic type would be the inability to do fast indexing as the compiler would need to insert runtime checks for the size of a character. What "indexing" do you think of ? Could you give an example where such a difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 14.08.2017 18:49, Sven Barth via Lazarus wrote: Because the crowd demanding Delphi compatibility is larger than the crowd demanding exact terminology. ... or even a revised concept avoiding the junk presented by Embarcadero :( But obviously the fpc team has no choice. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 14.08.2017 14:50, Marcos Douglas B. Santos via Lazarus wrote: "The right solution is to use Unicode everywhere." Embarcadero though that this would not b the "right" solution. Otherwise they would not have invented the encoding aware strings. IMHO that was a good idea. They only completely failed to do a decent specification and implementation. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] String vs WideString
On 13.08.2017 22:41, Juha Manninen via Lazarus wrote: You have misused "String" or "AnsiString" from the beginning for binary data. There have always been warnings against it. While this might be true, it's decently silly, IMHO. The name "String" can easily be interpreted as "String of things" and does not necessarily mean "String of printable stuff". The management Pascal always provided for strings (after the "Short String" was not the only string type) (i.e. Operators, built-in functions, lazy copy, reference counting) is perfectly applicable to "Strings of things", and don't force any known encoding at all. The drama only was introduced by Embarcadero's abysmal / sloppy implementation of automatic code conversion for strings. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Android & iOS
They claim Delphi VCL compatibility and hence it should be compatible to LCL, as well. -> http://www.elementscompiler.com/elements/whatsnew.aspx (I did not test any of their products.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Android & iOS
On 04.07.2017 08:04, Michael Van Canneyt via Lazarus wrote: So at the moment the developer experience would not be very good, I think you're better off using a HTML5 based Ionic app. This of course is bad news, but we do hope for improvement when time comes See -> http://www.remobjects.com/ . They claim to allow for writing multi-target pascal applications: "NEW: Elements 9.1, Oxygene, C# & Swift, for iOS, Android, Mac, .NET & more." (Of course not free / Open Source) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Enqueuing a callback from a thread via other class - or am I overcomplicating this ?
On 17.06.2017 22:25, el es via Lazarus wrote: Where does the call queued from a thread, return to ? From the POV of the application programmer: "nowhere". it's just another (main-Thread-) "Event" that (like "OnClick") gets "fired" by the Lazarus/fpc infrastructure and is done. The object's lifetime is controlled by the dedicated thread (meaning only one thread is allowed to Free() it); Of course a queued event should not use an object that might get freed by other means. If you want to pass data to the event, a useful way to avoid this is to create a transfer object: Type TTransfer = class; procedure the_event; TData: the_data; . running in the WorkerThread: Transfer := TTransfer.Create(...) Transfer.the_data. . := queue(@Transfer.the_event); (no Transfer.Free in the thread !!!) running in the MainThread: procedure TTransfer.the_event() begin ... fetch something from the_data ... Free; (this is Actually Self.Free; ) end; -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] AsyncProcess code problem
On 09.06.2017 09:38, Steve Gatenby via Lazarus wrote: I create a thread every second to run a process (TAsyncprocess), then FreeAndNil the process once done. Would it not be more appropriate to use a thread pool and keep the threads up, waiting for a TEvent telling them what to do ? -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] German lazarus forum down
Vielen Dank für den Hinweis ! -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 05.05.2017 12:16, Graeme Geldenhuys via Lazarus wrote: In the end it’s about supporting Unicode. Does it really matter what internal encoding it is to achieve the “Unicode support” goal? Yep it does. There are ways around that issue (i.e. code aware strings) but in fact these trigger a new bunch of problems. You might want to read -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Making sources compatible with Delphi (but Lazarus is priority)
On 04.05.2017 16:56, Juha Manninen via Lazarus wrote: I believe everybody is happy to get rid of the horrendous Windows If if this is true, there is a decent need for backwards compatibility. That is why, theoretically, code aware strings is a good idea. Unfortunately the implementation of those, IMHO, is abysmal, as well in Delphi, as in fpc. (Most obvious drawback: not flexibly typed TStrings.) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Why lazarus is sorely needed: A plea for stability and backwards compatibility
+1 !!! The dream: Write and test a program using in a (partly) RAD way, of course in an Event-programming way, using the Lazarus IDE - say - in Windows. Now just by changing some settings, compile it for - Win32 - Win42 - Win 32 or 64 as a service (hence also running on WIN IOT Core) - MAC - Linux Desktop (PC / ARM / ARM64 / MIPS / ) - Linux Headless (I do have done a working draft for an "active NoGUI" Widget Type) - Android - iOS - with built-in Web Server, the GUI shown on a browser - As a Server based application (e.g. behind Apache or Microsoft IIS) with the GUI shown on a browser -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 20.04.2017 11:11, Graeme Geldenhuys via Lazarus wrote: Yes, many times. There obviously are lots of alternate GUI design tools (e.g. mse, FireMonkey, WXPython (Poenix), ...) . But for Lazarus users, it of course would be beneficial to be able to use the GUI designer already perfectly working in the IDE. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 20.04.2017 09:54, Santiago A. via Lazarus wrote: That is what RAD and GUI designers were created for ;-) Obviously it's not easy to do a (compatible) GUI designer for a Browser-(remote)-GUI. Otherwise I suppose Lazarus would have it. With WebAssembly, maybe there is a new chance... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 19.04.2017 17:21, Graeme Geldenhuys via Lazarus wrote: I believe that is what Michael van Canneyt is working on. It seems like, which to me is great news ! Of course we would need first a Pascal->WebAssembly compiler and then a new WidgetType in Lazarus. Same maybe could be derived from "CustomDrawn", as this also uses Pascal Code to generate the (more complex) widgets. Such code would be translated to WebAssembly and at runtime be transferred to and then executed in the Browser in high speed. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
Re: [Lazarus] Quick Video: A Web Application
On 19.04.2017 16:31, Graeme Geldenhuys via Lazarus wrote: That's very impressive. I'm still amazed at what is actually possible via a web browser - other than just viewing web pages. Thanks for sharing. In fact my little QNAP NAS (an ARM Linux Box) features a GUI vi Browser that is very similar to a Gui that would have been designed by using the Lazarus IDE. AFAIK, they transfer a lot of Java Script from the server to the bowser to have the appropriate widgets created there. So this seems rather standard since some years. It would be great if Lazarus would b able to seamlessly create such programs (even more up to date, versatile and fast: using WebAssembly compiled from Pascal instead of hand crafted Java Script). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
[Lazarus] Zeos SQLite Linux
I'd like to check out working with Zeos and SQLite. I have an "SVN" installation of Lazarus on Linux. So i used same for testing. I found a demo program and when trying this I found it includes the line sLibraryLocation := sAppPath + 'sqlite3_library.dll'; So it obviously is doe for Windows (On Linux it just shows an appropriate Error message.) So the question is to do Zeos / SQLite / Linux ? I failed to find such information yet. Thanks, -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org http://lists.lazarus-ide.org/listinfo/lazarus
