|
If it is good stuff, smoke it.
... such stuff as dreams are made on
|
|
|
|
|
Hmmm, Silicon Oxide and Carbide, Umm no thanks!
|
|
|
|
|
Since it isn't your code, dig deeper... find out what is wrong.
Document what you are seeing, what you find, and what you do to resolve the issue.
|
|
|
|
|
If you know that the conditions are so that a test should fail, yet it doesn't fail, then there must be something wrong with your code!
(Saym your code actually fails the test, but immediately thereafter, a write through a stray pointer changes the verdict from 'fail' to 'pass' ... Certainly not very likely, but not failing when you know that it should is not very likely either.)
Gererally speaking: Failing to fail may indicate a failure.
|
|
|
|
|
Member 7989122 wrote: Gererally speaking: Failing to fail may indicate a failure.
I fail to see your point.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
It used to be we would just test our code, usually by walking through it line by line (though maybe that's being optimistic) or, even more "archaic", we would write up acceptance test procedures and walk the application through the steps in the ATP. Now, with the advent of unit tests, what do we end up doing? Testing our tests! 
Latest Article - Code Review - What You Can Learn From a Single Line of Code
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Depends - what's your job? Do you have access to the source? What did your boss ask you to do? What's your skillset? Is this a wind-up question?
Asking daft questions can often give unexpected results too...
|
|
|
|
|
My job is to test it. Not really specific its hardware or software 'it' being the metal box. Wasn't really a question to which I was expecting an answer more opions.  The person to ask daft question of was around but busy today (read don't bother him!) As for the source I am not touching it (safety critical system)... 
|
|
|
|
|
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.
|
|
|
|
|
Not to worry it was bounced back to those who can. Just the Monday mutters 
|
|
|
|
|
|
So I am forced into understanding how to use JSON in python for a private project (home automation), because I reuse some open source code.
And so far, I failed blatantly - I do not understand the point.
From an online tutorial example:
------------
import json
pythonDictionary = {'name':'Bob', 'age':44, 'isEmployed':True}
dictionaryToJson = json.dumps(pythonDictionary)
If we print dictionaryToJson, we get the following JSON data:
{"age": 44, "isEmployed": true, "name": "Bob"}
--------------
So I do not grab the concept -> Why do I need a special format and functions to print the exact same thing that I had in the dictionary  ?? But I am still digging, so give me a couple of hours and it will be obvious. Hopefully.
My problem is not the printing, it is that the json stuff is a PITA when used with Unicode, and that's what the stuff I am working on is using. I'll end up rewriting everything, I see it coming..
|
|
|
|
|
you dont have the exact same thing, first of all, the braces are missing as they are syntax in the definition of the dict, but are part of the OUTPUT for a valid json string.
json is nothing more than a simpler, better readable xml (to give you a reference about what json is).
json can do much more, same as xml can do much more than <tag>value</tag>.
json has arrays, objects, so many things that are more than a simple key/value pair as in your example.
use a json formatter as you would use a xml formatter.
|
|
|
|
|
I am not convinced you can "do more" with JSON than XML, and I've never been sure why anyone felt the need to "invent " JSON when XML already existed. Anything you can do in one you can do in the other, and while JSON may be slightly less verbose, I wouldn't say it's easier to read. Personally, though, I regard both as the spawn of the devil. Ghastly things to deal with. Give me a proper database any day.
|
|
|
|
|
I dunno - I quite like JSON as a data storage medium - not as a database, it's a text file, after all - particularly if you use Newton.JSON: you can add it to your project via the NuGet Package Manager (Tools ... NuGet Package Manager ... Package Manager Console)
PM> Install-Package Newtonsoft.Json Then it's simple: serialize or deserialize in one line of code!
string json = JsonConvert.SerializeObject(myCollectionOfObjects);
List<MyClass> items = JsonConvert.DeserializeObject<List<MyClass>>(File.ReadAllText(path));
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes, well NuGet is something else I avoid like the plague! I do use Newtonsoft (and it is a Godsend, though I could wish for better documentation for dealing with complex structures), but just give me the dll's, please, not some freakin' package manager.
|
|
|
|
|
I used to think that, but I'm coming round - it means that the whole package is installed, so if there are dependant DLL's you don't have to scratch around to find them for each project.
The documentation could be loads better, yes! But that is ever the case these days. (And old days as well - remember MickeySoft MSDOS manuals with the "brick wall" learning curve?)
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I didn't mean, that "json is better than xml" - what I wanted to say, was, "that json can do much more than a simple key/value pair" as we have seen in the example of the op.
sorry if you misunderstood that.
|
|
|
|
|
well, no - my bad - I did kind of get what you were saying - guess I was just taking the excuse to air my grievances at JSON, which I ma having to deal with right now, and loathe it!
|
|
|
|
|
I don't think that "doing more" is the point, unless you're talking about BSON serialization.
A_Griffin wrote: JSON may be slightly less verbose,
That has my vote as the understatement of the year.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
A_Griffin wrote: I've never been sure why anyone felt the need to "invent " JSON when XML already existed.
Because data transfers to/from mobile devices going across mobile data plans (Verizon, AT&T, Sprint, T-Mobile, etc.) get very expensive when using text-heavy XML. <myxmltag>My data costs a bit more than { 'myXMLTag' : 'My data' }, especially sending a big dataset.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Damned mobiles have a lot to answer for! As developers for years we had the luxury of coding for ever larger, ever better screens, more memory, more powerful CPU’s and faster data transfer… then mobiles came along and suddenly we were back to square minus one.
And people called it progress….
|
|
|
|
|
In the immortal words of Angelo 'Snaps' Provolone, quit squawking. 
Seriously, though, the bloat in XML syntax always bothered me. I'm just surprised no one has pushed the JSON concept to replacing HTML's bloated tagging syntax.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Well, in most sensible countries (so excluding the USA in this regard) data transfer isn't really an issue any more, either in terms of GB or speed. I never have to give it a second thought (here in the UK).
|
|
|
|
|
Json is one of those xkcd 927[^] "yet another way to do it" standards. When you've seen a dozen such formats, you have seen them all. (And Json is numbered higher.)
The (official) reasons for making yet-another-format is usually either that some tiny little functional detail is missing or done in a way that someone dislikes, or that it is "much simpler". (I guess the "simpler" argument is the primary one for Json.) If we could spend our energy learning to master a somewhat more complex, but a lot more functionl language, rather than having to learn eight different "simplified in my way", I think it would have been much better.
Json certainly isn't worse than any of the other "simplified my way" alternatives. It is just yet another "yet another language".
(Another less official reason for making new languages, of all sorts, is obviously the power struggle: If you can sneak in your new standard/language so people start using it, then you gain power, because you control the standard: You have the right to define concepts and "correct" thought patterns when the stanard is used; you define future extensions and thereby which ideas shall have the strongst support etc. etc. You'll never hear the standard owner agree to that, but ask those who oppose to the standard!)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
