|
... involves getting my hands on a Navistar T444E engine - Wikipedia[^] or similar late model "chipped" fuel injected diesel engine and hooking into the On-board diagnostics - Wikipedia[^] to see if i can't make a custom electronic dashboard for it by rigging it up to a Raspberry.
The main problem is finding a place to put the thing as I don't really have a workshop - and i have a carport, not a garage.
Eventually I'd even like to make a reprogrammable ECU for the flippin thing.
Why? To make a better boondocking rig[^] so me and my fellow freaks can caravan through the post-apocalypse wasteland in style and comfort.
Steve Wozniak is the only thing at Apple that isn't evil.
|
|
|
|
|
I'm hope you aware that the T444E has a pollution problem already... In the post-apocalypse scene there is already enough debris around, you not really want to add to it... 
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
For the post apocalypse you should probably look for something fully mechanic. I wouldn't trust electronics to survive the apocalypse.
|
|
|
|
|
Agreed.
I envision our apocalypse having a very good chance of having limited technology, such as an EMP or solar-event.
Now if the ECU and and semi-conductor based sensors were in a Faraday cage or similarly shielded; this may not be a problem.
Mechanical systems would still function naturally, and old school points/condenser ignitions should be good too.
Coincidentally.... just streamed E.M.P. 333 Days[^] a couple of days ago
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
The thing about those diesels, is its easy to rip the computer out of them. You basically just have to replace the injector with a manual injector, and then it's a non E version of the engine. The E was just a retrofit to begin with. =)
Steve Wozniak is the only thing at Apple that isn't evil.
|
|
|
|
|
Are you going to make it multi-fuel as well?
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
That would be ideal, but it's primarily a diesel. Diesels are pretty flexible in what fuel they'll let you use, but it will never run straight petrol.
Steve Wozniak is the only thing at Apple that isn't evil.
|
|
|
|
|
Exactly what I was referring to; a Compression Ignition engine that can run on fuels other than Diesel; e.g. Jet Fuel, Kerosene, recycled McDonald's deep-fryer oil.
As for your particular engine, I don't see anything in my parts list for the IHC 6.9/7.3 engines
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
There's another powerplant i could use that i know a bit about - it's an older line, international, but the name isn't coming to me. It's another retrofit in terms of electric injection.
They're both common in school buses.
I know the older one will run on fry oil. I'm pretty sure i could get this engine to do so as well.
I think the main problem might be in the high pressure injection rails but i think there are WVO kits for those.
Real programmers use butterflies
|
|
|
|
|
For post-apocalypse, perhaps an army surplus tank modified with bulletproof glass skylights would be in order. It might get 10 mph retrofitted with your engine.
|
|
|
|
|
Greg Utas wrote: It might get 10 mph retrofitted with your engine.
And less than 1 mile per gallon.
That might be a problem in a post-apocalypse world. Gas stations are likely to be few and far apart. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yes, so I guess it'd have to be wind, solar, and...biomass, of which there should be plenty!
|
|
|
|
|
Two apps. Notification settings for both are configured the same. When one app gets a "message," it's icon is overlapped with a number. When the other app gets a "message", it's icon is not overlapped with a number, yet you can open the app and see the new "message." It did not used to be this way (i.e., the overlapped number used to display for both). Any idea(s) as to what is going on here?
Thanks.
DC
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
modified 13-Jan-20 11:05am.
|
|
|
|
|
|
I'm not looking for code.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
But now you may understand that both apps are different in this handling?
Or are they the same apps (also in version) but different devices? Maybe different ios versions?
Please explain, if it doesnt help you. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
You have to pay for the newest phone to get this fix.
Steve Wozniak is the only thing at Apple that isn't evil.
|
|
|
|
|
That isnt true. Even the 5s got the lastet update. Compare that with android phone from this age
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
The parallax is hiding it, so you must be holding it wrong.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Question for iPhone users, why?
|
|
|
|
|
Greg Utas in particular, you may find this of interest. Sorry I forgot how to tag. Someone explained it once.
To recap, Slang is a subset of C# that is CodeDOM compliant. It's maybe 60-70% of the language.
So I originally was parsing Slang by hand.
I wrote the Parsley parser generator so I could write a grammar and generate a parser to parse Slang that way instead.
My generated parser was 939k vs about 100k for my initial hand rolled parser, and was about twice as slow, and took at least twice as much memory to execute, by my back of the napkin estimations. Still, it was fine for this scenario.
The trouble is, and Greg, as per our earlier exchanges, you may want to know this - the out of band "preprocessor directives" and comments - skipping them entirely is easy, but conditionally ignoring them is much more challenging for the generated parser.
In the end, I couldn't make the generated parser handle it. I tried skip lists and it didn't work, as it was eating trailings - I'm going to write an article that covers this in detail. Greg I think it's not feasible. You need an explicit preproc step.
In the end I decided to go back to a hand written parsing method, but I still had the problem of maintenance and intelligibility.
Well, fortunately, I have this generated parser with a grammar that goes with it. So I added a /noparser option to Parsley which goes through all the steps of processing the grammar, and generating any associated lexers and constants, but skips the actual parser generation.
Now I'm coding by hand, but to the grammar I made before which makes it much easier to understand where i am and what I'm doing.
I'm testing my parser *against the generated parser* woo! which really helps.
And so there it is. I've mitigated some of my hand rolled headaches by generating a parser even though I won't use that parser in production.
And I think Parsley won me a prize here so it isn't a failure scenario at all.
Greg, you might want to consider this approach in building your parsers, as having your grammar in front of you in a BNF variant form plus making that available as documentation can really help both you and whomever uses your parser.
Plus definitely using a lexer would cut your effort and make your error handling more robust, i pretty much guarantee you - that's why almost everyone does it. 
Anyway, yay Parsley, even though I didn't use it for production code.
hack everything.
|
|
|
|
|
I was about to pack it in for the night when I saw this. I don't know how to alert someone on these boards either, so that makes two of us.
Much like you do with C#, I parse the subset of C++ that I use. I don't know much about C#, but are you actually saying that a new language kept this preprocessor excrement? The first thing that comes to mind is Monty Python and finding a dull spoon to geld those who were responsible.
My problem is twofold. First, I don't know where to get the BNF for C++. I'm sure it exists, but it must be worse than a dog's breakfast. Second, I "interpret" the code after parsing it. It's the only way to support some of the "Scott Myers code inspection" capabilities. So if I went with a generated parser, I'd have to modify generated code to support the interpreter phase. From the bloat that you've described, I'll pass.
With regard to the preprocessor, I support some things in my single-pass compiler, and a few other things should be added. But it's exactly as you say: to support all of it, a true preprocessor phase is needed. But I have no intention of supporting all of it. If someone else is willing, great. But there are some things that I find repugnant and won't countenance: stringification (#), concatenation (##), function macros, and code fragment aliases. If someone wants to use the tool but their code contains these things, they'd have to rework them, and I'd be doing the world a favor. Another one is #undef, which is tricky when all the code is compiled together, without any notion of "translation units". It could probably be supported, but would it be worth it?
Another reason I don't want a preprocessing phase is that I have an editor that can interactively fix about half of those Scott Myers recommendations. With a preprocessor phase, you get two versions of the code. There's probably a way to deal with this, but my initial reaction is, "Will the real source code please stand up!"
I wonder if a generated lexer would help. Mine isn't very large and was repeatedly refactored to keep the parser code tight. The debug version of my "compiler" is about the same speed as MSFT's real compiler, so I'm not losing sleep. Of course, it's not a true apples-to-apples comparison, but it does what it needs to do.
|
|
|
|
|
Greg Utas wrote: ut it's exactly as you say: to support all of it, a true preprocessor phase is needed. But I have no intention of supporting all of it. If someone else is willing, great.
That's exactly my situation. I needed to support some of it.
C# is light on preprocessor stuff at least. There's only a few directives, and one of them merely provides source code formatting (you can collapse #region/#endregion blocks in the source editor)
I'm not suggesting you go the preprocessor route so much as warning about picking up comments in a generated parser if you do not.
I agree with you in your situation about the generated parser. The thing is, I didn't end up using one either in the end. But I *am* using a generated lexer, which keeps my parser code simpler.
I am suggesting that creating some BNF for your C++ subset might not be such a bad thing.
Unlike C#, there's a ton of grammars online for C++ Comp 11 C++ Grammar[^]
hack everything.
|
|
|
|
|
honey the codewitch wrote: whomever uses your parser
My Markely parser rejects this as unknown syntax.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
*files a bug*
Steve Wozniak is the only thing at Apple that isn't evil.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
