Jump to content

Joseph MItzen

Members
  • Content Count

    81
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Joseph MItzen


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


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


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

    :classic_biggrin::classic_biggrin::classic_biggrin:


  4. 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? :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,

     

    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.

     

     


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


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

    • Like 1

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


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


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

     

    https://stackoverflow.com/questions/9119999/getting-output-from-a-shell-dos-app-into-a-delphi-app

     

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


  10. 34 minutes ago, Anders Melander said:

    Additionally almost all other formats can convert to and from TBitmap so there's no reason why all the other formats should duplicate the functionality in TBitmap/TCanvas/GDI.

    Why not have just one image type that can read/write multiple formats? Or at least have TJPEGImage, etc. descend from TBitmap rather than TGraphic?


  11. 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;
    CREATE FUNCTION
    
    jmadden=> select pymax(1, 2);
    
     pymax
    -------
       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.


  12. Quote

    A TImage object (an object of a TImage class) can be used to display an image file like a JPEG or PNG file. However with the TImage object it is NOT possible to edit the image, draw graphics and change pixels. To work with the graphics and pixels of the image it must be moved to a TBitmap object.

    Do you know what the reason might be for that design decision?


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


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

     


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


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


  17. 14 hours ago, John Kouraklis said:

    I remember that as well..a bit sad in my view.

     

    So, there is Embarcadero and then there is Delphi's Product Manager. I wonder how this works...

     

    Feels like the product manager is a freelance and outsourced position:classic_unsure:

    I had someone from inside Embarcadero tell me once about the layers of management. When I mentioned this, Marco told me that my understanding of the hierarchy was wrong and proceeded to try to explain it to me. Rather than convincing me that it was simpler, I felt like I needed flowchart paper to follow his explanation. 🙂 From what I recall there was a manager to manage the coders as well as the product manager (which he mentioned entailed a bit of marketing in the job description) and then when AppMethod was cancelled Sara DuPont because a sort of "co-manager", etc. Before Idera at least there were various Vice-Presidents in charge of software, etc. In neither version did I get an idea that there was one clear person in charge of guiding Delphi. Maybe things are different now with Idera and Atanas Popov.


  18. 12 hours ago, Dalija Prasnikar said:

    Release dates are unknown to the public.

    They're unknown internally too. I'll never forget the time Marco scheduled a preview webinar for an upcoming release and Embarcadero went and released it two or three days before the preview was scheduled! Marco joked it was now a "postview webinar", but it struck  me as strange that not even the project manager had any idea when the product would be released.

    • Haha 1
    • Confused 3

  19. On 8/28/2019 at 9:47 AM, Stefan Glienke said:

    Even though I don't see them pop up when browsing the forum itself (kudos to the mods being quick enough or having automated it) I see stuff like this on beginend.net almost every day recently:

     

    image.png.39ac7d550306d22d885717cff566b9ea.png

     

    Hey, you deal with the Delphi IDE long enough, you need a fistful of cheap unmarked pills of dubious provenance to get through the day! :classic_biggrin:

    • Haha 4

  20. On 9/30/2019 at 4:39 AM, Stefan Glienke said:

    Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect.

     

    The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

    You're reminding me of something written by Dennis Ritchie about operator precedence in C. At one point early on they wanted to change it, but Ritchie said "We can't; there's almost a million lines of C code out there!" :classic_biggrin: He wrote that in retrospect they should have made the change. Contrast this with the creator of Python, Guido Van Rossum, when talking about breaking compatibility to change how Unicode strings were handled. I don't have the exact quote, but it went something like  "All the lines of Python ever written pale in comparison to the number of lines of Python yet to be written".

     

    Quote

    The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

    This gets into the touchy subject of how many people are writing new code in Delphi versus how many are maintaining legacy code. Even with C++Builder they brought the 32bit compiler up to C++17 first, saying you'd be surprised how much 32bit code is being maintained by C++Builder users.

×