1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications.That already exists since more than 10 years (MSEide+MSEgui):
2. A slick, anti-aliased and zoomable OpenGL application GUI. Especially the text. That is easy to port, runs everywhere and looks much better than the current, pixelated ones.MSEgui has an experimental OpenGL backend. Although I must say that OpenGL is a nightmare to serve as GUI-backend. There are so many different implementations, all with different limitations, extensions and bugs. Especially for text. ;-)
3. Platform-agnostic, message-driven multitasking and multi-threading. Or, in other words: distributed processing.I'll probably will implement such elements in MSElang:
And yes, I will help.You could implement a shader based OpenGL backend for MSEgui. The necessary functions:
1. Lazarus GUI. Make a GUI that works equally well on all compiler target platforms and gives a unique look and feel to all applications. That would be the Apple way. Chance of success: low, without a strong and visible lead.
Why is this in this list, and on the first place? The main bottleneck is a unified compilation platform. No specific syntax, like with Objective Pascal or the JVM target. And coming from that, the incompatible event and widget models. And it would make the most difference in establishing Free Pascal / Lazarus as one of the main development platforms.
And yes, I will help.There are two attempts to make this possible - fpGUI-LCL widgetset and CustomDrawn LCL widgetset. They are far from finished and currently not usable for serious development. The development of the fpGUI-LCL seems to be abandoned and the development of CustomDrawn also doesn't seem to move fast...
1 and 2 are not Lazarus points, and the other toolkits do all kinds of owner drawn work, so that is their turf.You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?
You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?
You don't think that having (1) as an option in LCL would help wider acceptance of Lazarus and FPC?
That depends on how you interpret (1). Polish Apple a bit within the current lazarus constraints: go ahead, but that is no real change from current policies, so I didn't take it that way.
Make something universal as I read it: that will break the lazarus contraints too much or be very unwieldy, so I think there is no realistic outcome of such effort. Not if we can't even get a simple working cocoa backend in 5+ years.
Nativeness on all targets is hard. Even Java GUIs with billions pored into them still feel non-native.
But fully working FPC-drawn LCL-widgetset, maybe will not feel native, but it will give you an option to have same look and feel everywhere. It must be nothing more but an option, the "native" widgetsets have to stay.
I believe that there are people who prefer this to "nativeness" and I believe that having it in LCL will be more helpful for wide-spreading FPC and Lazarus than telling people to go to one-man projects like MSE or fpGUI.
Not because these projects are not good, but new user will certainly more likely decide to stay with FPC if we can offer it in one place with "native" widgetsets, that is inside Lazarus. Inside the IDE with community of developers and users, not one-man project IDE-s. Plus Lazarus would offer easy switch from "OS-native" to "Pascal-native" controls and the other way.
Well, Delphi is as good as dead. And, to be honest: good riddance. As the developments of the last ten years were nothing to write home about.
Delphi is dead
However, these are one-man projects. One man develops, one man decides where the project will go...Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.
[fpgui (maint)]$ git shortlog -s -n
2801 Graeme Geldenhuys
867 graemeg
85 Jean-Marc Levecque
36 sekelsenmat
32 drewski207
26 Felipe Menteiro de Carvalho
21 David Laurence Emerson
19 Andrew Haines
13 Jean-Marc
5 Dibo
4 Jean-Marc.Levecque
4 Michael van Canneyt
3 Andrew
3 David Emerson
2 Philippe Lévi
1 Jean Pierre Anghel
1 Micheal Fyffe
1 Paul Breneman
1 Rodrigo Aliotti
1 Stéphane Aulery
1 Charlie Root
1 Fred van Stappen
1 hinst
1 jean-marc
1 jp anghel
1 ArtSvetlakov
1 Clemens Capitain
Lazarus LCL library with "native" OS widgetsets is a good way, but LCL still needs a good fpc-drawn library, independent from C-libraries gui backends, which can be used as widgetset and look and feel same everywhere.That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).
And STILL they push out new versions faster than us :-)Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. ;) A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.
And STILL they push out new versions faster than us :-)Simply because that makes the people - spending thousands on Delphi licenses per year - feel like they are getting something for their money. ;) A good business tactic. It sucks for the developers though. Nobody upgrades their projects to new Delphi versions that quick.
A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me. ;)What happens to the project, if you would be gone tomorrow?
However, these are one-man projects. One man develops, one man decides where the project will go...Huh? I'm pretty open with fpGUI. Yes I obviously did most of the work, but I also accept many contributions... some were even massive contributions to the core of the framework itself.
A list of contributors and number of commits from each: Doesn't quite look like a one-man project to me. ;)Code: [Select][fpgui (maint)]$ git shortlog -s -n
2801 Graeme Geldenhuys
867 graemeg
85 Jean-Marc Levecque
36 sekelsenmat
32 drewski207
26 Felipe Menteiro de Carvalho
21 David Laurence Emerson
19 Andrew Haines
13 Jean-Marc
5 Dibo
4 Jean-Marc.Levecque
4 Michael van Canneyt
3 Andrew
3 David Emerson
2 Philippe Lévi
1 Jean Pierre Anghel
1 Micheal Fyffe
1 Paul Breneman
1 Rodrigo Aliotti
1 Stéphane Aulery
1 Charlie Root
1 Fred van Stappen
1 hinst
1 jean-marc
1 jp anghel
1 ArtSvetlakov
1 Clemens Capitain
QuoteLazarus LCL library with "native" OS widgetsets is a good way, but LCL still needs a good fpc-drawn library, independent from C-libraries gui backends, which can be used as widgetset and look and feel same everywhere.That's exactly what the LCL-fpGUI widgetset is. I don't actively develop it, simply because I think LCL is rubbish. Very inconsistent, slow, bloated and too Windows-like [on other platforms]. LCL-fpGUI also reduces the functionality, flexibility and power of fpGUI widgets. Saying that, I do contribute patches every now and again to make sure it still works with the latest stable fpGUI. I've also implemented all the basic widgets (excluding TLabel).
just about OpenGL:If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.
Orca from Code Typhon is a OpenGL GUI.
just to mention
just about OpenGL:If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.
Orca from Code Typhon is a OpenGL GUI.
just to mention
just about OpenGL:If my memory serves me right orca is a plagiarism of ksdev DXscene which makes it a legal minefield to use.
Orca from Code Typhon is a OpenGL GUI.
just to mention
What happens to the project, if you would be gone tomorrow? What the "future of fpGUI" would be?The same thing as what happened in the past... It continues with anybody interested. It's open source, the code is right there - available in the open.
I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:Indeed. I fully agree.
I just think that fpGUI (currently at least, this might change in future) have much smaller community than Lazarus,Also take into account that Lazarus [at the time] offered something extra that didn't exist in fpGUI. An IDE, Delphi compatibly, close ties to the Free Pascal project etc. Those were the promised features that drew the crowd towards the Lazarus project. That's what built its momentum.
Yes, I know that is what LCL-fpGUI widgetset is, but it is not fully working (like win32/64, GTK2, Qt, Carbon). Since you think LCL is rubbish, I doubt LCL-fpGUI will ever get into fully working state unless someone else makes serious effort to implement it.Just so you know, I did not start the LCL-fpGUI widgetset. I believe it was Andrew Haines. The biggest lacking widget currently holding back LCL-fpGUI is the TLabel widget. It is that widget which also causes application crashes at runtime when used. TLabel is a classic example of LCL's over engineering and Windows-ism. A seemingly simple widget, yet in LCL it is quite complex to implement. I simply don't have the time [or motivation] to study LCL in depth to figure it out. Implementing the other LCL widgets [I have contributed a few] was actually pretty simple.
And I'm sure he will get full support from you, despite what you think of LCL.Of course. If anybody wants to work on LCL-fpGUI and needs technical information about fpGUI, I will gladly help out where I can.
It is normal that LCL-fpGUI cannot reach the full functionality of fpGUI itself, but having it as fully working LCL backend will be just enough for the need I am talking about.I've always believed that a fully implemented LCL-fpGUI widgetset will be hugely beneficial to the Lazarus project. I know I would instantly recompile the Lazarus IDE to use fpGUI instead of GTK2 or Qt.
I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.Huh. Learn something new every day!
I didn't start the fpGUI project, I found it [abandoned] in a FPC repository.Huh. Learn something new every day!
I always considered you the author of the library.
Age of multimedia. DirectX, DirectShow. Almost not implemented in Delphi.
Age of web (HTTP). Web pages become interactive - Flash, Java, JavaScript. Almost not implemented in Delphi.
Age of portable devices. Small screens with big and simple controls. Not implemented in Delphi.
Age of clouds. Backend for web, distributed computing, hot-swap virtual containers. Not implemented in Delphi.
What can we do? Complete multimedia and web support. There is many libraries and components, but they not included in Lasarus.
Designed in IDE must be works on any local and remote device or browser without extra attention from programmer. Portable devices and web pages need some fundamental modifications in LCL/VCL - virtual controls connected to remote datasource, grids of controls. "Widgets - Data Object - Storage" model.
Distributive cloud computing in virtual containers is very promising, but still too young and evolving. May be PascalScript with simple variables/functions export/serialisation/marshalling will help.
On topic: I see no correlation between "free pascal" as a language, another UI library and state of Delphi. Imho, all three are quite independent entities:
* FPC goes on its own, picking up delphi features here and there
* Delphi goes on its own
* UI libraries live on their own. Usually not using the latest language features.
QuoteDesigned in IDE must be works on any local and remote device or browser without extra attention from programmer. Portable devices and web pages need some fundamental modifications in LCL/VCL - virtual controls connected to remote datasource, grids of controls. "Widgets - Data Object - Storage" model.
I don't think that you must try to do webapplications VCL/LCL style. That was one of the mistakes of the early Delphi web intraweb packages. Yes, it sounds nice to drag and drop a webpage together, but it simply doesn't work that way. Not even back then, and html is a lot more complex now.
Moreover, the website designers are often now separate from the programmers, and like to use other tools.
Personally I think it is smarter to be able to integrate with what's there in the web sphere than to replace it. Only in small business you can actually consider changing the webserver to some homebrewn. And depending on hosting not even there.
There is set of very basic controls/widgets, that present in any user interface - image, button, text, edit field. And some aggregates - vertical and horizontal containers for basic controls (menu, toolbars, lists, accordeons, tabs..). They can be native on some systems, and can be emulated. Most of them already present in VCL/LCL, but many standard widgets come from MS Windows, and do not have implementations on mobile platforms. We can add to LCL set of GUI-independent controls, that not ancested from TWinControl, not contain position and dimension properties in pixels, can be exported to XML/HTML and works on any remote display, from TTY text terminals to future holocubes with mind control. And leave current desctop controls for legacy fine-tuned aplications.
Same for web - if someone create mapper for visual forms to web page, and someone create web-server component, that do all stuff, that application become web application for browsers, then anybody can just design web applications same way as desctop applications, without learning of server backend internals.
About integration in present web sphere - it's compromise, but not ideal way. It's good for mature legacy projects, but very hard for starting over. It must be easy as software installation - specify place to deploy (local or remote), some options (database, account), and deploy! Target can be local WAMP/LAMP webserver or some online application service (Amazon, Google, etc..).
But that means a different designer, a different persistence etc, and you are already not enhancing the LCL + lazarus designer anymore, but having something parallel.
You have to, since coordinate systems are different (as you correctly state), they don't inherit from the same basecomponents (that the designer needs) and html has a more scrolling document layout system.
I have no problem with that, but that only takes over some principles and jargon, not actual code. ASP.NET does the same and generates the related javascript needed clientside .
Though I think the audience will be small, since
- most website design are made by creatives (from the publishing world) not programmers. The programmers are responsible for the layout.
- the small business and private person users that don't have that work division will run into hosting. Shared hosting generally doesn't allow to run binaries, that makes deploying such web technologies hard
The best way to avoid is to have a good UI and logic separation, or simply skip some generations of technology :-)
Huh. Learn something new every day!And fpGUI pre-dates Lazarus. :)
I always considered you the author of the library.
Age of web (HTTP). Web pages become interactive - Flash, Java, JavaScript. Almost not implemented in Delphi.All of the above can and often is implemented using Free Pascal. At least that is true based on the crowds of people I hang around with.
Age of portable devices. Small screens with big and simple controls. Not implemented in Delphi.
Age of clouds. Backend for web, distributed computing, hot-swap virtual containers. Not implemented in Delphi.
We've gone through this before, with TP and Kylix, and speaking from that experience, I'll predict what happens when Delphi dies:What still amazes me is that many companies or developers think Delphi has died many years ago... with Borland Delphi 7. They don't even know about CodeGear or Embarcadero taking it over. At least that was the case in my previous job. They were totally amazed that Delphi was still around. They were even more amazed (and impressed) that there are projects like Free Pascal and Lazarus around that can do what Delphi does [and more], but on multiple platforms.
Huh. Learn something new every day!And fpGUI pre-dates Lazarus. :)
I always considered you the author of the library.
All the communication is then done through messages (records, often with strings).Maybe you should take a look at MSEide+MSEgui then. I believe MSEgui has something like that for some years already [I think it is called MSEifi]. I've never tried it, but from what I've heard it sounds similar to what you described.
I don't want to claim anything, I was simply under the impression that Kassandra was started before Lazarus, and fpGUI/fpGFX/fpIMG was implemented at the time of Kassandra. But this was all long before I even knew about the existence of FPC or Lazarus, so I might have the facts wrong.And fpGUI pre-dates Lazarus. :)No it does not afaik. It does predate Lazarus' win32 backend though, so you could claim first native win32 solution :-)
All the communication is then done through messages (records, often with strings).That looks like remote MSEifi. In MSEifi the server sends the *.mfm form data (MSEgui equivalent for Lazarus *.lfm files) and Pascalscript snippets to the client MSEifi interpreter which could be a browser plug-in or a standalone application. Server and client are connected by MSEifi datapoint- and event-components and communicate with messages. MSEifi components can be used in order to separate GUI and business logic in a normal desktop application. It is also possible to have server and client in a single application so the same application source can be used in remote or standalone code.
The problem is that people want new technologies, but only on old principles. It doesn't work that way.Some sort of "relaxed LCL", where UI design is based on system native tools and rules.
The best way to avoid is to have a good UI and logic separation...
We've gone through this before, with TP and Kylix, and speaking from that experience, I'll predict what happens when Delphi dies:What still amazes me is that many companies or developers think Delphi has died many years ago... with Borland Delphi 7. They don't even know about CodeGear or Embarcadero taking it over. At least that was the case in my previous job. They were totally amazed that Delphi was still around. They were even more amazed (and impressed) that there are projects like Free Pascal and Lazarus around that can do what Delphi does [and more], but on multiple platforms.
In today's world, most companies are completely blinded by the "what's the latest language craze", they simply forget about anything that came before it. That's very sad.
I don't want to claim anything, I was simply under the impression that Kassandra was started before Lazarus, and fpGUI/fpGFX/fpIMG was implemented at the time of Kassandra. But this was all long before I even knew about the existence of FPC or Lazarus, so I might have the facts wrong.
Why are people using free pascal ?One year before I started using FPC/Lazarus, the main reason was the "platform independence" without a runtime interpreter.
Strength of FP? Same as for all Wirthian languages - strong typing and fast compilation. Working in a Wirthian language sometimes makes you cry due to verbosity and stiff type system but these drawbacks have been largely negated by wise design changes over the decades. TP4 basically solved the problems with its' hardware related additions.
I guess asking for Oberon-2 inclusion in the next FPC release is unrealistic? :D
I think we basically have the languages we need and future development should be to make tasks simpler by providing as many ready to run classes as possible and not trying to be all things to all people.
This means if the guy with his Atari ST cannot do all things then so be it. Try to do a few things well and drop the rest. I do not mean to remove support for all minor systems but don't focus on them.
Apple has excelled at this. Also this deliberate removal of options is what made VB and Delphi great - they solved the everyday problems with a lot less coding.
If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.
The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.
Basically this would require an event driven TCP/IP package similar to lNet, a simple 2D graphics library, a minimal set of custom drawn widgets using said 2D lib, a message passing mechanism like DBUS (but infinitely simpler) and some modifications to FPC. It would also be necessary to implement bindings to certain hw features like timers and add reserved words to implement processes. Maybe this is unrealistically much.
What is the fundamental strength of free pascal over all the other languages ?As a language? I vote on strong static typing and safety features (e.g.: overflow and range checking AFAIK is defined as language feature instead of compiler feature)
Why are people using free pascal ?Most articles I read praise the compilation speed while producing optimized enough binaries. Also the bunch of pre-shipped libraries so that people don't need to grab libraries from here and there anymore.
What do they mostly do with it ?Rapid GUI prototyping, scientific computation, ethical hacking and the standard db driven apps.
What is our weakness ?
@leledumbo: I somtimes look at the Underhanded-C contest (http://www.underhanded-c.org/) and (gladly) see that these features are mostly not possible in pascal by design.Add ioccc as well. Like I always said to non-Pascal programmers, Pascal is your friend while programming, it doesn't let you do many stupid things. You'll feel like doing pair programming with your compiler, while when doing that with C it's just a translator tool, although it's trying to be friendlier these days (but you need to specify -Wall all the time).
Why bother if there are X and VNC etc ? I don't see any practical benefit in this, except that it will be very complicated (and multiply versioned, since client and server might not match)The simplest answer is, that most machines nowadays (except the simplest) don't run on a single micro-controller, but include many of them, all connected through various networks. They are all treated like devices, each with its custom interface. And there is a PC at the top level, that most often runs MS Windows, with the GUI application.
And really embedded solutions might not even have ethernet, or too slow to manage lugging around the required bitmaps.
Maybe there is some specialized usecase, but I don't think it is anything mainstream.
The simplest answer is, that most machines nowadays (except the simplest) don't run on a single micro-controller, but include many of them, all connected through various networks. They are all treated like devices, each with its custom interface. And there is a PC at the top level, that most often runs MS Windows, with the GUI application.
What you provide is not an answer. Nearly everything cross-device is either the worst kind of lowest common denominator, or very specialized for a certain app domain.
...
If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.
The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.
...
Ok. How about this one:
Most applications today are also split into multiple parts
...
If I am to contribute new ideas, I guess why not bring up the Internet of Things. I do not know if this is a hype or a dead end, but it is something I have not seen anyone bring up in this thread. I wonder if it might be possible to make FPC for embedded devices like Raspberry Pi, Arduino and similar devices.
The Arduino lacks a GUI and this might be a project that could bring real benefit. I'm also thinking about a complete framework that makes it easy to build a system from Arduinos or similar devices loaded with FPC/Embedded programs and make them communicate in a simple way. There are plenty of Arduinos and add-on boards but not so much in terms of framework and GUIs.
...
This man hacked the Modbus TCP protocol where he stayed in a hotel:
http://mjg59.dreamwidth.org/40505.html
Also KNX is another protocol can be easly hack:
https://www.defcon.org/images/defcon-22/dc-22-presentations/Molina/DEFCON-22-Jesus-Molina-Learn-how-to-control-every-room-WP.pdf
At first all ideas starts with simple way and this simplicity must be change to complexity because of somebody want to make control them.
Actually I am still closing my jalousie (curtain) by hand... IoT is marketing ideas generaly not thinking what will be happen in emergency situations.
Laz/Fpc can provide to implement of your protocol in serial/tcp with by host OS's API.
Also there are some nice components for this:
LazSerial
LNet
EDIT: Word correction
Ok. How about this one:
Most applications today are also split into multiple parts
And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.
Ok. How about this one:
Most applications today are also split into multiple parts
And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.
"Write Once, Compile Anywhere."
You can while sitting in the car, then you are compiling it in the car. :POk. How about this one:
Most applications today are also split into multiple parts
And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.
"Write Once, Compile Anywhere."
Should anywhere be taken so literally?? No, you actually cannot compile pascal code with a car.
You can while sitting in the car, then you are compiling it in the car. :POk. How about this one:
Most applications today are also split into multiple parts
And are so loosely coupled (e.g. over textual web protocols) that various parts can be in differnet languages.
"Write Once, Compile Anywhere."
Should anywhere be taken so literally?? No, you actually cannot compile pascal code with a car.
"Write Once, Compile Anywhere."
Nobody wants 8051 constraints on a PC and vice versa)
And as advanced as Lazarus is, it won't automatically add those roles for you O:-)
Nobody wants 8051 constraints on a PC and vice versa)
And as advanced as Lazarus is, it won't automatically add those roles for you O:-)
Would be nice to have 8051 support for embedded, though ;) in the future O:-)
https://en.wikipedia.org/wiki/Intel_MCS-51
But it is very focused on single-task, database aware desktop applications.That is purely down to your choice. I use Free Pascal for all kinds of applications. That's what makes the Object Pascal language with a rich RTL and FCL so powerful. It is NOT a language designed for a specific task. You can write all kinds of applications equally well with it. eg: I've seen an operating system written in FPC (Object Pascal), a desktop environment with window manager for Linux, general desktop apps, console apps, daemon/service applications, database applications, web applications, mobile applications and the list goes on. Not many languages are so versatile, but that is what makes FPC and Object Pascal so great.
In C++ the choice is simple: you do have to write everything yourself. And in Lazarus, I have to write more and more myself as well.
thought about switching to c++, you can program much faster,
one of major factors that make me prefer pascal over c++ , is the set data type (really helpful). Although it can be emulated with c++ by bits shifting , but in the end it looks really ugly .
Is it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.
like procedure Test;
begin
for x:=1 to 5 do
begin1
while .. do
begin2
(do a lot of work here so it takes up lots of screen space)
for y:=1 to 4000 do
begin3
.. lots of stuff here taking up lots of screen space
end3;
end2;
end1;
in this case i can see which end belongs to which begin
i am not the only one who has constantly count and track where I left out any missing end. i know theres code completion but this never really worked for me.
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends. etc. for example, when i define a pointer the compiler automatically creates a pointer type in the var section of a procedure.
for example, when i define a pointer the compiler automatically creates a pointer type in the var section of a procedure.
Also
suddenly i got an idea!in this case i can see which end belongs to which begin
procedure Test; begin for x:=1 to 5 do begin // for x ... end; // for x end; // proc // this will have a horiz line below it anyway
what really irritates me is the confusion when using lots of nested begin and ends.The indent your code properly, or switch to TAB character indentation (instead of spaces). You can then set your indentation level very easy. eg: 1 TAB could visually be 4 or 8 Spaces. As for larger indentation causing horizontal scrolling... maybe in the past, but with widescreen monitors (or even multi-monitor setups) now being all the rage, that is not a concern any more.
i am not the only one who has constantly count and track where I left out any missing end.As already mentioned, Lazarus's editor highlights begin..end pairs. Many other IDE's and programmer editors do the same thing.
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.It's not a compiler issue, it's an editor issue. Get a smarter editor, or enable the "smart" features of your existing editor.
But NOT the compiler guessing. NO NO.I second that. Compilers ain't any smarter than us when it comes to guessing what we actually want to do.returns undefined, because it guesses the return statement ends at the end of the line. (And Date.now() is unreachable code)
javascript does that, and as a result, it can happen that [code=javascript] function mytime () { return Date.now(); }
It looks like X2nie and Martin_fr are doing some fantastic development on the editor. 8-)
(Modula Mode).Curious. Is there a large Modula code-base that needs to be supported?
QuoteIs it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.
what really irritates me is the confusion when using lots of nested begin and ends.
i am not the only one who has constantly count and track where I left out any missing end. i know theres code completion but this never really worked for me.
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms)....when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.And this is why you use C++? Strange. Which C++ compiler corrects missing }? How is keeping { ... } balanced from keeping begin ... end balanced?
...
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms).
;) (not sure there may be a single codepoint for ;), but I am old school)(U+1F609)
Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.It's self-evident that unlike Pascal, C++ compiler can correct missing "}". The feature comes from the fact "}" is taking only 1-byte, while "end" takes up to 3 bytes of memory (6-bytes for 64-bit platforms)....when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing.And this is why you use C++? Strange. Which C++ compiler corrects missing }? How is keeping { ... } balanced from keeping begin ... end balanced?
...
we do not need any improvements in the pascal language- we need an even smarter compiler that automatically corrects any missing ends.
The same explains, while Pascal is not suitable for writing games. "begin" takes up to 5 bytes of memory (10-bytes for 64-bit platforms), causing a routine or loop to start slower and polluting program memory stack.
C++ compiler just disregards the missing byte. Pascal cannot do that since 2 remaining byes "nd" will cause a fault.
Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.It was an irony ;)
I see. :-[Mmmm.. Wait why the Begin-End structure is handled internally in ready to run binary in long way? Its main is for clarity and human readability on translation stage (programmin) not in translated state (machine code) right? Why it is not handled internally in one byte format, what I'm missing ... a newb is wondering.It was an irony ;)
I cannot take seriously any discussions like "{" vs "begin" or supremacy of C++ over Pascal or vice versa.
I see. :-[your question also proves that you're not as newbie as you think about yourself ;)
I'm one of those who is making games with Pascal (I'm the Allegro.pas creator 8-)) and but I don't understand why the "BEGIN ... END" structure is irritating for game makers. I find it as irritating as C and I did a lot of stuff in C before to port Allegro to Pascal.QuoteIs it because you can type "{" faster than "begin"? And because you type "i++" faster than "i := i + 1" or "Inc(I)"?yes, one of the reasons. when you're really hard-coding games (yes there are still some who do that in pascal) it is very irritating. i know pascal was not developed for game programing. (...)
It will be fantastic if someone would do some devloment in the language too (Modula Mode).
It will be fantastic if someone would do some devloment in the language too (Modula Mode).
I have seen multiple requests for Modula 2 / Oberon extensions, but why?
As far as I understand, both are extensions to make Pascal Object Oriented. But Free Pascal already uses Object Pascal, which does the same.
So, I'm curious: what would Modula 2 / Oberon do better?
IF bla THEN
onestatement;
END;
Well, Delphi is as good as dead.
So, I'm curious: what would Modula 2 / Oberon do better?
So, I'm curious: what would Modula 2 / Oberon do better?Oberon also has OO style that inspires other mainstream languages, Java and Go being the most prominent. I mostly like the amalgamation of interface and implementation section, by using markers for access modifier. Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP). And oh, the grammar is damn simple, much simpler than OP although providing less language integrated features, but proven to be sufficient to even write an operating system.
I also prefer such syntax. I have it in AvrCo Multitasking Pascal for AVR microcontrollers and it's really nice. The only thing I miss more is try..except..finally..end block written in one shot. These 2 things would make code even more readable.So, I'm curious: what would Modula 2 / Oberon do better?The syntax. No need to use too many begin-end. It simplifies typing in most of the cases.
Active Oberon also adds concurrency into the language, a feature that I really want FPC to have someday, while having a closer to Object Pascal syntax for object definition (which is a class in OP).
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making. What if your code block has an if..else statement in it as well. The compiler might interpret it one way, each developer might interpret it another.
try if TestCondition then DoThing1; DoThing2; else DoThing3; DoThing4; DoThing5; end; except HandleException; finally FreeAnythingCreated; end;
try
...
except
on e: E1 do ...
on e: E2 do ...
on e: E3 do ...
end
The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.
The main problem with concurrency in all programming languages / models I know, is the use of threads with shared memory.And that's why concurrent programming is considered a different paradigm ;)
If you have two threads, that both access the same variable, you are encouraged to use a mutex to lock and unlock that variable. This is how it is done.
And that's totally the wrong way to do it.
Every time you lock the variable, you serialize the application. And not only that, but it incurs a large overhead and makes context switching take ten times as long:
- The shadow registers need to be cleared.
- The pipeline needs to be flushed.
- The cache memory needs to be partially flushed.
- the page tables need to be refreshed.
In the time that takes, the CPU could have done more work than a 8086 could do in a whole second.
Ergo, working like that makes your application slower instead of faster.
That's why the amount of CPU cores on Intel x86 processors first climbed up to 16, and is now back down to max four. Simply because few people have figured out how to use them effectively.
Essentially, you need to give each thread its own (thread-safe) message queue, which triggers execution on post. And use that for both events as well as data passing. That increases the latency, but the throughput as well.
There should be no shared memory. If you want to pass a block of data, allocate it on the heap, post the pointer and nil your own copy of the pointer.
Perl's variables are thread local at default.
Smalltalk has message passing
Qt has a similar signal/slot mechanism
Go has its channels
In functional languages variables are immutable, you do not need locking
And that's why concurrent programming is considered a different paradigm ;)Well, of course. I agree.
When coded properly, concurrent programming DOES make your app runs faster. Try my UPX wrapper (https://bitbucket.org/leledumbo/express), compress tens or hundreds of exes/dlls/whatever file type UPX can handle. Compare the total time taken with thread count = 1 and = number of cores in your CPU.
No problem with concurrency if one pays attention to the limiting factors. In my company, I create a concurrent message queue processor. If different kind of message are in sequence, they are processed in parallel without waiting. This increases the processing speed, A LOT, especially in case of heavy traffic situation because the request processing is less likely to timeout.
D also has all its variables on the thread local storage (TLS), unless they are annotated with "__gshared" or "shared", and two multi thread paradigms: "MessageBoxes" that allow to easily send receive between threads and "Tasks". Even with mutable data you don't need to lock all the time, but only when you access non-TLS data. I think all modern compilers do something like that nowadays.Yes, local variables in FPC reside on the stack, which is thread-specific. Unless they're objects.
Actually I'd surprised if someone tells me that FPC doesn't put the variables declared in a class or a struct on the TLS.
I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making.I don't think so. Unlike in 'old' Pascal, in newer Wirthian languages each if requires an end. Therefore your example would not be valid, and such syntax makes sense. You already use mentioned syntax with try..finally..end block. No need for begin/end and you can write more then one command inside of the block. If that is logical to you, I don't see any other reason beyond legacy for not liking it. Code looks much cleaner and easier to follow.
@Ñuño_Martínez just asking why there is multiple engine and wrappers for making game with Pascal? is it good really in compare of other popular engine? what games these Pascal ones are good at?There are multiple engine and wrappers for making games with any language. Get C/C++: You have Irrlitch, Unreal Engine and DooM engines, and you can go for older stuff and can use Build, Genesis3D and more. If you go to libraries, you have DirectX, Allegro, SDL and more.
I like Pascal very much but I want to know what can these Pascal engines do in compare of existence big and reliable engines?
You already use mentioned syntax with try..finally..end block. No need for begin/end and you can write more then one command inside of the block.
To be sincere, I miss QuickBASIC.Actually: I am missing Turbo/ PowerBasic.... Which once was QuickBasic on steroids.. ;)
Both of them, presents blocks without BEGIN ... END.You forgot to mention labels ;) Which can also be blocks without begin end.
Gosub sleep`?Both of them, presents blocks without BEGIN ... END.You forgot to mention labels ;) Which can also be blocks without begin end.
Oh, well, I should goto sleep..
Gosub sleep`?Both of them, presents blocks without BEGIN ... END.You forgot to mention labels ;) Which can also be blocks without begin end.
Oh, well, I should goto sleep..
In my opinion having both options (single statement and blocks) is quite usefull. I often use single line ifs and dos, it makes the code short and easy to understand.I like the try...finally...except...end idea, but your above code example without begin..end blocks is a nightmare in the making.I don't think so. Unlike in 'old' Pascal, in newer Wirthian languages each if requires an end. Therefore your example would not be valid, and such syntax makes sense.
Line breaks are parsed as whitespace only.
The only time I ever use single-statement ifs is these:
]
Because of the chance I overlook it and do things like:
if Something then DoSomething; DoOtherThings; if SomethingElse then Exit;
if Something then ; DoSomething;
See pic, that issue can be made easy to spot. Since code completion sometimes places a ";" while typing the if condition, the problem is not that uncommon.Ugh... not sure about future of FreePascal, but looking at Lazarus configuration screen ... it is complex :)
I detect it with 0 or 1 space. But one can add more space too. As long as the ; is on the same line.
F1 should take you right here: http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_User_Defined_Wordsindeed, F1 worked :) I guess I never realized that wiki help works by default.
IIRC there was/is a request to make the list of word part more intuitive. Matter of time to spent on it.
Did you notice that "Delete List" is only refreshed on the opening of the dialog.Please report on mantis
Please report on mantisWill do.
A possible syntax could be using the line break after then-statement as indicator if its a single statement or a block with following end-statement.
Then why are there no multiline strings?
btw, why it's own tab, rather than under Colors?Because it has plenty of settings other colors do not have. And they would not really fit on the color tab (keep in mind, that the option dlg may be resized, and quite small)
I know it is not the same, but the IDE can at least help a bit here.Then why are there no multiline strings?
I ask the same. This is a feture I really love in other languages.
Because it has plenty of settings other colors do not have. And they would not really fit on the color tab (keep in mind, that the option dlg may be resized, and quite small)But "Preview" of "Colors" is very helpful.
You must be hating JSON then :DThen why are there no multiline strings?I ask the same. This is a feture I really love in other languages.
Lazarus seems to parse the indentation to automatically insert an end; at the right place
Except for case statements. There it always puts the end; at the wrong place
Line breaks are parsed as whitespace only.
They are?
Really?
Then why are there no multiline strings?
They are not! Checkmate
The only time I ever use single-statement ifs is these
Because of the chance I overlook it and do things like:
That's also why using line breaks as syntax elements is not a good idea.Agree. But don't tell that to all those Python lovers: They'll keell you...
The moc tool reads a C++ header file. If it finds one or more class declarations that contain the Q_OBJECT macro, it produces a C++ source file containing the meta-object code for those classes. Among other things, meta-object code is required for the signals and slots mechanism, the run-time type information, and the dynamic property system.
The C++ source file generated by moc must be compiled and linked with the implementation of the class.
One counter example doesn't fully invalidate a principle.Well: https://en.wikipedia.org/wiki/Falsifiability (Karl Popper is my hero, so I am biased)
Agree. But don't tell that to all those Python lovers: They'll keell you...
C++ is а problematic, dead-end bloated language. ...Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.
In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.
Yeah, just like how BCB killed Visual Studio. NOT.
BCB was actually a very smart move and I personally know several people who use it professionally for scientific projects. But how would you expect it to "kill" Visual Studio, when the latest one is provided by the same OS manufacturer?
Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations. So you have IDE that can only run on Windows, VCL that can only run on Windows and third-party C++ compiler being a link between them, all of that against Visual Studio, which is native development tool on Windows and is the first one to receive all new bells and whistles from the same OS manufacturer.
So the future of fpc is C++?Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations. So you have IDE that can only run on Windows, VCL that can only run on Windows and third-party C++ compiler being a link between them, all of that against Visual Studio, which is native development tool on Windows and is the first one to receive all new bells and whistles from the same OS manufacturer.
Lazarus, on the other hand, runs on multiple platforms and, if not counting Pascal dialect, is a fully functional editor on its own, in many aspects, potentially best of its kind. Even if there could be issues porting LCL to another language, say C++ or Swift, for example, there is an existing functional Pascal port of LCL on many platforms, which has working solutions for many low-level cross-platform technical issues. As a result, creating a whole new framework based on LCL is still much easier than designing, creating and debugging a new one from scratch.
So the future of fpc is C++?Is that all you can synthesize from the above conversation? Only one of my points was that Lazarus/LCL can be extended and/or ported to different languages. As for future of adoption of FPC, that's quite speculative, but it really depends on where FPC devs will lead it to; in my opinion, focusing on finishing full support for embedded platforms will very likely increase chances for it to become more popular, as there is less competition there.
Actually I got 3 points. 1) add c/c++ support to lazarus 2) Convert lcl to C/C++ and 3) everythings dies perhaps its time to leave pascal behind and move on. Then again I'm notoriously slow so I'm probably missing something. Then again I agree with you. Pascal's time reached its end. There is a new technological wave in the embedded front which they could take advantage of but the world is already C/C++ java and C# it has nothing to offer.So the future of fpc is C++?Is that all you can synthesize from the above conversation? Only one of my points was that Lazarus/LCL can be extended and/or ported to different languages.
Actually I got 3 points. 1) add c/c++ support to lazarus 2) Convert lcl to C/C++ and 3) everythings dies perhaps its time to leave pascal behind and move on. Then again I'm notoriously slow so I'm probably missing something. Then again I agree with you. Pascal's time reached its end. There is a new technological wave in the embedded front which they could take advantage of but the world is already C/C++ java and C# it has nothing to offer.In a sense, yes. From what it looks like, the entire Pascal community (Delphi and FPC/Lazarus combined) now is rather small. I would speculate that many people who still stick exclusively to Pascal are those who have large codebase that cannot easily be moved somewhere else; some are realistically so, others just due to escalation of commitment (https://en.wikipedia.org/wiki/Escalation_of_commitment).
The reality, however, is that Pascal by itself is nothing special, it is just a language (just as others are, like C++, Java, etc.), and RAD paradigm that was revolutionary back in earlier Delphi days is no longer new - there are many alternative UI / RAD tools now, many of which are also cross-platform.Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards. I think that pascal has a lot of merit and it is compatible with my train of thought. So as a language it has its uniqueness that makes things different enough to be unpopular. As for the rad part, I haven't used any of the apple's tools but even in visual studio only the windows form designer has a good flow and feel to it. even the wpf designer is lacking I'm not going to touch the open source designers where to even be able to place controls on a form you have to decide how they are suppose to behave when the form is resized. There is no RAD tool I found out there that comes close to what lazarus with all its problems has to offer. Sorry but there is nothing RAD to codeblocks, codelite or devc++ they are mediocre IDES at best or good editors at worst. Then again I might missed a good IDE other that visual studio.
Because exactly the same would happen to its open source equivalent. Lazarus and FPC are developed in tandem, and to my best knowledge C++ needed both extension and careful alignment to work with VCL.I understand what you are saying but don't quite agree. For one, to the best of my knowledge (and limits of NDA), there is no C++ port of VCL, at least not a complete port, and with purpose, so any changes/upgrades to VCL in Delphi would automatically be felt on C++ side, perhaps with some header adaptations.
Stumbled upon Free Pascal is very super mega ultra underrated. (https://www.reddit.com/r/ProgrammingLanguages/comments/4etdnc/free_pascal_is_very_super_mega_ultra_underrated/) post few days ago, which seems relevant to this discussion.C++ is а problematic, dead-end bloated language. ...Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.
Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards.
Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" (http://c-faq.com/decl/spiral.anderson.html) by David Anderson.Though I like C, can't say the same about C++.
That is the reality of choosing a development platform based on what you can actually achieve with it, rather than watercooler discussions "but there is some C++ project that does ... ", and "if you just port LCL to C++" on the back of a beercoaster.No need to be so too overprotective with this. Nobody said to take Lazarus away from FPC. :) I just simply acknowledged that Lazarus as IDE and LCL, in their own way, if could somehow get to C++ landscape, in my opinion, they would make a killer product. You think they won't? Okay, your opinion is just as good as mine. :)
Sorry but there is nothing RAD to codeblocks, codelite or devc++ they are mediocre IDES at best or good editors at worst. Then again I might missed a good IDE other that visual studio.I think you didn't mention quite a few RAD IDEs (lists can be found somewhere in the middle of this (https://en.wikipedia.org/wiki/Graphical_user_interface_builder), this (https://en.wikipedia.org/wiki/List_of_graphical_user_interface_builders_and_rapid_application_development_tools), this (https://en.wikipedia.org/wiki/WxWidgets), and this (https://en.wikipedia.org/wiki/GTK%2B#Development), and probably many others, I doubt in finite time one can try them all to give accurate generalizations) and those that you mention are not UI RAD IDEs by themselves, they are editors and first two (can't say anything about DevC++ as I've never used it, especially since it's Windows-only) are pretty good at what they do.
Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.It sounds like you haven't actually actually used many other languages for production, yet you still try to make large scale generalizations and predictions. You probably can do much better if you actually get to learn stuff that you easily dismiss (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect), so please stop this non-sense.
Now is a completely different context.
...
The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.
No need to be so too overprotective with this. Nobody said to take Lazarus away from FPC. :) I just simply acknowledged that Lazarus as IDE and LCL, in their own way, if could somehow get to C++ landscape, in my opinion, they would make a killer product. You think they won't? Okay, your opinion is just as good as mine. :)
Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.It sounds like you haven't actually actually used many other languages for production, yet you still try to make large scale generalizations and predictions. You probably can do much better if you actually get to learn stuff that you easily dismiss (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect), so please stop this non-sense.
Now is a completely different context.
...
The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.
What programming language does Ultibo use?
Ultibo is written entirely in Free Pascal and is designed to act as a unikernel or a kernel in a run time library. That means when you compile your application the necessary parts of Ultibo are automatically included by the compiler so that your program runs without needing an operating system.
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.
In the thread about future of Free Pascal you are posting about adding support to C++ in Lazarus(whatever that means) and advising to learn stuff.That is correct. :)
One of the biggest problems I have with C++ is the plethora of GUI libs without one being really dominant (QT and MFC comes closest). And QT is pretty but has MOCing issues, and no native windows offering and I never really liked MFC, it felt too much a macro set on top of winapi rather than an integrated offering.Yes and this is why I like LCL approach more, where it really uses native controls on multiple platforms and its usage is pretty clean and intuitive.
Some talk have been made about embedded, I'm sure for most active readers/writers this project isn't nothing new, but for us newbies. :)Ultibo is quite nice, curiously I just checked it out few days ago and had no idea it used FPC. Raspberry PI is great, but by embedded platforms, I primarily meant embedded ARM and AVR. One of the things I would really love to see on somewhere around this web site, is a precompiled FPC/Lazarus bundle that can arbitrarily target Arduinos, much in the same way as Arduino IDE does. FPC already supports great deal of AVR chips and combined with Lazarus as IDE, it would be a much stronger alternative to Arduino IDE. Even so, maybe someone from FPC dev team can contact Arduino, asking for their financial backup to support a superior development platform? (I know they are probably trying to develop something of their own, but still...)
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards.
Repeat..until
For..in..do
For..to/downto..do
While..do
Variable declarations and types declarations are done right.
A good explanation what's a difficulty with C declarations - Go lang declaration syntax: https://blog.golang.org/gos-declaration-syntaxQuoteGo's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" (http://c-faq.com/decl/spiral.anderson.html) by David Anderson.Though I like C, can't say the same about C++.
or in the worst case a DIY document how to patch or convert one for that hardware.So do we (http://wiki.lazarus.freepascal.org/TARGET_Embedded), in a more general way as the options still need to be tailored for the specific hardware. "The rich gets richer, the poor gets poorer" applies in commercial programming industry. Vendors are likely to pick up major languages that can fit their hardware. Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup. You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.
So do we (http://wiki.lazarus.freepascal.org/TARGET_Embedded), in a more general way as the options still need to be tailored for the specific hardware.No you don't, you have a generic how to code for embedded systems. I'm talking about specifics. You missed the point completely.
"The rich gets richer, the poor gets poorer" applies in commercial programming industry.That's BS. It is not the commercial environment that has that effect and open source does not help to stop poverty. Lets not confuse the issue with useless politics.
Vendors are likely to pick up major languages that can fit their hardware.Vendors will pick up whatever benefits them the most, language is not a direct variable on
Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup.erm fighting what or whom exactly?
You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.OK, I'll byte, share with us your
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.
Well I have heard that many times over the years. Considering that C++ started as an extension that compiled code to C and not directly to cpu code it has more than 50% of language idioms shared with C that in my book makes them the same language, then again I consider turbo pascal 6~7 dialect the same language as delphi and object pascal, so interpretation is subjective and plays no major role on the syntax of those languages that was the topic on my comments not so much the features of each language. EE I do not think that FPC supports direct initialization of non local variable at all and I'm not sure it supports array initialization outside the const declaration. When I say got things backwards I mean declaration wise ee int X,Y; instead of X,Y : int; etc;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.
C and C++ are different languages.
C99 standard has some features not available in C++: https://en.wikipedia.org/wiki/Flexible_array_member.first time encountering these constructs but if my interpretation is accurate then I need to read up on them. Thank you.
C99 array initialization(for C++ it was implemented only in g++ -std=c++11):
int widths[] = { [10 ... 99] = 2, [0 ... 9] = 1, [100] = 3 };
Initializing array of struct:
struct { int x,y; } ar[ 4] = { [1].x=23, [3].y=34, [1].y=-1, [1].x=12};
On the other hand, it took decades for C to start promoting types with defined size: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Also:
int_leastN_t - signed integers with a width of at least N
int_fastestN_t - fastest signed integers with a width of at least N
All those features are good and all but it is not the features that will help the future of a language. I think that uniqueness, comfort and speed of development is. I'm all for the "complete form" (sorry I'm stuck can't remember the proper word for it) of code that pascal supports but it needs to add features to reduce code from somewhere else to give an impression of smaller and easier to understand code base. Let them find their unique position on the market. RAD is a good arrow on their quiver along with the homogeneous component library but they suffer a bit on granularity. By the way no C/C++ is not the future of FPC nor Java, .NET, python or any other language. They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.
There's no Boolean type in C.
Some type hints in C prevent or advice compiler's internal optimizations: volatile, restrict("restricted pointers", a hint).
Free Pascal has "absolute" keyword, practically undocumented, although the de facto convention is that compiler does not perform optimizations that would lead to necessity of compiler hints.
This area is still grey for me.
All those features are good and all but it is not the features that will help the future of a language. I think that uniqueness, comfort and speed of development is.
They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.
One mistake(IMO) I noticed in the implementation, is making "program" statement optional. It was required in TurboPascal as I understand.Nope, in fact the optionality is a leftover from TP. It was required in ISO Pascal and FPC's ISO mode respects that.
Stumbled upon Free Pascal is very super mega ultra underrated. (https://www.reddit.com/r/ProgrammingLanguages/comments/4etdnc/free_pascal_is_very_super_mega_ultra_underrated/) post few days ago, which seems relevant to this discussion.C++ is а problematic, dead-end bloated language. ...Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.
When Delphi first appeared, the whole RAD approach coupled with a relatively sufficient language made it quite popular decades ago, but currently many other languages are quite enough and there are plenty of UI/RAD solutions out there. Really, there is nothing wrong with using C#, C, C++, Java or any other language these days (e.g. Swift) for application development and each of them, coupled with a huge collection of frameworks and libraries, are enough to work even on most challenging projects. Delphi, FreePascal / Lazarus work just fine as well, but since "Pascal" community is so small, it's difficult to convince companies and crowds to use a language that is unpopular and doesn't offer any significant benefits; in fact, at this point, no such language can possibly appear - existing languages already cover most needs, except, perhaps, for growing areas such as GPGPU, parallel computing, etc. - but these are pretty much saturated as well.
In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.
For instance, I can't help but to read posts regarding BGRABitmap with a bit of nostalgia attached to it - just to think of the things you could do in Delphi with TBitmap.Scanline some almost 20 years ago (and let's not forget about Graphics32 component too), and the whole thing of displaying more than 256 colors on the screen after DOS (please don't get me started with VESA) - these were some glorious days back then. I still remember walking like for two hours under the snow just to buy my first 3dfx Voodoo (was in Canada at that time) - it was so exciting! (Among many GPUs, Voodoo3, was the most exciting and pleasant to work/experiment with).
However, as almost every IT specialist who is old enough, would likely to experience this, even multiple times during lifetime, in computer world we have to realize that technologies that were so glorious many (and sometimes, maybe just few) years ago may become obsolete and we have to, un-learn and re-learn something entirely from scratch - and not necessarily because new tech is better than old one, but it's just happens. I'm not saying that this is necessarily going to happen (completely) with Delphi/FPC/Lazarus that some/all of us are using, but IMHO it's a tendency that becomes difficult not to see.
...however, the concept of adding some kind of C++ Builder-clone functionality to Lazarus is just a bad idea. The Borland C++ compiler is and always has been the absolute worst (just embarrassingly bad) commercial C++ compiler available (there's a very good reason Embarcadero recently scrapped it completely in favor of Clang), and everything about the C++ Builder IDE is just "ok, this sort of works, it's kind of like Delphi I guess, but not as good". Any attempt to imitate it would just be an attempt to imitate something that was mostly a running joke to begin with.I wouldn't say that C++ Builder's compiler is bad, but I personally am not fan of the whole trend (that started lightly with Turbo C) of adding proprietary extensions to the language, to a point where the code would become completely alien to a different compiler, requiring a significant rewrite. I have same issue with Visual C++, although I really like their introduction of properties (https://msdn.microsoft.com/en-us/library/yhfk0thd.aspx), too bad GCC/Clang don't support it. But my point wasn't to create C++ Builder clone, rather than just porting LCL; in fact, initially, it doesn't need to have WYSIWYG editor - this can be done later. In fact, I don't think that any RTTI limitations in C++ should be a barrier for this - it is possible to create/load visual forms without it (in fact, Asphyre's UI and its WYSIWYG designer didn't use RTTI at all yet still worked).
I might add - as I did before - that it is perfectly possible to write readable C++ (yes, really!) . And it is also possible to make Object Pascal as unreadable as some C++ (yes, really!). All these discussions are often based on comparing apples with pears.Absolutely agree. In fact, I think every language can have these extremes.
What is a fact, though, is that C++ oriented programmers tend not to know about the current capabilities of Object Pascal, refer to their "knowledge" that is at least 25 years old and therefor dismiss it for the wrong reasons.Remember that the same happens in reversed roles, and IMHO, to a higher degree - especially because of complexity of C++ and intensive additions to the language, starting with C++11, then C++14 and still ongoing with C++17.
I also recall, back in 2000, when a friend of mine used Delphi to create some sort of logic analyzer, where in form's "OnCreate" event he would start application main loop and never return, calling "ProcessMessages" to handle UI events. In same application, he would use TListBox with size to fit exactly one item, which with its miniature scrollbar (just big enough to accomodate up/down arrows, no client area) would essentially work as some sort of "Top/Down Spin Box", but more obscure as you can have one or multiple items selected, that are not what you currently see in such "spin box". This might not be example of "unreadable code", but it's an illustration that you can screw up, if you really want to, in any language or development tool.
I feel like many people (Object Pascal programmers and also just people in general trying to learn C++) are often scared off because so many of the examples out there use the idiotic "K&R" bracing style
Well, Delphi is as good as dead.
The company is still in business, the product is still being sold. On what basis are they "as good as dead"?
I think Embarcadero don't know what Delphi was/is and what they can do with it. May be they look Delphi as a problem instead of an answer. Pretty sad. :(
Don't mix up the product with the language. The product Delphi is no longer breathing. The language that is on many ways its heritage isn't.
The problem is using it in the newer environments of web and clouds, etc. So I only have one problem, getting the Pascal compilers and IDE to develop run time code for the newer environments.What's your problem exactly? I've been writing server-side web apps on clouds using FPC just fine. For example, you could try CodeAnywhere (https://codeanywhere.com)'s VPS service (it offers free account with some limitations but you can use it without problem), install FPC on it, and write some web apps. Here's my account on CA, cak.lebah.web.id (http://cak.lebah.web.id) where I experiment with FPC and Swift.
The problem is using it in the newer environments of web and clouds, etc. So I only have one problem, getting the Pascal compilers and IDE to develop run time code for the newer environments.What's your problem exactly? I've been writing server-side web apps on clouds using FPC just fine. For example, you could try CodeAnywhere (https://codeanywhere.com)'s VPS service (it offers free account with some limitations but you can use it without problem), install FPC on it, and write some web apps. Here's my account on CA, cak.lebah.web.id (http://cak.lebah.web.id) where I experiment with FPC and Swift.
Object Pascal is not really that old:Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.
PHP, JavaScript, Ruby and Java all went public in 1995, when Object Pascal did.
Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.I said that it went public in 1995, which is correct.
Wrong. Object Pascal dates from 1986. https://en.wikipedia.org/wiki/Object_Pascal.I said that it went public in 1995, which is correct.
I am not confusing Delphi and Object Pascal here because Delphi is indeed the foundation of modern Object Pascal.
With emphasis on 'modern'.
It's like C, if you treat it like you treat object pascal, you would include A and B, wouldn't you? :p
After 9 versions of Turbo and Borland Pascal compilers, which gradually extended the language into the Object Oriented Programming (OOP) realm,Borland released Delphi in 1995, turning Pascal into a visual programming language. Delphi extends the Pascal language in a number of ways, including many object-oriented extensions which are different from other flavors of Object Pascal, including those in the Borland Pascal with Objects compiler (the last incarnations of Turbo Pascal).
all language constructs except classes, interfaces and exceptions are supported. Objects are supported in this mode.
I am not sure what you are after, but FreePascal can be configured to use different modes:Not exactly.
almost as good as Delphi 7
i would have liked to see all the object oriented stuff dropped
But truth be told FCP/Lazarus is no match for modern day Visual studio, C# and .net, especially now that you have free community edition of VS and .net being open sourced.
Just my 2c, don't shoot the me :)
Don't be a fucking moron, Thaddy.Well. Commercial interests are interesting. I would rather see that you stick to the facts.
Modern Object Pascal := Delphi.
What went before that leads up to the language that we use now:
And I really don't think that it's stupid.
But truth be told FCP/Lazarus is no match for modern day Visual studio, C# and .net, especially now that you have free community edition of VS and .net being open sourced.
Just my 2c, don't shoot the me :)
How can you describe the "Modern Day" ? I think you mean popular culture of desktop/backend(Server side) programming.
I am still using delphi and fpc for production lines , as scada solutions (pascal scada) , testing softwares in very hard conditions.
Ok we won't shoot you :)
Is there any machine learning or sentific algorithm library written in pascal? :(
Modern day as the latest versions, so VS 2015 & 2017, .net 4.5 +, C# 6.0 +, and so on.
I remember when I was using D7 and then went to college where I started with Java and early versions of Eclipse and C# with visual studio .net 2002. For me it was like going back in time.
But now the situation is reversed VS studio, C# and .net is so much better and same for PyCharm + Python 3.5 or InteliJ + Java & Kotlin & Scala. These tools and languages surpassed FPC/Lazarus by a long way. It's understandable since their development is driven by companies and larger communities.
And yes FPC/Lazarus is still viable to use for existing projects, why change something just for sake of changing tools.
But for new projects I see less and less reasons to use FPC/Lazarus or any other compiled language, since modern managed or scipting alternatives are so much better.
Except for kernel, drivers or some low level libs, but for that I would use C which is still de facto standard.
Modern day as the latest versions, so VS 2015 & 2017, .net 4.5 +, C# 6.0 +, and so on.
I remember when I was using D7 and then went to college where I started with Java and early versions of Eclipse and C# with visual studio .net 2002. For me it was like going back in time.
But now the situation is reversed VS studio, C# and .net is so much better and same for PyCharm + Python 3.5 or InteliJ + Java & Kotlin & Scala. These tools and languages surpassed FPC/Lazarus by a long way. It's understandable since their development is driven by companies and larger communities.
-- OK. We are a small community means they have got a lot of power we expect more powerful tools from them... ;)
Uh, I think you mean "way, way better than Delphi 7 in every conceivable way." Seriously, have you tried to use Delphi 7 recently?Have been using it for over a decade, and seriously i'm only comparing to it because it's the only other pascal IDE with language&debugger integration there is to compare to.
I suppose in your perfect world we'd all still be using Turbo Pascal on DOS? ;)Good horrors, no.
there are simply far too many people who for whatever reason view ancient IDEs/Compilers through rose-tinted lenses.Honestly, seeing where Borland went after D7, i'm not too surprised.
I HATE >:D DotNet-UpdatePackages and C++ RedistPackages and Java-Runtime-Crap and even more stupid developers and companies that aren't able to write down those requirements where I can see this immediately. I don't want so recognize that when installing or testing a new software.Well, first do any course in computer science. I would advise pre-beginner.
Well, first do any course in computer science. I would advise pre-beginner.Thanks for the tip, but I don't want to get brainwashed to love all this ... I think there are enough people who think this way and I just want to keep my position for a while...
Is there any machine learning or sentific algorithm library written in pascal? :(
http://forum.lazarus.freepascal.org/index.php?topic=32620.0 (http://forum.lazarus.freepascal.org/index.php?topic=32620.0)
I HATE >:D DotNet-UpdatePackages ...
@Handoko: me too...
That's exactly the same with C++: I installed the 2010-Pack and several 2013-Packs and an old ChessPRG requires the 2008-Package. What ?! And of course that one won't install on Windows 7. Once I had the 2008 Package installed, but I can't remember how...
@Handoko Windows 7 have built in .net 2.0 package installed aside with .net 3.5. No separate package is required for .net 2.0.
The future of Free Pascal? As an open source project it will live forever. For real-world work there isn’t any future - use Java (the #1 language in the world) instead.
The problem is that most programmers do not want to see their mistakes and start programming without any clue about what they are trying to do.
Object Pascal tries to prevent you from making those mistakes.People make mistakes. At least both Kernigan and Richie admitted that (both loath that they invented half a language) . Soustrup has - while he is still alive - a huge problem keeping the hornet nests in a somewhat regulated order. And Pascal is still readable and prevents you from making silly assumptions.
{int (follows a macro explaining basically nothing) i; // index declared somewhere else... ...several thousands of lines further, while i is supposed to be still valid.....but one of the team forgot.... ..... i:= 100;{// oh, I forgot a variable, lets call it Z (not z)...\n }}
var i: integer;
begin
for i := .. to ... do begin
end;
// long code
do something with another variable, but accidentally type variable i
end;
{
for (int i=..;i<=..;i++) {
}
// long code
do something with another variable, but accidentally type variable i
}
However, compared to it Lazarus still lacks some vital features like multiple source editor window supportThat exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_Editor
Pretty much the only show stopper is the scaling - give me a way to work comfortably on a hundred file project in Lazarus, and Delphi 7 would go down the drain.This will also help: http://wiki.freepascal.org/New_IDE_features_since#Project_Groups
A project group helps only with many related projects. I understood the hundred files belong to one project.Pretty much the only show stopper is the scaling - give me a way to work comfortably on a hundred file project in Lazarus, and Delphi 7 would go down the drain.This will also help: http://wiki.freepascal.org/New_IDE_features_since#Project_Groups
...use Java (the #1 language in the world)Maybe that's true, but the fact that many people use JAVA or buy a certain book or do whatever doesn't mean that this has something to do with quality. More often it's the other way around...
That exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_EditorExcept it does not work like that - either you have to use non-docked mode, which is completely unusable due to a horrific amount of disconnected clutter on the screen, or you use docked mode and have to have all the editor windows on screen all the time.
Artlav, what exactly does not work with hundred files?Switching between them in a quick fashion.
In Lazarus, i haven't yet found a way to either get several editor tab sets or windows without producing an explosion of clutter, or in some other way to quickly go to an arbitrary file in a project.I often keep 2 editor windows open, side by side, both almost from screen top to bottom. More than 2 would be clutter, yes, but so it would be with Delphi 7.
Like in D7? Sorry, couldn't resist :DThat exists for a long time: http://wiki.freepascal.org/New_IDE_features_since#Multi_Source_EditorExcept it does not work like that - either you have to use non-docked mode...
Thanks for the link, however - this is quite a useful page, and i haven't even imagined looking for some of these features...You're welcome.
Maybe that’s true, but the fact that many people use JAVA or buy a certain book or do whatever doesn’t mean that this has something to do with quality. More often it’s the other way around…Normally (but not always) quality comes from a lot of people using a product. Having millions of developers working with Java, and 100’s developing it definitely adds to Java’s quality. The massive eco system, and 3rd party support in very very impressive too.
I really don’t know why they don’t create at least some kind of backward compatibility. Maybe they are not smart enough…I can’t speak for C++ or DotNet, but Java’s backward compatibility is once again very impressive. Just recently I used Java class files (I don’t have the *.java files any more) in a new program. Those original class files were written and compiled around 2002-2004, and they still worked with my program compiled in 2017, using the latest JDK!! If that’s not good backwards compatibility, then I don’t know what is. Either way, you can’t do that with FPC’s *.ppu or Delphi *.dcu files.
Like in D7? Sorry, couldn't resist :DNot quite.
In Lazarus the editor bookmarks are global for all files, not local for each file like in Delphi.That's rather neat.
Just recently I used Java class files (I don’t have the *.java files any more) in a new program. Those original class files were written and compiled around 2002-2004, and they still worked with my program compiled in 2017, using the latest JDK!!What sort of dependencies did these class files have?
I simply posted about Java as a joke.Yeahh, I know... :)
That's nearly a show-stopper level of annoying.That may be a little exaggerated.
Anyone know how to fix this?Symlink handling has improved in trunk. See:
Symlink handling has improved in trunk. See:Tried out the latest SVN.
http://bugs.freepascal.org/view.php?id=31260
Please test and report back.
That may be a little exaggerated.Random breakpoints that you can't remove because it was set in another version of the file?
I can’t remember the last time I used a program that requires JAVA RUNTIME,I actually use a lot of Java based programs here. UMLet, jEdit, Eclipse IDE, trolCommander etc. Installing the JRE (actually the JDK - just in case) is one of the first things I do after a new OS install.
I just hate this never-ending C++/DotNet-PackageInstallBullshit.DotNet is totally pointless for me. It’s a bad ripoff of Java, since SUN sued Microsoft all that years ago.
I hate it when I see a nice program and that program needs DotNet 4.5 for example… Then I always think “Hey why can’t you use OBJECT PASCAL or FREE PASCAL or maybe C…”My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.
I can’t remember the last time I used a program that requires JAVA RUNTIME,I actually use a lot of Java based programs here. UMLet, jEdit, Eclipse IDE, trolCommander etc. Installing the JRE (actually the JDK - just in case) is one of the first things I do after a new OS install.
QuoteI just hate this never-ending C++/DotNet-PackageInstallBullshit.DotNet is totally pointless for me. It’s a bad ripoff of Java, since SUN sued Microsoft all that years ago.
Am i missing something, or should i make a bug report for this?This debugger issue seems different from the issue in bug tracker. I think it should be reported.
My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.
This debugger issue seems different from the issue in bug tracker. I think it should be reported.Ok, submitted - http://bugs.freepascal.org/view.php?id=31577
Java fixed only in 1.5 and after.To be fair, Java 1.5 is a very long time ago. Yes there was a slowdown of Java development for a while (SUN exiting, Oracle finding its feet), but nowadays Java language progress is going very strong.
…but for small and medium biz, I think the .NET eco system is actually betterAnd with that decision you can’t target Linux, FreeBSD or OSX. So you are cutting out a huge chunk of potential business.
Java is terrible!Then we agree to disagree. ;) The more I use Java, the more I like it. As for syntax, I think Object Pascal is way more verbose. In java you don’t have to duplicate class method definitions (like in Object Pascal in the Interface section and the Implemenation seciton). Object Pascal is simply C/C++’s .c and .h rolled into one. Java simply said - you don’t need to duplicate method definitions.
The syntax is verbose, the libraries huge, ..
I am a Linux guy, and I would actually reach for .NET before reaching for Java.Who actually writes Mono applications? I’ve never seen any job adverts for that either. As for a Mono application, I think in all my years I’ve only seen and used one Photo Manager application under Linux - many many years ago. Also you can’t target OSX with Mono or .NET, but you can with Java.
Personally, I really prefer the syntax of C++ over the syntax ofThat's the problem... WHICH C++ syntax.... There isn't any.... Apart from curly brackets it is pretty much free for all.
Java is still really slow and hungry for resources.Sorry, but you’ll have to be more specific than that! As far as I, and many others on the internet, believe - the “Java is slow” in this day and age is just another myth that doesn’t want to go away. If it was that slow, then why to most financial institues, and trading companies run Java backends on their servers. To them every millisecond counts.
My issue with Java for years has been memory consumption. But these days I made peace with that. What modern PC doesn’t come standard with 8GB or RAM anyways? My desktop system has 32GB RAM and my laptop has 16GB RAM.
My laptop has 4gb
i have huge issues running firefox, java ide and javac.
everyrthing freezes
Java is still really slow and hungry for resources.Sorry, but you’ll have to be more specific than that! As far as I, and many others on the internet, believe - the “Java is slow” in this day and age is just another myth that doesn’t want to go away. If it was that slow, then why to most financial institues, and trading companies run Java backends on their servers. To them every millisecond counts.
Closer to home…. Like I mentioned earlier, have a look in the Graphics section of this form. I showed a 100% software rendering raycaster implemented near identical in C, Java and Object Pascal. The code is purposely badly written, because it was based on a Java 4KB competition, so small was a priority of well written code. Anyway, the graphics output is identical on all, but the Java version runs circles around the other two. On my system Java was hitting 30+ frames per second, C was in the mid to high 20’s, and no matter how many optimazations was applied, the Object Pascal version (compiled with FPC of course) as struggling at around 4-6 frames per second.
Eclipse IDE runs really fast here. No slower than Lazarus IDE. The same goes for other Java applications I run. jEdit for example loaded and syntax highlighted a huge 20MB source file much faster than Lazarus IDE could.
I can add that you do get good and bad applications, and one can always find examples of slow (and badly written applications), be that native executables, .NET based or Java based. But do yourself a favour, and do some new internet searches about Java executable performance. Java today is NOT the Java from 1996.
Not all applications are IO bound. Just want to mention that. ;D
IDEs are process bound more than IO bound, so that's actually one instance where you can really feel the difference between Java/Python/Node.js and native languages like C/C++/Rust/Pascal.
DotNet got many things right (like mandatory JIT, generics, nullable types and autoboxing) that a sleeping Java fixed only in 1.5 and after. It's interoperability with native code is better/easier too. (pinvoke vs jni)
(disclaimer I abandoned these kinds of languages in 2005, might have changed since)
Java is still really slow and hungry for resources.
That's the main reason why I don't use any Java based IDE.
Even VSCode, based on Typescript, is faster than Netbeans, Eclipse, ..
The only thing that comes really, really close to being excellent is everything that JetBrains does. 8)
Java IDEs are resource hungry. There is no getting around it.And "native non Java based" web browsers (Chrome, Chromium, Opera and Firefox) all are *very* resource hungry too! So there you go, it's not just a Java problem.
DotNet got many things right (like mandatory JIT, generics, nullable types and autoboxing) that a sleeping Java fixed only in 1.5 and after. It's interoperability with native code is better/easier too. (pinvoke vs jni)
(disclaimer I abandoned these kinds of languages in 2005, might have changed since)
Luckily for me (Java & C# programmer) it has changed on the Java side.
I would have to wait 15 mins for Eclipse to openI just tested this on my system. I did a reboot to make sure everything was out of memory. Then started both IDE's for the first time after the reboot. Lazarus IDE started in 4 seconds. Eclipse IDE started in 5 seconds. So based on starting time I'd call them pretty even. But if you have to take into account that Eclipse has to fire up the JVM, and that Eclipse has a ton more features and code analysis, I'd say Lazarus (the "native" app) looses badly.
...his system is not, avg, commodity hardware.In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.
Java IDEs are resource hungry. There is no getting around it.And "native non Java based" web browsers (Chrome, Chromium, Opera and Firefox) all are *very* resource hungry too! So there you go, it's not just a Java problem.
Have you ever monitored Lazarus IDE resource usage after you have used it for about an hour? It hogs up an awful lot of RAM too. At least Eclipse and IntelliJ IDEA do about 20x more code analysis and other functionality etc while running - compared to Lazarus IDE. So it makes sense the former two IDE's use lots of RAM.
In my experience, RAM is dirt cheap, so get as much of it as your system can handle. If you starve your system of RAM, any application is going to perform badly - no matter what SSD hard drive or CPU you have. Maybe the reason why my Java applications (yes, even Eclipse) runs at native application speed, is because I have enough resources available in my system (especially RAM, which I know every application, OS, desktop environment loves).
But to be honest I never really monitored the Lazarus IDE resource usage.Maybe its time you start. ;) I've been using Lazarus here for just under a hour now, and it's already up to 500MB of RAM usage. It normally sits around the 850MB mark with my average size projects. I've also seen it over the 1GB RAM mark in the past (all day usage and with many files open).
Working with little RAM on my laptop forces me to try to code smartly.In that case, if you run Linux then switch to JWM window manager and code using MSEide (even for LCL based applications). Both use magnitudes less memory than a GNOME/MATE/KDE environment running Lazarus IDE.
Working with little RAM on my laptop forces me to try to code smartly.
In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.
Working with little RAM on my laptop forces me to try to code smartly.
I recommend you to upgrade your laptop's memory. I work as a computer technician, I know that memory is very affordable now. If you're not willing to spend much money, buy the used one. It's less than $10 here for 2 GB and as good as new. All programmers can code but just a few can code smartly.
ps:
No body (except Microsoft) likes Windows 10. ;)
No body (except Microsoft) likes Windows 10. ;)
But not happy, she said Win10 is confusing.Not just confusing... the games Microsoft are playing to try and get (or force) people to upgrade are ridiculous. Auto upgrading overnight, whole system logging (keyboard logging, apps used, hardware used, forced apps store usage etc) and now the latest bulls**t - restricting updates for older versions with fake "warning" messages.
ps:
Nobody (except Microsoft) likes Windows 10. ;)
QuoteI would have to wait 15 mins for Eclipse to openI just tested this on my system. I did a reboot to make sure everything was out of memory. Then started both IDE's for the first time after the reboot. Lazarus IDE started in 4 seconds. Eclipse IDE started in 5 seconds. So based on starting time I'd call them pretty even. But if you have to take into account that Eclipse has to fire up the JVM, and that Eclipse has a ton more features and code analysis, I'd say Lazarus (the "native" app) looses badly....his system is not, avg, commodity hardware.In all the companies I've worked for over the last 10 years, I can't remember seeing any developers system (laptop or desktop) with less than 8GB of RAM. So if I used 8GB of RAM 10 years ago, using 32GB now is definitely not a far stretch. Hell, even using 16GB of RAM now should be pretty good. I chose 32GB because I also run about 2-4 VM's concurrently on my system for testing purposes.
I call bullshit on on everything you said about where you worked in 10 years.. but whatever.I hear little violins playing in the background now. :'(
I also dont need 2000 VM's our servers are all Ubuntu too.As much as I would like everybody to run FreeBSD or Linux, I develop and test for multiple operating systems (as per my clients needs), and while contracting, each client gets its own VM to segregate the work.
I call bullshit on on everything you said about where you worked in 10 years.. but whatever.I hear little violins playing in the background now. :'(QuoteI also dont need 2000 VM's our servers are all Ubuntu too.As much as I would like everybody to run FreeBSD or Linux, I develop and test for multiple operating systems (as per my clients needs), and while contracting, each client gets its own VM to segregate the work.
When it comes to performance I think Lazarus and FPC will not be fully optimized until all the modern/Delphi functionality bells and whistles that Maciej and co have been asking for have been added. It is hard for small teams to optimize software when they are adding new functionality to it.
It is only when things get stabilized that they can concentrate and squeezing every last drop out.
I am looking for automatic garbage collection but I don't see it happening soon. Perhaps Maciej's ARC will help when it comes out, which will be nearer 2020 if not after.
FWIW computer developers have become cheapskates who undervalue their work and/or allow their work to be undervalued. Other professionals pay far more for their tools and they don't even whinge. Even Uber drivers invest more in the cars and they don't gripe about costs so much.
FWIW computer developers have become cheapskates who undervalue their work and/or allow their work to be undervalued.Most programmers are in entry level and/or minimum income jobs due to the market oversaturation these days, and can't just spend a $1000 on a top-of-the-line computer simply for the sake of reducing compile time from 60 to 30 sec or something.
If I set it to anything less I will be wasting my time watching the hourglass.Case in point.
Well, Delphi is as good as dead. And, to be honest: good riddance.I'm very late to this thread but I am interested why people feel Delphi is dead. I was toying with buying it, even at its exorbitant price.
Well, Delphi is as good as dead. And, to be honest: good riddance.I'm very late to this thread but I am interested why people feel Delphi is dead. I was toying with buying it, even at its exorbitant price.
The future always means future. So it doesn't matter how long the thread runs. If a goal is achieved, there's a new future feature..., etc.
Just my 2 cents:Maybe the USA is more backwards than the rest of the world thought. 10 Years ago I was based in a 3rd world country - South Africa. I worked in Science & Academics for a 30+ employees company. Developer systems were all desktops (laptops were simply not powerful enough) and RAM was a mix between 4GB and 8GB - *never* lower that 4GB. And yes, 2 monitors per PC was common too.
10 years ago 8 or even 16 GB was common for a developer in the Netherlands..
Graeme you mentioned recently that you were compiling Firefox. How long did it take?7 minutes if I remember correctly - which I believe was faster than usual. I went and made a cup of coffee while it was churning away. :) Compiling LibreOffice takes magnitudes longer (35+ minutes)! Imagine the pain in debugging that.
FWIW computer developers have become cheapskatesDefinitely. Every second I wait for a compilation is time wasted and costs somebody money.
If my constraints are 16/32 GB to write and ship this software, well I might as well close shop.As a CTO you seem to have a major lack of understanding when it comes to software development. A development machine does NOT equate to a end-user system. Developers don't have a normal workflow that end-users have. Developing with a high resource system doesn't mean your application requires those high resources too.
I personally have never seen a company have a group of developers all using multiple VMs.Clearly you have been out of the programming scene for some time. VM's are quite common place now in development environments and in QA testing.
To put this in context, my personal laptop back in 2007 was a 15.6" DELL Inspiron (weighs a ton) with a screen resolution of 1920x1200 and 4GB RAM and some 3Ghz CPU and a 128MB Radeon video card. I still have that laptop today (fully working, but not used any more). Pity laptop designs went backwards since then, now sporting shitty 1366x768 resolutions as common place. WTF! And the consumer seems happy with that?? WTFx2!
Weird. I got an inspiron from a more expensive series (the Inspirons already upgraded to Core 2) at roughly the same time, and that was not even an option. It was the first time I didn't get a Latitude, so I maxed out the inspiron 6400 a bit. But that was still conroe processors (so 2.2GHz was a lot), 2GB Ram, 1280x1024 and a 128MB GF7300. The laptop chipset could not do more than 4GB, and Dell didn't even support that configuration. (rightly so even, since when I later upgraded it anyway, instability started)
Later 2007 might have given you a 2nd generation core2 (kentsfield), but afaik the laptop processors there never reached 3.0 GHz.It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
So either you have something really weird and exotic, or you got your dates wrong.
If my constraints are 16/32 GB to write and ship this software, well I might as well close shop.As a CTO you seem to have a major lack of understanding when it comes to software development. A development machine does NOT equate to a end-user system. Developers don't have a normal workflow that end-users have. Developing with a high resource system doesn't mean your application requires those high resources too.QuoteI personally have never seen a company have a group of developers all using multiple VMs.Clearly you have been out of the programming scene for some time. VM's are quite common place now in development environments and in QA testing.
To put this in context, my personal laptop back in 2007 was a 15.6" DELL Inspiron (weighs a ton) with a screen resolution of 1920x1200 and 4GB RAM and some 3Ghz CPU and a 128MB Radeon video card. I still have that laptop today (fully working, but not used any more). Pity laptop designs went backwards since then, now sporting shitty 1366x768 resolutions as common place. WTF! And the consumer seems happy with that?? WTFx2!
Weird. I got an inspiron from a more expensive series (the Inspirons already upgraded to Core 2) at roughly the same time, and that was not even an option. It was the first time I didn't get a Latitude, so I maxed out the inspiron 6400 a bit. But that was still conroe processors (so 2.2GHz was a lot), 2GB Ram, 1280x1024 and a 128MB GF7300. The laptop chipset could not do more than 4GB, and Dell didn't even support that configuration. (rightly so even, since when I later upgraded it anyway, instability started)
Later 2007 might have given you a 2nd generation core2 (kentsfield), but afaik the laptop processors there never reached 3.0 GHz. I think 2.66 was about tops. (https://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors#.22Merom.22.2C_.22Merom-2M.22_.28standard-voltage.2C_65_nm.29)
So either you have something really weird and exotic, or you got your dates wrong.
It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100 (http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100)
[…]VM's are quite common place now in development environments […]Containers. Containers are cool now. ;)
It was exotic for the era, as the commenter thought that rez was high at the time. [… deviantart link …]Yeah, it still is. I like my laptops small and mobile.
It was a DELL Inspiron 9100. This link shows the specs... 3.2Ghz.
http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100 (http://uk.pcmag.com/dell-inspiron-9100/28273/review/dell-inspiron-9100)
Oh dear. P4. Most people rather forget that period :-)
Maybe now it is considered "exotic", simply because all laptop manufacturers started producing shit laptops after 2004. Things are supposed to improve, not take a hell of a step backwards!It was exotic for the era, as the commenter thought that rez was high at the time. [… deviantart link …]Yeah, it still is. I like my laptops small and mobile.
I can't imagine how hot that thing must have gotten after running for a few hours.Running hot was never a problem. If I remember correct, it had something like 4 fans and a massive heat sink. What was an issue was the weight and battery live - 2 hours 30 minutes max on a fully charged battery. Luckily I always worked at a desk with a power point. Also, you could never work on the laptop on your lap - your legs would go numb in a few minutes from the weight. :)
Also, why would you even bother upgrading the RAM on a machine that still has a terrible, terrible GPU like a Mobile Radeon 9700 (with a whopping 128 MB of VRAM!)I don't fully understand. I played loads of times at game LAN parties (Counter Strike, Half-Life, Quake etc). It was awesome. Everybody lugging around pimped out desktop PCs and massive 17 or 19 inch CRT monitors that took 30+ minutes to set up. And here I come with my awesome laptop in a single backpack. It turned lots of heads at the time. Oh, and the sound was fantastic too - even included a sub woofer built into the battery housing.
Oh dear. P4. Most people rather forget that period :-):) At least I didn't get the Ghz rating or screen resolution wrong. DELL also marketed in as a "desktop replacement laptop" - so its weight and short battery life was not too surprising.
For example the Lazarus project itself has rather many source files but I can work with them smoothly using the IDE.Sorry for the off-topic, but i ended up doing just that, and am curious what your workflow looks like?
For example the Lazarus project itself has rather many source files but I can work with them smoothly using the IDE.Sorry for the off-topic, but i ended up doing just that, and am curious what your workflow looks like?
Specifically, how do you quickly get to/switch to a particular arbitrary file in a project?
Specifically, how do you quickly get to/switch to a particular arbitrary file in a project?Sorry didn't notice this earlier.
Can free pascal porting to haxe ?
Maybe its
https://haxe.org/ (https://haxe.org/)
the first thing google gave me
About Haxe I think we can use library from other language , if we compile haxe to Java it mean we can use SWT, AWT, Java Bean etc, haxe to php we can use library from zend
so if we compile object pascal to haxe , we can use library from other language that support haxe
it will be pascal every where
haxe compile to native language , not like .net or jvm
And the jvm target is pretty good. And can be used to feed into a native code compiler for Java bytecode...haxe compile to native language , not like .net or jvm
FPC also, and has heaps of targets. Including Java. Maybe Haxe should compiler to FPC :_)
I think (as I understand) he/she wants to say is it possible to use fpc like as haxe functions:
using StringTools; class Test { static public function main() { // uses static extension StringTools from the Haxe Standard Library var v = "adc".replace("d", "b"); trace(v); } }
For example:
function str_change:string; var str : 'adc'.replace('d','b'); // or str : String('adc'.replace('d','b')); begin result := str; end;
For example:So, since 'adc' is a literal string and the 'd' is to be replaced by a 'b' then why not simply declare it directly?
function str_change:string; var str : 'adc'.replace('d','b'); // or str : String('adc'.replace('d','b')); begin result := str; end;
The functional/pipeline xx.yy.zz way of concatenating string is used in TStringbuilder and various other string libraries. It is not a language feature, but a library feature.Personally I don't like this style too.
Personally I abhor the style. I blame it on Turbo Vision traumas, which employed this style and was IMHO pretty much unreadable.
So can all the other Statements prior mentioned(except for the TStrings-Variant). As long as every Parameter involved are Constants and (the Function only depend on these Parameters, (and have no Hidden Side-effects but even if they have the Coder has to know what he's doing then using these Functions ))
Complicated, just write (3.0.2+) :Only for demonstration purposes, with an attempt to preserve the original construction.
[/code]
I mean Like C# below
CS2HX converts your C# 4.0 code into haXe code. haXe is a multi-target language, so the resulting haXe code can be converted to many other languages.
This means CS2HX can be a:
- C# to ActionScript converter
- C# to JavaScript converter
- C# to Java converter
- C# to PHP converter
- C# to C++ converter
Is there something like this for variable values?
TPoint = record x, y : Single; color : TColor; end;
Pas2haxe may sound good, but if I can choose please put more efforts on pas2android.Huh? We have pas2Android: FPC compiles to Android-arm (and Android-Intel? never tried that).
I Really like that one My Include-File already look's like
function Test2: string; var X: TStringArray; begin X := ''.Join(#0, ['Hello World', '2. String', 'Last String']).Split(#0); Result := X[High(X)]; end;
Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator thenFunny that your code fragment ended up the same 8-)
Or the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator thenFunny that your code fragment ended up the same 8-)
Anyway, since we now have implicit array constructors, going through a vararray scenario is not necessary in trunk. The code is also way more efficient.
But, trunk only!
Sorry, I meant conversion operator of cause. from array to TMyPointOr the second Code: you only have to write a vararray to TmyPoint-conversion and overload the assignment operator then
And array only. Though maybe you can work around it with some conversion operator. (e.g. from array of two singles to tpoint etc)
I also had resource in mind, but in this special case it had to be a hard-coded Array of Strings coming from an include-file.Whenever i change the Textfile I had to Change the number of the Array too, and I Sooooooooo didn't liked that !!!!!
The problem is the whole "copy and paste in source" idea driven too far, a different solution would be to use resources.
I had the same problem with shader source code (not being recompiled after run), changed to resources and am very happy with it.
I find it strange that there seems to be a widespread perception among many programmers that Pascal is a "dead" language. A typical comment is "What!, people still use Pascal?"Me too...
Pascal was great and is still great... :P
Sorry but you didn't bother to understand mine, the only thing that is not supported currently is to the variable names, otherwise here is a short demonstration how to get exactly the same behavior that you demonstrated today no need for a new compiler.What's wrong with?
f:=open("file.txt")
Sorry, but you didn't bother to understand my point. It wasn't only about some techniques of opening a file.
I tend to think the task would require writing another compiler without backward compatibility.
For example, an interface that can declare only the name of a procedural type, without actual types:
IContextManager = Interface deferred __enter__: FuncOrProcType; procedure __exit__; procedure __rescue__(ex: Exception); end;
^^Here, the type of __enter__ would be determined by a compiler at an implementation site, in a class. Only the name is enforced by the interface, this opens an ability to create "object protocols".
__enter__ can be implemented as a function or procedure, with any arguments and return types.
Such interface leads to rich semantics that use those required methods in a compiler:
Using TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2 do begin // here needed environment(context) is ensured by these "context managers" above name1.someMethod; name2.interestingMethod; end;
A compiler would insert calls to __enter__ methods for each object in "TheCustomer, SomeOtherObject to name1, OtherHelperContext to name2", where name1 and name2 would require that __enter__ is implemented as a function rather than a procedure.
On exit for a using statement compiler would insert calls to __exit__ methods.
More organized memory management.QuoteSo, that construction somehow partly replaces RAII of C++, gives some "design by contract" abilities.
Also it can be used to program transactions with rollbacks.
Or using draw procedures in some graphic contexts, or action procedures in a game.
OK. I don't see it then. Keep in mind that the main force that keeps pascal alive this days is compatibility if I'm to forgo compatibility and rewrite my libraries I'll target a more popular toolchain like c++ I have no reason to stay cornered.you have your init right there and when it fells off scope you have the destructor called automatically and it is as clean as your example
Keep in mind that I have not worked with object for a long long time so my facts might be upside down but the idea is there and I'm pretty sure can be made to work.
I do like the variable ability. In any case I'm all up for a new compiler but I'm warning you I'm not giving up my compatibility for any reason.
The programmer is responsible for calling the constructor and the destructor explicitly when using objects.
But it does not relate to what I meant. I took simple semantics in Python as an example and demonstrated how it could possibly be implemented in Object Pascal or some static typed lang.
I tend to think the task would require writing another compiler without backward compatibility.Then it will not be Pascal but another language (i.e. Modula, Oberon...). ::)
What's wrong withDouble quotes... :D?
f:=open("file.txt")
OK. I don't see it then. Keep in mind that the main force that keeps pascal alive this days is compatibility if I'm to forgo compatibility and rewrite my libraries I'll target a more popular toolchain like c++ I have no reason to stay cornered.
I tend to think the task would require writing another compiler without backward compatibility.Then it will not be Pascal but another language (i.e. Modula, Oberon...). ::)
Actually the big advantage of FPC (and also Delphi) is its high backward compatibility. You can compile programs designed for very old compilers (such as Turbo Pascal 1.0 or Delphi 1) with very little changes.
Double quotes... :Dof course... :-[
what happened to the danish language? O:-)Dansk bacon er supior til Britisk bacon.
Those are not Delphi deficiencies but half-baked parser issues on the emacs side....
Delphi has parser issues, but that's not one of them.
(Try to parse Delphi 7 's system.pas or windows.pas in FPC to find some real parser issues... 8-) )
It seams to me that such a language may replace C in open source.I wish. Anyway, it made me smile today. Thank you! :D
You are ignorant.
In Delphi "there is no difference between a function result and a variable, however there is in FPC":
http://wiki.freepascal.org/Code_Conversion_Guide#When_calling_a_procedure_variable_use_this_syntax:_theprocname.28.29
It's not a "half-baked parser issues on the Emacs side" because I didn't even start to write a parser(Semantic built-in lib in Emacs). Only a quick automatic fontification so far.
I don't know yet what pushed Delphi programmers to make the language more context dependent by omitting parenthesis for function calls without arguments. It seams like a C++ way.
You are ignorantnowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions :D
In this case ... I'd stick to the gin-tonic 8-)QuoteYou are ignorantnowi will get some.gin/tonic and wait for thaddy's reaponse and i will enjoy your slow convultions :D
Parenthesis don't make a function call a function call. Pascal is a typed language, the fact that identifier is a function makes it a function call.
That's why in Delphi you have to do @SomeFuncName to get a pointer.
When you think about a function name, it can't be anything else than a POINTER to its code.
But if you want to treat a function's name as a pointer, you have to distinguish between a name as a pointer and a function invocation.
So parenthesis for invocation must be mandatory. In this case you wouldn't need to use @ on a function's name.
That's why in Delphi you have to do @SomeFuncName to get a pointer.Your code compiles fine without the @.
That's why in Delphi you have to do @SomeFuncName to get a pointer.Your code compiles fine without the @.
No, compiler calls the function "Hello" and passes to "Take" a string returned by "Hello".
Take(Hello);
Error: Incompatible type for arg no. 1: Got "AnsiString", expected "<procedure variable type of function:AnsiString;Register>"
I've worked a little on implementing syntax highlighting for an FPC mode in Emacs.
It turns out that Delphi's idiosyncrasies spoiled the language in some parts.
For example, calling a proc/func without parenthesis: http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg (http://s5.postimg.org/oszmu72vb/fpc_mode_emacs.jpg)
OBJFPC style guidelines fix that, but are not enforced.
It seams to me that such a language may replace C in open source.
type TFuncNoArgsString = function(): String; // is it a pointer type? function Hello: String; begin Result := 'Hello There'; end; procedure Take(f: TFuncNoArgsString); begin WriteLn( f() ); end;
Alex, FPC-mode in Emacs? This is really a good one. Have you already upload the FPC-mode package to the melpa repo? I would really like to try it :).
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.
If we want Lazarus to become the major platform, we need our own multi-platform, OpenGL GUI.Free Pascal has at least two owner drawn cross platform toolkits since more than 10 years: fpGUI and MSEgui. For MSEgui there is also MSEide, a handy and very productive design environment.
so for example unity is only cross platform on desktops and uses another tools on android and ios?
Unity - Game Engine (https://unity3d.com/unity/features/multiplatform)Unity: user interface: http://unity.ubuntu.com/ A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
Unity: user interface: https://en.wikipedia.org/wiki/Unity_(user_interface) A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.As I was the one talking about Unity, I wanted to clarify which one I was talking about.
Which was unknown to me (which also means nobody knows it - let alone uses it - on a large scale). Unity as a widget set is rather well known. Unity as game engine is not. Change the name...Unity: user interface: https://en.wikipedia.org/wiki/Unity_(user_interface) A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.As I was the one talking about Unity, I wanted to clarify which one I was talking about.
Change the name...As you wish.
I will check it out, now. What the new name? 8-)Change the name...As you wish.
Unity: user interface: http://unity.ubuntu.com/ A.K.A. widget set.. Mainly used on UBUNTU. Don't mix the two on Ubuntu.
<Grumpy!! >:D> O:-)
Which was unknown to me (which also means nobody knows it - let alone uses it - on a large scale). Unity as a widget set is rather well known. Unity as game engine is not. Change the name...