The wonderful world of compilers
-
JScript is based on the ECMA standard for JavaScript, it's like 98.99% compatible.
There are some constructs you can do in JScript that you can't in JavaScript. For example, in JScript this works:
var gebi = document.getElementById; gebi("test"); // worksThat doesn't work in JS proper.
Repeating, of course.
-
JScript is based on the ECMA standard for JavaScript, it's like 98.99% compatible.
And here I was, trying to avoid pedantic dickweedery.
-
var gebi = document.getElementById;
gebi("test"); // worksThat doesn't work in JS proper.
Huh. Hey, that'll maybe clear up something for me. Earlier today, I saw some abortion of JS like this:
if (!(x = document[n] && document.all) x = document.all[n]
where n is the name of a form field. Is this supposed to be abusing the thing I quoted? Because it doesn't work in IE Edge or in non-IE browsers. I think just replacing it with x = document.getElementById(n) will work but I'm not sure.
-
-
if (!(x = document[n] && document.all) x = document.all[n]
I think your code for Discourse'd. Because that's gibberish, as far as I can tell.
It looks vaguely like an ancient "is this running in IE?" test. Like, pre-IE6 ancient.
-
FrostCat said:
trying to avoid pedantic dickweederyWhy??? You must be new here.
Novelty, perhaps.
-
He gave you a nice pointer.
-
I think your code for Discourse'd. Because that's gibberish, as far as I can tell.
It looks vaguely like an ancient "is this running in IE?" test. Like, pre-IE6 ancient.
That is actual code, unless I typoed it--I quoted from memory. It is, in fact, pre-IE6: the site is designed for IE5, and now it has to be updated for the major modern browsers. This line is part of a script run on form submit,and kills the page on non-ancient-IE browsers.
-
And here I was, trying to avoid pedantic dickweedery.
We're pedantic about everything besides its/it's, evidently.
-
We're pedantic about everything besides its/it's, evidently.
Like I said, novelty. "Confusion to our enemies!" is my motto.
-
-
These comments made me go back and re-read what I wrote above, and I managed, without trying, to avoid using either word at least twice.
-
Ok well it's missing at least one paren, to start with. And without any more hints as to what "x" is (and yes I know you need to anonymize it or whatever), it's hard to tell what the intent was.
-
Ok well it's missing at least one paren, to start with. And without any more hints as to what "x" is (and yes I know you need to anonymize it or whatever), it's hard to tell what the intent was.
That wasn't anonymized. At all. The variables were x and n.
if (!(x = document[n]) && document.all) x = document.all[n]
That's the exact line. n is a parameter, and it's the name of a form field. x is just a var that was defined one line previously. Like I said, I assume it can be probably safely replaced with "x = document.getElementById(n)" but I'm not positive.
-
That's the exact line. n is a parameter, and it's the name of a form field. x is just a var that was defined one line previously. Like I said, I assume it can be probably safely replaced with "x = document.getElementById(n)" but I'm not positive.
Ok I kind of get what they're doing, but I think we're veering into fucking IE3/Netscape 4 territory here.
Browsers used to implement a DOM element in document called "all" which was a single associative array of literally every other element in the DOM.
I don't think you can replace it with getElementById because I'm pretty sure document.all either only indexed by element name, or indexed both name and id. I honestly think it's fucking old enough to predate id altogether.
-
I'll check. There have been efforts to update the whole thing, so it's possible the form fields have ids. If I can't just replace that one line, the entire function will have to be replaced, because it doesn't work in ANY modern browser, and my job this month or so is to make it.
The thing I like about my company is TRWTF is stuff like this, or "all the tables that have border attributes instead of CSS cause rendering difference between browsers, so we'll use jQuery to inject a style into all the tables with the obsolete attribute, to fix the rendering, so we don't have to edit 3000 files." I mean, it's a WTF, but it's frankly small potatoes compared to the usual kind of shit here.
-
because it doesn't work in ANY modern browser, and my job this month or so is to make it.
No shit. document.all['element'] and document['element'] have been deprecated for like 10+ years.
-
No shit. document.all['element'] and document['element'] have been deprecated for like 10+ years.
Ha! Well, this site is older than that. What can I say, it predates my being at this company, and I'm trying to fix as much as I can get away with. Our Indian offshore programmers are estimating 5000 man-hours to add browser cross-compatibility, so they're very interested in shortcuts. The first thing I worked on, fortunately, so far seems likely to take far less time than was estimated, so I am optimistic. So far all I've seen on that page is table border rendering weirdness and that obnoxious bit of script.
-
As recent as 8 years ago their chips still required old school style emulators to debug
Some of their newish parts still require an external emulator such as the 12F683.
Although that's mostly to do with the fact that losing two I/O for debugging would make it almost pointless
I have a stack of ICEPIC and ICE2000 pods in one of my dev cupboards. I remember when we first got an emulator, it was like magic. Debugging by observing function, removing the part, UV erasing it, and reprogramming was painfully slow...
-
JavaScript is a scripting language. It was never designed specifically for the web, and many apps use it as originally intended.
Brendan Eich of Netscape coded JavaScript in 1995 during a ten-day drunken bender, solely so applets (a la Java) could grope around in web page content and vice versa. Microsoft cloned it in 1996 and happened to shove it into their "Active Scripting" cesspit, allowing it to be used like you claim it was intended, and Macromedia then got on the same bandwagon in Flash MX and Adobe in Acrobat 5. But its original design was specifically for the web.
-
Eich. The gay hater?
-
-
The scary part is "thousand years ago". As recent as 8 years ago their chips still required old school style emulators to debug....
I remember being excited when the 16F84 came out so I wouldn't have to put my chips in the UV box to erase them. As for debugging, I usually use the software emulator and extra pins connected to LEDs. Never considered ICD.
-
Some of their newish parts still require an external emulator such as the 12F683.
Although that's mostly to do with the fact that losing two I/O for debugging would make it almost pointless
I have a stack of ICEPIC and ICE2000 pods in one of my dev cupboards. I remember when we first got an emulator, it was like magic. Debugging by observing function, removing the part, UV erasing it, and reprogramming was painfully slow...
Yea....that's not an excuse for awful silicon. It's a $1 for christ sakes in bulk.(1k+) and that's coming from MC's own pricing table.
The ATTINY45/V from Atmel is cheaper in bulk significantly, same pin count, more memory, no loss of pins for debug or programming, sane architecture and in fact your assembly will be smaller from experience writing and dealing with both.
-
Yeah, as I said earlier in the thread we've moved to ST parts now. The cost reduction was just too large to ignore even though we were a PIC shop (apart from cases where we really needed more grunt than a dsPIC or PIC32 could provide).
I'm quite liking the STM8 parts. There are some things that Microchip did better but they are pretty nice parts on the whole.
Edit: By moved I mean we have actually redesigned current products rather than just using them on new designs. Our disties did try hard but we couldn't meet the required price points with Microchip. We have one multinational customer that requires a cost reduction each year...that is a WTF and very hard to manage!
-
We had a customer like that at one point until we created a nice graph of time invested into product cheapening it further vs. cost of product increasing as we increase R&D into it.
-
We have one multinational customer that requires a cost reduction each year...that is a WTF and very hard to manage!
What is it with people following in the footsteps of Madman Muntz? Do they not understand that that road leads to madness and angry customers junking your product to go buy somebody else's?
-
We had a customer like that at one point until we created a nice graph of time invested into product cheapening it further vs. cost of product increasing as we increase R&D into it.
That is an excellent idea, I'll suggest it to my boss.
What is it with people following in the footsteps of Madman Muntz? Do they not understand that that road leads to madness and angry customers junking your product to go buy somebody else's?
Thankfully that customer is effectively the end-user from our point of view as the equipment is leased to their customers who have no say in using it. And it's branded with their name not ours.
But yes, I hate having to reduce cost generally unless it's simply squeezing our distributers. I generally specify parts and suppliers because I know they provide repeatable quality etc.. Sure we can get the same, say, inductor produced in China by a no-name rather than from Coilcraft but suddenly half-way though the batch the ferrite grade might change (this actually happened).
-
-
@NTAuthority said:
Eich. The gay hater?
"Hater." Sure.
Hmm...I didn't even know he was gay.
-
by a no-name rather than from Coilcraft but suddenly half-way though the batch the ferrite grade might change (this actually happened).
Hahaha, we got bit by a Chinese manufacturer of battery cells coming in internally contaminated after a year.
Imaginary cost reductions are great. They also spend 2x more effort welding the fucking things because their metal casing is some cheap ass oxidized steel.
-
We have one multinational customer that requires a cost reduction each year...
The way to deal with that is to always deliver the smallest possible cost reduction to them that you can get away with, even if you could do more. Save some cost reductions for future years, possibly taking the difference between the real cost reduction and the one you're selling upstream as extra profit.
There's a system, so you can game it.
-
Yeah--good Wal-Mart suppliers know how to game the system too. They have almost the same rule, except that it's "items that don't change must drop the price." That's why, or so I assume, things like toothbrushes change styles constantly.
That policy may have changed since I read about it, too.
-
That's why, or so I assume, things like toothbrushes change styles constantly.
Planned obsolescence is probably more important, though Wal*Mart benefits either way.
-
Planned obsolescence is probably more important, though Wal*Mart benefits either way.
I'm not sure how the idea of planned obsolescence applies to consumable items..
-
A toothbrush doesn't have to be non-durable. Manufacturers constantly change their design "add features" with no measurable usefulness and change the cosmetic design. They want you on that upgrade treadmill...
-
A toothbrush doesn't have to be non-durable
Toothbrushes are inherently consumable: you're supposed to replace them after a few months. There's no point in making them any more durable than they need to be to last that long. If you wanted to argue semantics you could make a claim, I guess, for planned obsolescence actually being in use here, but I just don't think that the concept makes sense when you're talking about something with a short active life.
The whole reason the concept of planned obsolescence was such an affront is that it was applied to an item, cars, that are absolutely capable of being functional for decades with proper maintenance.
-
This sandwich is affected by planned obsolescence!
-
you're supposed to replace them after a few months.
As they are manufactured now, yes...
You're supposed to replace them when the bristles fray. If they don't fray, you don't need to replace the brush. Guess who's interested in having bristles that fray?
Certainly, manufacturers don't want them to last a year (a not so unreasonable length of time) when they can make 3-4 times as many sales by making them flimsy.
This is similar to the Phoebus cartel. Before the 1930's, lightbulb manufacturers competed on longevity. The average life of a bulb was about 3000 hours. The Phoebus cartel (G.E., Osram, Philips, and others) decided to "standardize" on a 1000 hour life. They even fined their members for lightbulbs that exceeded the expected life.
Also:
Planned obsolescence or built-in obsolescence[1] in industrial design is a policy of planning or designing a product with an artificially limited useful life, so it will become obsolete, that is, unfashionable or no longer functional after a certain period of time.
It doesn't matter if it's a durable good or a consumable good.
Planned obsolescence is exactly why some toothbrushes with replaceable heads have sealed battery compartments.
-
This sandwich is affected by planned obsolescence!
sigh
Ben. Ben. Ben, buddy, listen. Alfred E Neumann-style YOLO randomness is orthogonal to autism. Are you picking up what I'm laying down?
-
I'm using reductio ad absurdum on the idea of toothbrushes being planned-obsolete.
-
Sure you are!
-
I'm glad we are in agreement.
-
I am so glad that I am not the only one who hates this piece of shit compiler.
My boss seems to think PICs are the best thing ever whereas I just want to use something that actually fucking works, like something ARM or AVR based.
-
I am so glad that I am not the only one who hates this piece of shit compiler.
My boss seems to think PICs are the best thing ever whereas I just want to use something that actually fucking works, like something ARM or AVR based.
Reminds me. There was this old guy at the company that absolutely loved PICs. I mean he would probably sleep with PICs in his pants love. My god, he would go on rants like PICS HAVE THE MOST PERIPHERALS THAT ANY OTHER MICROS(lol, maybe in 1990s they did).
Or THEY HAVE THE LOWEST POWER. Nope.
Or THEY ARE THE CHEAPEST AND HAVE THE MOST PACKAGES. Nope bro, it's the 21st century.
He would rant and rave about the work he did on making PIC code "interrupt-safe", i.e. instead of a global struct, lets pass a pointer to it instead! (his excuse was you wouldnt know when it changed by interrupt....but that doesnt help...).
My god he loved his abominations of code. He made a smbus slave that had this ridiculous rigid state machine based on data instead of what should have been just a state machine based on hardware status. It was so full of WTFs and repeated code segments. But alas, "THE MICROCHIP GUYS AGREED THIS WAS THE BEST WAY TO DO IT". Yea....no.
He would sing the praises of the excellent PIC compilers and shut up and play dumb every time I brought up a new bug with the compiler to him.O god, there was this consultant that worked at the company. He worked on a x86 micro(old school) there but my god, the dude took a perfectly good RTOS system and proceeded to fuck it. He intermangled threads so bad there was no point in using an RTOS but its still there to this day. At some point we hired this elite consultant to help with a bug an engineer was having with a PIC.Me and another coworker already told management, it was a undocumented PIC hardware defect. But management couldn't accept their precious garbage was broken. The three embedded engineers pouring over the problem must not know what they are doing with PICs! Quick, hire the jackass consultant we love!
The consultant himself? He reviewed code, commented on useless shit he obviously had no experience. He complained about code style when his RTOS project had absolutely zero sense of the words "code style' meanwhile we actually ran uncrustify on our source.
Me and coworker finally setup a fucking test case right in front of the morons and said go fuck yourselfs.(Or close to it without saying it, heh)
-
Interestingly the most predictable (and probably least buggy) mode of the current PIC compiler set is the free mode - the one that does the fewest optimisations. That mode almost works.
I still prefer probably any other architecture because every commercial PIC compiler I have had the misfortune to touch totally and utterly sucks.
