To me that turn doesn't look like it lines up with the street I'm seeing over to the right of the picture - which makes me wonder if the turning lane is for something else and the no-right-turn sign is for that street to make sure people don't try to cut from that turning lane into it. I'm too lazy to try to track the street down in Google Maps to check though.
fyjham
@fyjham
Best posts made by fyjham
Latest posts made by fyjham
-
RE: To turn or not to turn, that is the question.
-
RE: Fight the Powah
In the interest of losing in performance to regex (example is in C#):
public static bool CheckPowerOfTwo(int value) { checked { try { for (int i=1; i < Int32.MaxValue; i++) { int powerOfTwo = 1; for (int j = 0; j < i; j++) { powerOfTwo = powerOfTwo * 2; if (powerOfTwo == value) return true; } } return false; } catch (OverflowException) { return false; } } }
Didn't let it play out long-term, but it took 20 seconds to do the first 4000, so in theory it should take a few months to do all integers...
-
RE: If an error message falls in a forest...
@JvdL said:
Logger.Warning("{0} is a moron because {1}", jvdl, designException);
The logger will handle such an invocation based on the severity (warning), the category derived by logger from CallingAssembly attributes and reflection. When sevcat merits logging, it compiles a message with time stamp, log text, user, source, machine, stack traces. It dispatches that to one or more handlers associated to that sevcat.
Sensible at this stage. Now let's pose the next question: What configures where the severity categories go? Does the framework itself dictate that these go to the console, or are you instead providing this from the calling Application when you initialize your logging framework (Either via configuration settings or programatically creating handlers for the levels)? If your framework takes it upon itself to decide to write it's errors to the stderr then you bet I'd disagree. If your framework is instructed by your calling code that errors at severity X go to stderr, so be it because then it's told you to do so.
You seem to have described your logging framework as dictating where thngs go, so in that regard I would say that either you shouldn't touch the UI from it or alternatively the application should (By configuration, parameters to a constructor, static methods, inherting a logger and implementing methods, or some variety of mystic voodoo chant) provide the logging framework with a mechanism for showing the error to the user. The fact the Logging layer may be deciding whether to show it is one thing, but the decision of whether "Show it on the UI" means it should be put into a HTML box with a red border, shown in a popup dialog above your forms application, written to standard error or printed out and strapped to the leg of a carrier pidgeon with instructions to deliver it to the user is a decision the UI layer should be making.
-
RE: If an error message falls in a forest...
@SEMI-HYBRID code said:
we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.
Funnily enough, to have DirectX use the UI you have to give it a window handle (EG: Your display code has explicitly said "Please, draw all over this part of the UI"). OpenGL I don't have a great deal of experience with, but if I recall correctly once again you have to provide it with some kind of window or explicitly instruct it to create it's own. This falls under the "The UI has explicitly asked the DLL to do this, therefore go nuts" heading. As far as interfacing directly with the hardware... that's hardly the same as the UI. Unless you're referring to input hardware such as the keyboard etc, in which case most input libraries from these require the UI to explicitly tell them they want them to take over that input device. So those fit within the paradigm me and blakey were suggesting.
I don't think anyone's trying to say that DLL's should never touch the UI, moreso that they should not do so without the application explicitly requesting that they do and that wherever possible this interaction should be via an abstraction layer (Which in some cases like 3D graphics can not be an option due to performance).
@SEMI-HYBRID code said:
okay, then there's a question - does writing to console prevent the library from being a black box/working in a black box? how do you know the dll is not writing into console it has created for itself in the init function? what part of the snippet presented in the OP definitely says that it's using a console that it assumes is already there, created by someone else in advance?
Well, System.Console is a static class without a constructor in .NET, so I guess I'd have to say I don't know explicitly that this code hasn't already called SetOut on the standard console prior to doing this, but what I do know is that if the DLL in case of error without informing the application updates where the shared static class for writing to the console puts it's output then that would be even worse
-
RE: If an error message falls in a forest...
I'd have to agree with blakey here. I've always found it a little bit silly that Console is static in C#; would much prefer it to actually be an instance of an object so that if the UI doesn't want to give a handle to that object to another class (whether in a library or otherwise) then it can keep it's grubby hands off the interface.
While I wouldn't be so extreme as to say a DLL should never touch the UI or have UI logic in it, I would certainly agree that it shouldn't touch any part of the UI without the calling code explicitly handing it a reference to the UI it is going to work on. By all means a DLL can be passed Console.Out and Console.In and then do whatever it's meant to do with them, because at that point your UI-layer has essentially requested that the shared library perform actions on the UI itself. For a shared library to make an assumption, unsolicited by the calling code, that it can just go straight to the user interface without the UI layer being involved is just bad design. And if a bad design which is typically indicative of an error can be detected by the IDE/compiler then I agree a warning is a very good way to deal with it.
-
RE: Symantec is worse than many viruses
@Anonymouse said:
That's not entirely correct. Mostly because the definition of "good" can differ widely from application to application.
A hashing algorithm does not necessarily need to burn thousands of CPU cycles to be good (in fact, in a speed-critical application, that's the *last* thing you want).
A fast hashing algorithm is just not very desireable in a cryptographical context, but then, you can always stretch your keys...
Yeah, true, a hash can be used for many things, perhaps I should have said a good hashing algorithm for this task.
In context of what's being protected though you'd really need a slow hashing algorithm, or to use key stretching which has a net-result that your complete algorithm for generating your hash (Inclusive of stretching time) is a slow hashing algorithm despite using a slightly faster hashing algorithm at the core, to be secure enough for the task.
So yeah, you're right, but I think the core point still stands, just the statements don't necessarily apply in all contexts.
-
RE: Symantec is worse than many viruses
@sprained said:
Of course you could search. You hash the search input and then search for it against the stored hash.
That said, I'm not sure what the point would be of storing them other than for search purposes.
Only if you didn't salt the hashes, which would be fairly insecure and open to attack with rainbow tables pretty trivially.Otherwise you'd have to loop over every single record, get it's salt, hash your input against that salt and then compare it. Which assuming you have a lot of data (Symantec probably has a lot of customers in their system) and a hashing algorithm which is processor-intensive (Which it needs to be to be a good hashing algorithm) then that should take an incredibly long time to run that search.
-
RE: The Perfect Lack of Understanding
@snover said:
Writing $(document.getElementById('mcRdata_lg_'+a)) instead of $('#mcRdata_lg_'+a) makes sense—if you are getting paid per character. Otherwise it’s just fucking stupid.
I assume he was referring to the overload being available, as per dhromed's comment. I think (and hope) nobody's stupid enough to defend that approach.
-
RE: SavePageStateToPersistenceMedium In HTTPModule.
Hey,
Just grabbed that snippet for ya. This is something we use to compress the viewstate and we've been using it for a few years now across multiple sites with no real issues. Ours is overridden in a Page class that we use that all our pages inherit from not in a HttpModule though... The compression/decompression stuff references some of our internal libraries that I haven't included, shouldn't really need that part though if you're going for storing it server-side.
protected override object LoadPageStateFromPersistenceMedium()
{
string viewState = Request.Form["__VSTATE"];
byte[] bytes = Convert.FromBase64String(viewState);
bytes = Anonymized.CompressionTools.DeflateDecompress(bytes);
LosFormatter formatter = new LosFormatter();
return formatter.Deserialize(Convert.ToBase64String(bytes));
}
protected override void SavePageStateToPersistenceMedium(object viewState)
{
LosFormatter formatter = new LosFormatter();
System.IO.StringWriter writer = new System.IO.StringWriter();
formatter.Serialize(writer, viewState);
string viewStateString = writer.ToString();
byte[] bytes = Convert.FromBase64String(viewStateString);
bytes = Anonymized.CompressionTools.DeflateCompress(bytes);
ScriptManager.RegisterHiddenField(this, "__VSTATE", Convert.ToBase64String(bytes));
} -
RE: SavePageStateToPersistenceMedium In HTTPModule.
It's definitely quite possible to change what gets rendered into the viewstate, and so long as you override the methods that pull it back out you can do so seamlessly. I've used this previously to gzip the viewstate, but if you wanted to put an index in the viewstate and look it up from somewhere later there's no reason it wouldn't work. I'd question using the cache - given it could easily be cleared before the user returns, and I'd recommend at least some effort to avoid a user faking another's viewstate ID - but there's nothing fundamentally impossible about the concept.
Be sure to get the right save/load functions - there's more than one spot you can do it and some don't work with .NET AJAX. I don't recall exact methods but if you'd like I can track down that gzip code and post a snippet that'd help you on your way?