A few days ago, first public Beta of pas2js has been released.
See the demo (code).
Happy holidays! :-)
Wednesday, December 20, 2017
Sunday, December 10, 2017
fpcupdeluxe
If you use Free Pascal and/or Lazarus and update them often to follow the development in trunk, or if you just need to use multiple versions side by side, have a look at fpcupdeluxe (GitHub).
It's a GUI front-end which lets you easily select a release and build it, including cross-compilers, with a click of a button. The result is installed into its own directory where it doesn't interfere with any other installations of Free Pascal and Lazarus.
If you haven't yet, check out the latest releases of both Free Pascal (3.0.4) and Lazarus (1.8) published recently.
Update: It seems the latest fpcupdeluxe (1.6.0k) now builds trunk without any problems, no tweaks necessary, so you can ignore the rest of this post.
As a side note, updating trunk today failed for me when it was trying to build the intermediate ("bootstrap") compiler. I haven't thoroughly investigated it but I think it's due to the fact that fpc 3.0.4 is now the required compiler to build trunk and I have found a quick fix which works for me now and comprises the following two steps:
1. Create a patch file with the following content in $(fpcupdeluxe)/patchfpc directory:
and activate it in the fpcupdeluxe's settings (see screenshot below). This should "force" the bootstrap compiler 3.0.4 to be used instead of 3.0.2 as before.
2. Click "Trunk" and let fpcupdeluxe clone the 3.0.4 release into its fpcbootstrap subdirectory. This would still fail for me as for some reason the generated bootstrap compiler was still 3.0.2. Just replace the binary (ppcx64) with the 3.0.4 binary (you can build one yourself from source or copy it from the official release).
On the next click of the "Trunk" button, you should get a successful build of the current trunk fpc (3.1.1) and Lazarus (1.9). Updating the cross-compilers then worked for me again as well. I usually use x86_64-linux and cross-compile to arm-linux, i386-linux, x86_64-win64, i386-win32, x86_64-darwin and i386-darwin.
It's a GUI front-end which lets you easily select a release and build it, including cross-compilers, with a click of a button. The result is installed into its own directory where it doesn't interfere with any other installations of Free Pascal and Lazarus.
If you haven't yet, check out the latest releases of both Free Pascal (3.0.4) and Lazarus (1.8) published recently.
Update: It seems the latest fpcupdeluxe (1.6.0k) now builds trunk without any problems, no tweaks necessary, so you can ignore the rest of this post.
1. Create a patch file with the following content in $(fpcupdeluxe)/patchfpc directory:
Index: Makefile.fpc
===================================================================
--- Makefile.fpc (revision 37707)
+++ Makefile.fpc (working copy)
@@ -21,7 +21,7 @@
[prerules]
REQUIREDVERSION=3.0.4
-REQUIREDVERSION2=3.0.2
+REQUIREDVERSION2=3.0.4
# make versions < 3.77 (OS2 version) are buggy
and activate it in the fpcupdeluxe's settings (see screenshot below). This should "force" the bootstrap compiler 3.0.4 to be used instead of 3.0.2 as before.
2. Click "Trunk" and let fpcupdeluxe clone the 3.0.4 release into its fpcbootstrap subdirectory. This would still fail for me as for some reason the generated bootstrap compiler was still 3.0.2. Just replace the binary (ppcx64) with the 3.0.4 binary (you can build one yourself from source or copy it from the official release).
On the next click of the "Trunk" button, you should get a successful build of the current trunk fpc (3.1.1) and Lazarus (1.9). Updating the cross-compilers then worked for me again as well. I usually use x86_64-linux and cross-compile to arm-linux, i386-linux, x86_64-win64, i386-win32, x86_64-darwin and i386-darwin.
Friday, May 19, 2017
Big Ball of Mud
Recently I've spoken to people at quite a few companies where Delphi is used to develop their software. There's a pattern which is very hard to miss or ignore: Every one of them so far wants to get away from Delphi. They are all very dependent on it and still need it to continue running their businesses but they are unhappy about it and their long-term plan is unequivocally to move away from it. Often they would like to migrate to the Web, using the browser as the user interface and things like Microsoft ASP.NET and Azure as the back end.
An often-mentioned reason why they'd like to migrate away from Delphi is that their systems evolved into what can be described as the "Big Ball of Mud".
But wait. How's that related to a particular language or development environment? This (anti-)pattern applies to software design in general, right? Regardless of the language or the IDE?
Think about how fast and easy (compared with other tools) you can bang out a quick prototype in Delphi. Think about how often those prototypes end up in production after all, never rewritten or revisited again. In the article above, they are referred to as the "throw-away code"; code which was supposed to be thrown away but for some reason that never happened.
Which is what, as the throw-away code accumulates, eventually leads to the Big Ball of Mud pattern.
Does perhaps Delphi, by making it so easy to produce throw-away code, support a tendency leading to the creation of "Big Ball of Mud" systems?
What do you think?
An often-mentioned reason why they'd like to migrate away from Delphi is that their systems evolved into what can be described as the "Big Ball of Mud".
But wait. How's that related to a particular language or development environment? This (anti-)pattern applies to software design in general, right? Regardless of the language or the IDE?
Think about how fast and easy (compared with other tools) you can bang out a quick prototype in Delphi. Think about how often those prototypes end up in production after all, never rewritten or revisited again. In the article above, they are referred to as the "throw-away code"; code which was supposed to be thrown away but for some reason that never happened.
Which is what, as the throw-away code accumulates, eventually leads to the Big Ball of Mud pattern.
Does perhaps Delphi, by making it so easy to produce throw-away code, support a tendency leading to the creation of "Big Ball of Mud" systems?
What do you think?
Subscribe to:
Posts (Atom)