|
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
|
|
|
|
|
Quote: I'm finally at the point that I can start installing dev tools again
How about starting the installation by a story...
0. Grab bottle of Shiner.
1. Walk in to your desk.
2. Open your laptop.
3. Turn on the power.
4. Google and download the tools.
5.More stories...
|
|
|
|
|
I've keep a few VM's in different stages.
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....)
Message Signature
(Click to edit ->)
|
|
|
|
|
Okay, that was an analogy.
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)
For example,
If x is a:
do
is different from
if x is a:
do
It's funny, and doesn't this sound rudimentary and a bit annoying? 
modified 13-Jul-19 12:00pm.
|
|
|
|
|
The first version will not work as it has a syntax error. It should be:
if x is a:
|
|
|
|
|
fixed ! Thanks
|
|
|
|
|
It sorta makes sense, and in theory at least should encourage correct indentation.
But ... that won't save it. Survey Results - If you know C, C++, C#, Objective C or Java do you also know Python?[^]
Just the "no need to declare variables" sends a shiver down my spine. That's actually worse than VB could manage - and that takes some doing!
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!
|
|
|
|
|
OriginalGriff wrote: "no need to declare variables" sends a shiver down my spine.
Er, isn't that exactly why the "var" keyword was invented? A few years from now no one will be using proper typed variables any more.
|
|
|
|
|
Oh, no, no, no, no!
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!
|
|
|
|
|
OriginalGriff wrote: Python's version is worse
I agree, but you can still do quite a bit of damage with var.
OriginalGriff wrote: Strongly typed variables should be mandatory in all languages used in the 21st century!
That is definitely true; but will teachers explain that properly to their students?
|
|
|
|
|
Richard MacCutchan wrote: I agree, but you can still do quite a bit of damage with var.
In what language?
JavaScript? Certainly, but JavaScript doesn't really get much better than that...
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.
|
|
|
|
|
C#
var elapsedTime = stopwatch.ElapsedMilliseconds;
var processedCount = GetProcessedCount();
var processedPerSecond = processedCount / elapsedTime * 1000;
Spot the bug.
|
|
|
|
|
Fueled By Caffeine wrote: 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...
var query = databaseContext.SomeTable;
query = query.Where(x => x.SomeBoolLimitingTheResultFromThousandsToTens);
return query.ToList(); 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.
Fun times 
|
|
|
|
|
OriginalGriff wrote: just pick a name and assign a value. So if you misspell it ... that's a new variable
but how do you misspell "i"
Message Signature
(Click to edit ->)
|
|
|
|
|
'j'? 'u', 'o', 'k'? All easy to do, especially on a "soft keyboard". 
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!
|
|
|
|
|
Use Cryllic. Word doesn't match the second as 'sit':
sit
sіt
|
|
|
|
|
There is also the "Extra quote character": ''' which looks just like the ones around it, but will not compile in other peoples code - not that you would replace any, I'm sure ...
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!
|
|
|
|
|
|
lopatir wrote: but how do you misspell "i"
Right. That cost me a couple days of work, in the days when Fortran, as well as hardcopy code, were still around. (Yes I know there are languages called Fortran today, but they look completely different!). The loop went trhough once (as Fortran always does), but wouldn't repeat. I didn't discover the problem until I sat down with a printout of the disassebled binary code. Fortunately, the disassembler made use of the symbol defintions in the debug info, and fortunately, the printer (as opposed to the screen) used serif fonts. Then I could distinguish an "l" from an "I", so a conditional jump out of the loop used a diferent variable from the intended one.
There are several such "false friends". I should have known, because in my student days, one of my friends who was a TA in the elementary Fortran programming class caused and "incident": The professor insisted on Norwegian variable names, so instead of "QUEUE" the variable should be named "KØ". "Ø" isn't recognized in Fortran, but ø is commonly transcribed to English as oe, which makes it "K0E". Because we have Ø as a letter, we do not slash zeroes here. Depending on the typeface, KOE and K0E may look almost perfectly identical. They did on our screens. When Jon discovered, he exclaimed loudly so that everybody around could hear hear it to the very good-looking, 18 year old female freshman: "Look, here you are not saying k-oh-e, you are saying k-null-e!" Zero is "null" in Norwegian and "knulle" means f**k... Jon didn't realize was he was "suggesting" until the word had been pronounced, and he got so ashamed that he wanted to flee away. But the girl did accept his excuses.
Actually, it doesn't take national characters, like ø, to confuse 0 and O - even in English-speaking environments, non-slashed zeroes are common. Some typeface do not distinguish much between 1 and l either - I have seen troubles caused by that pair as well.
|
|
|
|
|
Fortran: screen?? You were doing it wrong. If you'd had the punch card deck you'd have spotted the mistake straight away...
|
|
|
|
|
During my first student year, we actually did punch cards! Or, we filled in coding sheets, handed them in for punching by trained typists (especially well trained in mistyping...), and the turnaround time could be 36-48 hours in rush periods. Interactive terminals on 300 bps serial lines were reserved for graduate students. During the second year, we got three 16 bit minis, each handling 16 screens at 9600 bps, and a full screen editor, which made the big and proud Univac 1100 mainframe look so much like a clunky old wreck that we were ordered to reduce the line speed of the mini's terminals to 1200 bps, so that we did not put too much shame to the great mainframe. (The TAs, I was one, managed those three minis more or less ourselves.)
Then (fall of 1979) Fortran was replaced by Pascal as the language for the "101 Basic programming" course for half of the students. Some departments refused to switch - noone in their branch of engineering would ever be programming anything but Fortran! Other departments accepted Pascal only conditionally: The EE departement accepted it only if the Computer Science students (like myself) were required to take a course which covered e.g. 3-phase power distribution networks...
The incident with the I/l mixup happened around 1985, after I had completed my degree and was working at the University Computer Center. The guy with the problem was in the Mechanical Engeneering department; they still clung to Fortran as The Only Language at that time. But they did accept screens then! (Besides, I don't think there ever was delivered any punched card reader for the 32-bit supermini series that they were using.)
A few years ago, a studymate of mine, working at the University supercomputer center, surprised me by telling that for FEM, weather forecasts and similar typical supercomputer applications, Fortran is still the language of choice! It is no longer Fortran IV, though... Strangely enough, I cannot find on the Internet who said, in the discussions of the proposed language extensions to become Fortran 77: "I don't know what programming languages will look like in year 2000, but they will be called Fortran..." - one of the big gurus of the time, maybe Hoare or Dijkstra. When I paraphrased that statement in my earlier post, it was intended as a historical reference, but it seems like the quote has not survived history. Whoever said it was perfectly right: Fortran 2003 is called Fortran, but looks nothing like Fortran IV.
|
|
|
|
|
Which is why I see Python as a poor choice for teaching beginners to 'code'.
Take this class definition containing a function:
class StringFormat(object):
@staticmethod
def FloatToStringFormat(num: float, decimalPlaces: int) -> str:
return "{:.{}f}".format(num, decimalPlaces)
Calling it like this:
resultAsString = StringFormat.FloatToStringFormat(20.123, "2")
I would expect to get an error as I am passing in a string rather than an integer for decimalPlaces.
But no, Python happily sets resultAsString to "20.12"
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's interesting to see in this discussion that one of python's more attractive features is seen as a disadvantage 8)
Once again, the debate here about whether the language is 'good' or not seems to have nothing to do with whether it actually is good or otherwise, but simply amounts to 'does it fit my idea of how a language should work'.
If I've learnt anything from over 40 years of software development, it is that (with a few domain specific exceptions) the skill of writing good software - don't mistake me here, I'm not saying that I write good software! - has almost nothing to do with the language you write it in, and everything to do with domain knowledge and the skill of the programmer(s).
Every language has rules; every language has flaws. Being aware of both and using/avoiding them so you produce good code is what it's all about.
The behaviour cited above as being 'problematic' is exactly why I use Python for certain types of project.
8)
|
|
|
|
|
Mike Winiberg wrote: has almost nothing to do with the language you write it in, and everything to do with domain knowledge and the skill of the programmer(s).
I agree.
I am glad you used the word "almost", because using Windows batch scripting for some devops work I have been doing has resulted in me having to work around the language and do things in a manner that I would not see as particularly elegant.
Of course I could rewrite it with powershell scripting, which is on my list, but when you are working on systems that are business critical - doing a large code refactor is not always possible largely due to the cost to the business.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Oh yes, I was careful to say "almost"! 8)
It never ceases to amaze me how complex a process could be constructed with DOS batch scripts - often by relying on obscure side-effects of small .COM files etc. I've always liked Powershell (although I rarely use it!) because it seemed a genuine attempt to provide a full batch environment for windows with 'proper' controlled access to the entire system.
I do find the verbosity of the naming convention somewhat off-putting though (as indeed is the case for some other languages) - ridiculously long and complex variable names can be as difficult to manage as i, ii, iii and iiii etc!
(I once spent over a day hunting down a bug in some C++ code where a stupidly long descriptive variable name had been used in multiple places with two different internal spellings via a macro such that the compiler didn't 'notice' the variants!)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
