Jump to content

Joseph MItzen

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Joseph MItzen

  1. 7 hours ago, Lars Fosdal said:

    That said - $299 for 8 licenses with source code is not over the top for what appears to be a capable piece of code.

    Still, it would have been nice to see a $149..1xx single user license including source.


    Honestly, if I ran the idea of paying $149 to be able to display an SVG file to any programming forum outside of this one, I guarantee you the reaction would not be positive.


    I've always said, "Make money with Delphi, not from Delphi". A survey of developers found that the number one reason they gave for choosing a language for a project was the number of libraries available for it (and preferably open source ones). When the Delphi community tries to charge for things that are free everywhere else, it just makes it that much less likely that someone will choose Delphi in the future. The barrier to entry is raised that much higher.


  2. 9 hours ago, PeterPanettone said:

    While the opensource idea is a good concept for social collaboration,  the misconception that EVERYTHING must be free is a pathological social delusion.

    And yet, that's the way the software world has headed towards. Open source is more than just good for "social collaboration", it's good for producing secure, reliable code at a potential pace that far outstrips what any commercial vendor can produce (e.g. the Linux kernel has more contributors than even Microsoft can devote to its own kernel).

  3. 23 hours ago, David Heffernan said:

    Isn't this just the age old issue that Delphi's RTL unmasks floating point hardware exceptions, but most other tools (including the MS tools) mask them.

    Damn, even floating points have to wear masks right now. :classic_sad:

    • Haha 3

  4. On 3/10/2020 at 6:35 PM, timfrost said:

    Exactly.  Stripping out every UTF-8 BOM is not viable unless all users of the files will only ever use a single national language and its encoding.

    UTF8 doesn't need a BOM regardless of encoding.


    Byte order has no meaning in UTF-8, so its only use in UTF-8 is to signal at the start that the text stream is encoded in UTF-8, or that it was converted to UTF-8 from a stream that contained an optional BOM.


  5. On 3/10/2020 at 3:45 PM, Lars Fosdal said:

    I try to ensure that all my text files have a BOM and are encoded as UTF-8.


    BOM is both not required by the UTF8 standard and discouraged. Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature

  6. On 3/10/2020 at 12:03 PM, dummzeuch said:

    If you only ever handle files created with Windows programs, that's probably fine. Unfortunately I also get files from other systems, where the BOM might be useful.

    I thought it was only Windows programs that ever put the BOM in in the first place. At least in the Linux development community they tend to consider it a Windows thing.
    Wikipedia says...


    The Unicode Standard permits the BOM in UTF-8 but does not require or recommend its use. Byte order has no meaning in UTF-8.... Microsoft compilers and interpreters, and many pieces of software on Microsoft Windows such as Notepad treat the BOM as a required magic number rather than use heuristics. These tools add a BOM when saving text as UTF-8, and cannot interpret UTF-8 unless the BOM is present or the file contains only ASCII. Google Docs also adds a BOM when converting a document to a plain text file for download.


    So basically no one should be expecting a BOM in a UTF-8 file (and it's not required) so I don't believe you'd run into problems omitting it.

  7. 5 hours ago, Andy Vines said:

    For information for others considering the Community Edition I have tried to get a new licence for the Community Edition and have failed, it appears you have to jump through hoops after the first year as expired, even though the emails said I should contact support, they just referred me to the faq's and CE page.

    This is what they're saying on Reddit too... the software says contact support, and the support team just sends an email back saying to refer to the FAQ which states that support doesn't cover Community Edition. 😞 It's a crazy Catch-22.

  8. On 11/21/2019 at 7:51 AM, Uwe Raabe said:

    So, when did you get that serial number and when did install the CE with that serial number for the first time?


    IIRC, all CE serial numbers are only valid for one year. 

    So from what I've been hearing, when the year is up the user is going to have to uninstall the old CE, get a new license (if they're still offering it) and then install the new CE and all of their components over again. At least that's what the understanding is without any official comment to the contrary.

  9. 16 minutes ago, David Heffernan said:

    What are you on about

    Life, the universe, everything... and threads.


    It is perfectly possible to write code that is correct, and behaves in a deterministic fashion with threads.

    Lots of things are theoretically possible but incredibly difficult in practice. And should one want to do things the hardest and most error-prone way possible?



    For sure the order of scheduling and execution is not deterministic, but that doesn't mean that you can't write programs whose behaviour is deterministic.

    Professor Lee goes on with a mathematical/logical proof for two pages disagreeing with you on this. 🙂 He goes on about a theory of equivalence for sequential programs, and then...



    Consider now whether we have a useful theory of equivalence. That is, given a pair of multithreaded programs(p1, p2)and another pair(p′1, p′2), when are these two pairs equivalent? A reasonable extension of the basic theory defines them to be equivalent if all interleavings halt for the same initial state and yield the same final state. The enormous number of possible interleavings makes it extremely difficult to reason about such equivalence except in trivial cases .... Even worse, given two programs p and p′ that are equivalent when executed according to (1), if they are executed in a multithreaded environment, we can no longer conclude that they are equivalent. In fact, we have to know about all other threads that might execute (something that may not itself be well defined), and we would have to analyze all possible interleavings. We conclude that with threads, there is no useful theory of equivalence.Still worse, implementing a multithreaded model of computation is extremely difficult. Witness,for example, the deep subtleties with the Java memory model ... where even astonishingly trivial programs produce considerable debate about their possible behaviors.The core abstraction of computation given by (1), on which all widely-used programming languages are built, emphasizes deterministic composition of deterministic components. The actions are deterministic and their sequential composition is deterministic. Sequential execution is, semantically, function composition, a neat, simple model where deterministic components compose into deterministic results.Threads, on the other hand, are wildly nondeterministic. The job of the programmer is to prune away that nondeterminism. We have, of course, developed tools to assist in the pruning. Semaphores, monitors, and more modern overlays on threads (discussed in the following section) offer the programmer ever more effective pruning. But pruning a wild mass of brambles rarely yields a satisfactory hedge.

    Basically, you can't know that you've written a threaded program whose behavior is deterministic except in the most trivial of cases. The case I cited in my reply to Lars mentioned a project whose purpose was to test using rigorous engineering practices to combat threads and despite code reviews, 100% code coverage, the involvement of concurrency experts, etc. it took four years to turn up a deadlock problem. And that's why threads are evil.


     Even the SQLite FAQ reads....



    6) Is SQLite threadsafe?


    Threads are evil. Avoid them.


    SQLite is threadsafe. We make this concession since many users choose to ignore the advice given in the previous paragraph.

    I believe this idea is becoming mainstream enough in computer science (if not in application development) that we're seeing the creation of the actor model, the MapReduce algorithm, etc. as ways to implement parallelism more safely.


    For those interested, I just started reading "Seven Concurrency Models In Seven Weeks: When Threads Unravel" and so far it's a great book. It covers threads and locks, functional programming, separating identity and state, actors, sequential processes, data parallelism, and the lambda architecture.



    I for one make a living doing just that

    Hee hee, I'll leave you with my favorite quote from Lee's paper then (in jest!)....



    To offer a third analogy, a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.


  10. 9 hours ago, Lars Fosdal said:

    Threads are dangerous in the same way that travel by car is dangerous.

    If you prepare well, know how to drive, follow the rules and take the appropriate precautions, then you will be in control and nothing bad happens.

    I'm not sure I can agree with your optimistic outlook. Threads are inherently nondeterministic in a way that human beings are not.



    If the next generation of programmers makes more intensive use of multithreading, then the next generation of computers will become nearly unusable.

    -Edward A. Lee, "The Problem With Threads"


    It's more like traveling on the back of a hungry crocodile. If I may quote Swizec Teller's discussion of Lee's paper because it sites a perfect example (as well as giving its own car-related analogy):




    Essentially the problem is this – the core abstraction of computation is a deterministic assembly of deterministic components, but threads are inherently nondeterministic. The car analogy Lee provides is trying to compose an internal combustion engine out of a pot of iron,  hydrocarbon and oxygen molecules randomly moving according to thermal forces.

    This is so bad in practice even using very strict and rigid engineering principles, doesn’t help. In early 2000 Lee started the Ptolemy Project, a project designing concurrent embedded systems. But this is also an experiment in battling threads with rigorous engineering discipline – they developed a code maturity rating system, design reviews, code reviews, nightly builds, the works. Reviewers included concurrency experts and there are regression tests with 100% code coverage.

    When the system started being used in 2000 no problems were observed until a deadlock on April 26th, 2004. Just the fact they know the exact date this happened tells a lot about how rigorously engineering principles are applied. Still, a very serious problem took four years to be discovered.


    That's not a comforting example, is it? :classic_sad: Concurrency tends to cause problems, but threads are a really dangerous practice because of the shared memory issues. Processes, the actor model, functional programming with immutable values - there are a lot of other solutions that are a lot less volatile. As Guido Van Rossum pointed out several years ago, threads were never even originally intended for parallel computation! Unfortunately, a lot of developers continue to equate concurrency with threads. As Mark Summerfield puts it,




     Mid-Level Concurrency: This is concurrency that does not use any explicit atomic operations but does use explicit locks. This is the level of concurrency that most languages support..... This level of concurrency support is commonly used by application programmers, since it is often all that is available.

    High-Level Concurrency: This is concurrency where there are no explicit atomic operations and no explicit locks. (Locking and atomic operations may well occur under the hood, but we don’t have to concern ourselves with them.) Some modern languages are beginning to support high-level concurrency.



  11. 10 hours ago, aehimself said:

    They introduce more problems that they solve in some implementations, true; but with correct usage they can make a sluggish UI fluent, a long running calculation finish in a fraction, or simply making the application do several calculations in parallel instead of serial.

    But processes can do all those things as well while being much less dangerous.

  12. 10 hours ago, Fr0sT.Brutal said:

    AFAIU Firebird guys prefer perf and stability over language abilities. While it's pretty hard to break a server with just SQL, it is much easier with DLL. And calling a scripting lang like Python from SQL is just a perf killer. Btw, I guess there's also security that is concerned. What if a non-privileged user executes a query with "rm -rf" of "cat /etc/passwords"? 

    Well, again, they're working towards adding other language abilities, so it's not like it's been rejected on design grounds. As for security, some of the languages available with PostgreSQL come in "trusted" and "untrusted" modes. For instance, from the PostgreSQL documentation:


    Normally, PL/Perl is installed as a "trusted" programming language named plperl. In this setup, certain Perl operations are disabled to preserve security. In general, the operations that are restricted are those that interact with the environment. This includes file handle operations, require, and use (for external modules). There is no way to access internals of the database server process or to gain OS-level access with the permissions of the server process, as a C function can do. Thus, any unprivileged database user may be permitted to use this language.


    And of course any of these other languages will need to be enabled by a system administrator. Regarding "rm -rf" or the like, the PostgreSQL database should be set up to run under its own account with very limited privileges and its own group. In PostgreSQL, only database superusers can create functions with an untrusted language.


    Now as for performance, there are two points. The first regards performing actions on a large volume of data.It can be far quicker to perform the action on the server, even via Python, than to move the entire body of data to the target machine and perform that action locally. The second is that other languages can allow the end user to easily perform actions that would be incredibly difficult via the inbuilt procedural SQL language, hence it's a performance enhancer.


    To quote from the anonymous author of "PostgreSQL Vs. MS Server":


    "Pure" declarative SQL is good at what it was designed for – relational data manipulation and querying. You quickly reach its limits if you try to use it for more involved analytical processes, such as complex interest calculations, time series analysis and general algorithm design. SQL database providers know this, so almost all SQL databases implement some kind of procedural language. This allows a database user to write imperative-style code for more complex or fiddly tasks.

    PostgreSQL's procedural language support is exceptional. It's impossible to do justice to it in a short space, but here's a sample of the goods. Any of these procedural languages can be used for writing stored procedures and functions or simply dumped into a block of code to be executed inline.

    • PL/PGSQL: this is PostgreSQL's native procedural language. It's like Oracle's PL/SQL, but more modern and feature-complete.
    • PL/V8: the V8 JavaScript engine from Google Chrome is available in PostgreSQL. This engine is stable, feature-packed and absurdly fast – often approaching the execution speed of compiled, optimised C. Combine that with PostgreSQL's native support for the JSON data type (see below) and you have ultimate power and flexibility in a single package.

      Even better, PL/V8 supports global (i.e. cross-function call) state, allowing the user to selectively cache data in RAM for fast random access. Suppose you need to use 100,000 rows of data from table A on each of 1,000,000 rows of data from table B. In traditional SQL, you either need to join these tables (resulting in a 100bn row intermediate table, which will kill any but the most immense server) or do something akin to a scalar subquery (or, worse, cursor-based nested loops), resulting in crippling I/O load if the query planner doesn't read your intentions properly. In PL/V8 you simply cache table A in memory and run a function on each of the rows of table B – in effect giving you RAM-quality access (negligible latency and random access penalty; no non-volatile I/O load) to the 100k-row table. I did this on a real piece of work recently – my PostgreSQL/PLV8 code was about 80 times faster than the MS T-SQL solution and the code was much smaller and more maintainable. Because it took about 23 seconds instead of half an hour to run, I was able to run 20 run-test-modify cycles in an hour, resulting in feature-complete, properly tested, bug-free code....

    • PL/Python: you can use full Python in PostgreSQL. Python2 or Python 3, take your pick, and yes, you get the enormous ecosystem of libraries for which Python is justifiably famous. Fancy running a SVM from scikit-learn or some arbitrary-precision arithmetic provided by gmpy2 in the middle of a SQL query? No problem!

    • PL/Perl: Perl has been falling out of fashion for some time, but its versatility earned it a reputation as the Swiss army knife of programming languages. In PostgreSQL you have full Perl as a procedural language.

    • PL/R: R is the de facto standard statistical programming environment in academia and data science, and with good reason - it is free, robust, fully-featured and backed by an enormous library of high-quality plugins and add-ons. PostgreSQL lets you use R as a procedural language.


    Python and R have become the dominant languages in data analysis, and machine learning which is why MS SQL Server has added support for them (along with .NET languages). Being able to use a machine learning routine or do logistic regression right on the server inlined with SQL is a really powerful feature.

    • Like 1

  13. 2 hours ago, Anders Melander said:

    What about layers, filters, transformations, scanner and cloud support. Yes, let's add SOAP, REST, FTP and Kermit support in case need to transfer these images between systems. 

    Why do we need different classes at all? We could just create a single class that does EVERYTHING.

    You really don't want to have an honest discussion, do you? You seemed to come into it with some sort of chip on your shoulder.

  14. 12 minutes ago, Anders Melander said:

    Monolithic design... Pick up any book on software design and it will explain why that is not a good idea. I'm not going to do it here.


    Unnecessary coupling. The above book will explain that too, but ask instead: Why should it?


    Having lots of methods that all do the same thing with a slight twist isn't a good idea. In normal development, you make that one function and supply a parameter. For instance, you don't want one function that returns squares of a number, another for cubes, etc. You have one power function that takes a parameter that raises a number to the specified power.


    I'm also not clear about the coupling. Classic OOP would, for instance, create a deck of cards class and then inherit from that to produce a blackjack game and a poker class would similarly inherit from the deck class. In the VCL, TJpegImage, TPNGImage, etc. are all inheriting from the TGraphic base class. If they all inherited from the TImage class instead you wouldn't need to do any converting to load and alter an image.


    In fact, this is how many popular image libraries across languages work. ImageMagick, one of the most popular open source image editing libraries, has a ReadImage method that takes a file name and returns an ImageMagick Image object. One function to load any image type, one object type returned to work with.


    Pillow is the most popular library in Python. One image type, "image".  Further:




    The Python Imaging Library supports a wide variety of image file formats. To read files from disk, use the open() function in the Image module. You don’t have to know the file format to open a file. The library automatically determines the format based on the contents of the file.

    To save a file, use the save() method of the Image class. When saving files, the name becomes important. Unless you specify the format, the library uses the filename extension to discover which file storage format to use.


    Same idea as ImageMagick. It's the VCL inheritance scheme that seems rather ad hoc and unusual.

  15. 1 hour ago, David Heffernan said:

    If I actually disagreed with you, I'd produce a counter example. I don't think I have because I don't think there is one. 


    Therefore I can't believe that I disagree. 

    OK, I think I recalled the disagreement somewhat wrong. It was about being able to call a process and get its output back into Delphi. I cited the standard code examples per




    and opined that it was rather complicated. You offered another method and argued that it wasn't really very hard at all.

  16. 36 minutes ago, Vandrovnik said:

    But these routines also have to be installed on the machine where Firebird server is running (that is how I understood "run safely inside Firebird engine space"), or am I wrong?

    If I understood the original post, what's being talked about is the ability to write procedural code in other languages directly within SQL statements being sent to the server. PostgreSQL offers this, and SQL Server offers this (for .NET languages). For example, in PostgreSQL if Python is installed on the server and the python language support is enabled in the database:

    jmadden=> CREATE FUNCTION pymax (a integer, b integer)
              RETURNS integer
              AS $$
                 if a > b:
                     return a
                 return b
              $$ LANGUAGE plpythonu;
    jmadden=> select pymax(1, 2);
    (1 row)

    Here a user was able to send a function to the server just like a regular SQL statement and then call it. Such code could be in the middle of a batch of SQL statements. Triggers can be coded in other languages, custom aggregates, etc.


    Firebird doesn't offer this level of support for inlining other languages today.

  17. On 11/7/2019 at 1:50 AM, Fr0sT.Brutal said:

    Lazarus has multiplatform TProcess with STDIN/OUT interception, waiting for finish and so on. I wonder if something like that exists for Delphi (this should really be in RTL as it's "routine stuff")

    I know David Heffernan and I have debated this before :classic_biggrin:, but IMHO no, there's nothing like Lazarus' TProcess, Qt's QProcess, or Python's run function in Delphi (David disagrees). I also am puzzled why Delphi has never had a simple way to execute commands and retrieve results.

  18. 5 minutes ago, Vandrovnik said:

    I wrote UDF for Firebird in Delphi in year 2010 and cross compiled it for linux using FreePascal, so writing functions in Delphi already works quite a long time...

    There's a difference between writing code in an external IDE, compiling it, and having a system administrator install it versus simply enabling a user to inline another language along with their SQL code.


  19. On 11/5/2019 at 2:33 AM, Jacek Laskowski said:

    Firebird 3 has very interesting possibilities. Among other things:

    •  Eventually, plug-in support for stored procedures, triggers and functions written in Java, C++, ObjectPascal, etc."


    I began looking at Firebird in 2005. I was told that support for writing functions in other languages was coming in Firebird 3.0, which was going to be coming shortly. It came 10 years later. 😭 And of course, no support for writing functions in Delphi, etc. yet. One would be much better off choosing PostgreSQL, which is also open source, has a long history of approximately yearly releases, is highly extensible (create your own data types, indexes, etc.), has a large plugin ecosystem, and allows for inlining code in many languages. Of course, there are also many enterprise-grade features such as parallel queries, significant replication support, etc. I'm not aware of FreePascal language support, but that would only be due to lack of interest; the plugin system can certainly support it. I've even seen a plugin for LOLcode. :classic_huh:

  20. On 10/26/2019 at 2:05 PM, aehimself said:

    Seriously though, my company is not paying for (or don't know about) these and it's a bit pricy for a simple person. There are people in my country who earn the price (or a fraction!) of a 1-day ticket per month.

    *spit-take* Wow, you weren't kidding! 1200 Euros for three days? That's more than my desktop computer cost.