Joseph MItzen

2 hours ago, MDagg said:

Note that 0/0 is an indeterminate form whereas 1/0 is undefined. This is the reason why the errors are different. The Intel FPU does recognize indeterminate forms.

Division by zero is division by zero, whether it's 0 / 0 or 1 / 0.

On 3/31/2021 at 11:26 AM, Mike Torrettinni said:

OK, that makes sense. I use 10.2.3 so new LSP can't help here. You never used any RegEx on your code?

I never use any RegEx in my code.

20 hours ago, pyscripter said:

Regarding numpy on Linux if you use the default python 3 installation it would suffice to install numpy via pip:

pip3 install numpy

If you're using the version of Python bundled with your Linux distro, you should either install NumPy from the Linux distro's package manager, use the "--user" option to install the package in the user's home directory (making sure the path is adjusted accordingly) or install into a virtual environment. Otherwise you could have problems with the distro package manager and pip conflicting. The distro package manager won't know pip installed NumPy to the system directory and could end up overwriting it in the future during an install or update.

6 hours ago, Juan C.Cilleruelo said:

Does anyone know anything about this? 

It was like a one step forward, one step back situation: I believe they removed FireDAC from Professional at the same time they added Mobile support to it.

3 hours ago, Darian Miller said:

I purchased pgDAC Pro last year for $500, which is the current list price.  I can renew the annual subscription today for $250.

 

Honest question - you pay $500 and then $250 a year to use an open source database, with none of that money going back to the database project itself?

On 9/12/2020 at 6:23 AM, Hans J. Ellingsgaard said:

A count(*) query, on the other hand,  has a very limited impact on the server. 

That depends on the database and the version. For instance, in PostgreSQL < 9.2, a count(*) query would have to perform a sequential scan through the database:

Quote

PostgreSQL uses multiversion concurrency control (MVCC) to ensure consistency between simultaneous transactions. This means each transaction may see different rows – and different numbers of rows – in a table. There is no single universal row count that the database could cache, so it must scan through all rows counting how many are visible. Performance for an exact count grows linearly with table size.

MS SQL Server, and now PostgreSQL, can  often do index-only scans in situations like this, for much quicker results.

1 minute ago, FPiette said:

There are now "managed records" which are not classes.

See the documentation: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Custom_Managed_Records

 

They're modern classes in essentially every way except inheritance. I imagine they did this to get around the memory management issues with the standard classes. Heck, even Niklaus Wirth in the past has suggested that objects are just Pascal records with methods. 🙂

Quote

Nevertheless, the careful observer may wonder, where the core of the new paradigm
would hide, what was the essential difference to the traditional view of programming.
After all, the old cornerstones of procedural programming reappear, albeit embedded in a
new terminology: Objects are records, classes are types, methods are procedures, and
sending a method is equivalent to calling a procedure. True, records now consist of data
fields and, in addition, methods; and true, the feature called inheritance allows the
construction of heterogeneous data structures, useful also without object-orientation. Was
this change of terminology expressing an essential paradigm shift, or was it a vehicle for
gaining attention, a “sales trick”?

On 9/4/2020 at 2:49 AM, Sherlock said:

To distinguish between add-ons and components is like distinguishing between records and classes - a good thing to ease discussions with your peers.

But what happens now that Embarcadero has been turning records into classes?

On 9/2/2020 at 11:57 AM, Darian Miller said:

TMultiReadExclusiveWriteSynchronizer

When did they hire a Java developer to name things?

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.

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).

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.

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.

Quote

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.

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

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...

Quote

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.

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.

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.

16 minutes ago, David Heffernan said:

What are you on about

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

Quote

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?

Quote

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...

Quote

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....

Quote

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.

Quote

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!)....

Quote

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.

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.

Quote

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):

Quote

 

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? 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,

Quote

 

 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.

 

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.

14 hours ago, Anders Melander said:

The point is that it's better to forget about the thread, report a timeout and continue as if the thread had been forcefully terminated. 

Is now a good time to bring up that threads are evil? 😈

On 11/13/2019 at 12:44 PM, Remy Lebeau said:

ERROR_SUCCESS

OK, that is the worst name for a return value I've ever encountered!

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:
 

Quote

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":

Quote

"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.

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.

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:

Quote

 

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.