OriginalGriff wrote:

they proudly announced the kit contained a "1 bit DA converter"

Which was entirely correct. Sigma/Delta DA (and AD) converters are indeed 1-bit converters that use crazy oversampling plus noise-shaping to produce an analog output that has the same resolution as a 16 or 24 bit "classical" converter :) . The introduction of sigma/delta converters removed a whole class of non-linearity issues with classical converters.

Ah yes - *that* proof. Totally agree. That assertion *must* have been written tounge-in-cheek :) . At least, I very much hope so :laugh:

obeobe wrote:

the conclusion that 22 degrees is the optimal angle is also not backed by any proof

Must depend on the aspect ratio of the particular monitor. When that is known it should be really simple to calculate what angle to tilt the monitor in order to have the diagonal become horizontal. Other than that, I find the concept of diagonal mode hilarious :laugh: . And yes, a complete waste of space on the other parts of the screen.

I will second that. I use pen and paper too. Note down the time when I start working for a client, then work until I start needing a break, and keep on until a full number of half-hours have passed. Then take a break. Repeat until the day has passed :-). And the final number of hours of the day go into a Wordpad document per client. The hours are then summed up at the end of each month on the invoices. Keeps it simple.

My advice is to return it. Those volatile compounds that it emits are best avoided. I had the same issue with a D-Link router a few years back. Smelled terrible. I got it replaced and the new unit had no issues. I have a bunch of Raspberry Pi-s. Some of them are odorless, others smell like hot electronics even after weeks of burn-in. So it depends on model, batch, assembly line, etc. Sometimes you just get a unit that has residual whatever on it and that residue will evaporate ever so slowly when used. May take weeks or even years.

Quote:

And EF handles sprocs perfectly well.

Ah, maybe I should have mentioned that we were using it against an Oracle database. It is true that it talked well with SQL Server, but it wasn't at all happy understanding Oracle packages and views.

Quote:

make sure you're aware of the current capabilities - not what is was 6-7 years ago.

This was indeed 5-6 years ago, so newcomers will hopefully have a better experience with EF than we had :-).

Quote:

Have you seen what complicated queries it produces for just one simple table ?

Amen to that. And if you are not careful, it will also open multiple connections to the poor database server. And if you have had the audacity to use views and stored procedures to do a clean database design - oopsie, EF doesn't like that. I implement the business logic in the database and surface client-ready interfaces via views and stored procedures. That way, something like EF is not needed. But if you don't have a DBA around, and you are OK with using the database as dumb storage - then EF looks like a good fit.

I also like Linux and use it quite a bit. When on Linux I use LibreOffice, GIMP, QtCreator, GEdit, Atril document viewer, SimpleScan ... and sometimes a browser. So mostly Desktop applications :^). But hey - I am over 50 so I am legacy myself :laugh: .

I am also actively developing things in Delphi and maintaining both large and small existing applications. For Desktop app development it is by far the most productive environment I know. Too sad that it is perceived as legacy, but then it seems that the whole concept of Desktop apps is becoming legacy - apparently running everything in a browser is the way to go these days. So in that respect WinForms and WPF is legacy too :rolleyes:.

Or try to do consistent quoting to pass parameters to an external executable. It's mind-blowing that a fundamental feature for a scripting language - interfacing to other commands - is so complicated. I have in some instances ended up passing parameters to batch files as environment variables. That works reliably. And then there was the lovely incident with invisible files in an earlier version of PS. I called out to a batch file that created files on a network drive. Unfortunately, when I returned to PS the files were invisible until PS was restarted. Not a happy experience, when the PS was supposed to process backup files produced by the batch file. Caused me a good deal of lost hours - and backups! And yes, the function return value mystery. Who ever thought that was a good idea ? I have really tried to like PowerShell. It feels like it should be a major step up from MS-DOS scripting with proper flow control, error handling, etc. But now I try to stay away from it, as it usually ends up eating my time, especially when I need to make it talk to existing scripts. One success story: I did a PS script that read a file and processed it via a .NET library. That was easy, clear code, and no surprises.

Most of my customers are long-time customers so I have VPN access to their net. That means that when I work remotely it is via Remote Desktop on the customer's machines and so the work I do never leaves the customer site. For other clients I have shared end products in a folder on my own web server (password-protected if confidential) or uploaded to customer's sharing platform of choice (lots of cloud offerings for file sharing). Been a long time since I used CD-ROMs and pen drives - but yes, that's a rock solid solution. Go with the pen drive if you have to ship physically; optical drives are becoming scarce.

Exactly. The code shown will give a readout of the DC (static) input voltage, it will not tell you anything about the tone signal. To sample the input at a decent frequency, forget about using analogRead(). It can't sample faster than about 9000 Hz. You will need to set the ADC in free-running mode and after the necessary code changes to support that, you then need to see how much RAM you have availble for sampling, and how fine-grained an FFT you can do on that given the limited processing power you have. Let's assume that you can get a fine-grained FFT. If you play a single string on the guitar it will be fairly simple to determine the base frequency and convert that to MIDI. Now strike a chord. Now you have six different strings that all produce base frequencies and overtones and you need to deconvolute them. To produce correct MIDI you have to do all this in real-time. The delay from string-played to MIDI-produced has to be below 10 ms if you want to use the MIDI signal to trigger a guitar synth or another instrument without noticeable delay. If you "only" want to record and can live with a fixed larger latency, fine, but you still have to be able to process all input in real-time. One of my friends has a home studio and he uses a piece of software that can analyze all kinds of instruments and e.g. split a guitar voice into the respective strings and display what is played as finger settings. Really awesome, but of course, it costs :-). You can buy dedicated hardware to plug into your guitar that outputs MIDI for around $100. Just saying :-)...

Very mixed. The good: * Debugging is excellent. * Syntax is very nice for some commands. * You can do proper loops and structured programming. * Ability to call .NET methods directly is very practical. The bad: * File system interaction is an abomination - lost work due to PS's perception of the file system being out of sync with the real file system (time stamps). Why does it have to have its own file system abstraction that even tries to cache stuff ? * Had to fall back to DOS CMD to get simple stuff working reliably, e.g. mounting a network drive. * Syntax is weird for some commands. * Calling out to other command line tools is ... challenging (e.g. parameter handling). I will wait for the dust to settle on a couple of versions more before I try it again. Particularly the bad file system interaction and awkward integration with other command line tools has scared me away.

Marc Clifton wrote:

do you have actually have any business logic that actually does something internally with the data?

Indeed - and where is this business logic implemented ? If it is implemented in stored procedures (so all types of clients will have the same logic enforced), and you use views to decouple the clients from database dependencies and control client access, and you run an Oracle database - beware of the ORM. I sat on the sideline and watched a developer attempt to create a mostly auto-generated NHibernate-based C# WPF application against such an Oracle database. The schedule slipped again and again, and when the application was released it was a memory-hog, slow, and really hard to maintain. We already had a prototype non-ORM application written in a few days - but someone wanted a WPF app. But I can imagine that if you are interfacing directly to "dumb" tables with no server-side logic applied then I guess the situation will be different. Oh, and if your database is SQL Server - at least the developer in question never got Visual Studio to interpret the Oracle view layer correctly.

:thumbsup: :)

glennPattonWork wrote:

(safety critical system)

In that case it is easy: If it passes a test that previously failed, you need to raise it as an issue. In general: Passing a test that is supposed to fail is of course a failure. Doubly so in safety critical systems.

I use Delphi regularly. On Delphi XE7 these days. I still don't see any of the other popular IDEs deliver the same blinding-fast compile time and self-contained EXEs. Deployment is true xcopy-deployment with no runtime dependencies other than Win32. So for me it delivers great value. I will however agree on the pricing issue. Major reason why I don't upgrade the IDE often :). Embarcadero releases a new version every year or so, but I find it harder and harder to see what's new. At least they are still working on the product. One application I maintain is built using Delphi 7 (from 2002). The EXEs still work flawlessly on Windows 10 - even look like proper Windows 10 applications. That may be more a testimony to how well MS backwards compatibility works, but still...

Peter Shaw wrote:

I can guarantee I get about 5 or 6 "MAJOR THREAT" alerts from the company, per month, alerting me to the fact there has been a "MAJOR BREECH" of my personal and private data, and that they are doing everything they can to contain it, so that I don't get affected by identity fraud. The alerts? There all any time some one uses "0123456789" as a telephone number, or provides "me, 1 a house, a street, a town, AB1 2CD" as an address, in some credit check, or if these details are found on line :)

:laugh: Awesome! Thanks, you just made my day :laugh: .

Slacker007 wrote:

I wonder if this has anything to do with CHAR is fixed length and VARCHAR is variable length?

Yup. I know this is a question about SQL Server, but I have a feeling that they have adopted some old logic from Oracle. In Oracle the CHAR type will automatically pad data with spaces so the data field always occupies the max length you specified. CHAR versus VARCHAR2 Semantics[^] In that context, the behavior of len() is actually the only one that makes sense :wtf: . So, to keep your sanity you never want to use CHAR but always VARCHAR/VARCHAR2 :-). Or, in Postgres - just use TEXT to get rid of all those pesky length constraints as well.

Couldn't agree more. I have used SumatraPDF for years and am very happy with it.