The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
This intolerance on other opinions is a hugh problem. Only open minded discussion leads to better solutions. I am afraid about upcoming dark ages, because I lived in socialism and know its consequences.
Press F1 for help or google it.
Greetings from Germany
I seemed to have screwed up BOTH Win7 VMs, so I decided to start over.
On my dekstop, I was smart enough to have made a snapshot of the VM aftr getting the VM working with the display, USB3 and networking, before installing any dev tools. This allowed me to delete the snapshot and create a new one, and only have to install the dev tools again.
The loaptop was a different story, and I had to delete the entire vm and start from scratch. I'm finally at the point that I can start installing dev tools again.
What a crappy kind of weekend...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
First one is base OS with basic utils and settings the way I like, then take a snapshot
clone that (after snapshot) and add dev utils, database tools, libs (but not the databases), snap shot
clone that, install & pref-set visual studio, snapshot
clone that, snapshot, add local databases, snapshot, do work, occasional snapshots (so backup only needs the last snapshot file)
the last [pre-clone] snapshot on each machine, (particularly the first one), provides for testing on a fully clean settings (untainted by something quick-modded during dev/app install and not recorded in the installer script/notes, i.e. reg setting/dll often overlooked) and fully clean/restore it after for the next time.
... if say added some garbage extension/setting to vs, can snap back to the clean vs
... if say database upgrades, can test the upgrade. if wanted few months later roll back snaps/clones and re-build "new machines" using it as the base version.
lately moving from vs17 to 19: cloned pre-vs and installed/pref set 19 - fully clean, no 17 baggage issues
(and just in case of problems kept the vs17 ones around till I was sure I could ditch them.)
think like those guys like linus on youtube when they test soft/hardware: they have a store room of different machines to pick from - some clean/re-cleaned, some [part] modded, some old, some different o/s....)
I was trying a little piece of Python code. Got a bit surprised with the "positional"-indentation requirements in code. Just like how it used to be in older programming languages like Cobol. (I'm not sure if any other recent programming languages enforce these)
If x is a:
do //indented & works
is different from
if x is a:
do //Non-indented & throws error
It's funny, and doesn't this sound rudimentary and a bit annoying?
Python's version is worse: you don't need to declare the variable using "var", or "Dim", or anything - just pick a name and assign a value. So if you misspell it ... that's a new variable.
Just like FORTRAN was back in the day (1977). And that caused a probe to miss the planet Venus completely, so what it does in a banking app, or a Boeing 737 Max is not something you want to think about too hard, really.
Strongly typed variables should be mandatory in all languages used in the 21st century!
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
I agree, but you can still do quite a bit of damage with var.
In what language?
In C# it's still a typed variable, so it's exactly the same thing as explicitly using the type name except instead of the type name you use var. So no damage there, except to readability.
var processedPerSecond = processedCount / elapsedTime * 1000;
Probably there, you get an int instead of a decimal?
However, changing var to decimal will still result in a wrong output as an int is silently cast to a decimal, but that doesn't change outcome of the divide operation.
The fix I think you're looking for is:
var processedPerSecond = (decimal)processedCount / elapsedTime * 1000;
Now here is a fun bug, which I've seen go wrong multiple times...
In this piece of code the query variable is of type IQueryable.
That means the Where that is executed is actually Queryable.Where(IQueryable, Expression).
The actual database call, with WHERE clause, is executed on the ToList method (or more precise, in the Enumerator).
Now someone comes and changes the code, the first line becomes var query = databaseContext.SomeTable.ToList();
Suddenly, the type of query has changed to IEnumerable!
The database query WITHOUT the WHERE clause is executed and Enumerable.Where(IEnumerable, Func) is executed to filter the collection in-memory.
You now get thousands of records instead of tens, while the in-memory Where is probably more expensive than the database WHERE.
All in all a nice performance hit...
That is actually the only bug I've ever encountered while working with var, and it's pretty specific.
And the only reason it goes wrong is because IQueryable and IEnumerable have pretty much the same extension methods, save for Expression and Func, but a Func can be implicitly cast to an Expression.
If I wasn't using a strongly-typed language, and had an a**hole for a coworker that needed a lesson, I certainly would! Send him a copy in which a variable has unicode changes but looks the same: "It works for me, I can't understand why you are having problems!"