0dyl
This is bit on info-dump. I’m not the best at expressing myself and so some parts may not be clear. Please feel free to ask for clarification or any further questions.
Pattern matching is available as a language extension (currently) exclusive to GNAT GCC. It’s not in the reference manual, which means it’s not part of standardised Ada (yet). It’s intended to be an experiment or prototype for what will eventually become a standardised language feature (the standardised feature may be different, or it could be rejected, as the standardisation committee is composed of multiple compiler vendors).
As is, that pattern matching feature works in both normal Ada and in SPARK mode on GNAT GCC 15.2. The flag to enable it is “-gnatX0”. Please see these: https://godbolt.org/z/d55ddznfn https://gcc.gnu.org/onlinedocs/gnat_rm/Case-pattern-matching... https://gcc.gnu.org/onlinedocs/gcc-15.1.0/gnat_rm/How-to-act... In the Godbolt example, that is in normal Ada.
You are not alone in finding the Ada community difficult to navigate. The “ada-spark-rfcs” repository you linked is a community outreach program of AdaCore to solicit feedback from programmers in venues they’re more likely to use. Those RFCs are then forwarded to the Ada Rapporteurs Group (ARG) who focus on the development of standardised Ada. Their issues, mailing list and meeting minutes can be found at: http://www.ada-auth.org/arg.html
SPARK doesn’t add features to Ada; instead, it’s a subset of features that can be easily proven by SMTs for formal verification. The special things in SPARK (extra attributes and pragmas, which Ada implementations are allowed to define) are only to aid formal verification. When language features are added, they’re added to Ada first and subsequently potentially enabled in SPARK.
I admit that calling it “ada-spark-rfcs” is kinda confusing - it’s just dumping ground for ideas for Ada and SPARK. For example, the multiple ghost levels RFC really only applies to SPARK, as ghost code only exists to improve verifiability. The final modifier RFC is for Ada proper, and it’ll probably apply to SPARK as it allows OOP.
The situation regarding compiler available is confusing and it made me nervous when I was first learning about the language.
GNAT GCC has two versions: FSF and PRO. The FSF (as in the Free Software Foundation) version is the publicly available version that’s in mainline GCC. PRO is for paying customers of AdaCore. From what I can tell, it’s built against an older version of the GCC backend. It tends to get those newest experimental features sooner, but they do trickle into FSF GCC. There have been points in time where I haven’t noticed any difference in feature set between GNAT PRO (according to the release notes) and those in FSF.
SPARK code works with both GNAT FSF and GNAT PRO. The formal verification tool for SPARK, GNATprove, is open source. https://github.com/AdaCore/spark2014
Have a great day. :)
Edit: I’m not affiliated with AdaCore. I’ve never even spoken to one of their employees on the forums. I do use Ada, but only in my “side-business” (not making any money yet lol).
What on earth are you on about? That’s not the case.
Ada 2022 has been released and Ada 202x is getting improvements. Those features are trickling into FSF GNAT (GCC).
Are you talking about the SPARK dialect, where GNATprove is open source?
That's perhaps not the best wording.
Nonetheless, I do agree with you. D can be very flexible in that regard.
The approval I got from the engineer was due to the following points:
1. The 6 speed came out of a newer generation of the model.
2. My controller has some safety features.
3. My controller emulates factory hydraulic behaviour. Had I implemented something like a transbrake, I would have been in for a very long ride of red tape.
I love CAN bus (for my own designs), but I don't see the effort of attempting to reverse engineer GM's format as worth it, especially since I had no prior experience with CAN.
Thank you :) I've got another D automotive project which I hope to write about soon.
I agree, the syntax is much clearer than C++. The very first prototype was in C++, but I found myself frequently frustrated with the language. I find D's features make me more productive.
1. My apologies, I've confused you. CAN communications are purely internal for my system, it doesn't communicate via CAN to the car's computers.
The sensors and actuators give or accept voltage signals, and my controller inputs or outputs those accordingly. For example, the 4 speed has some pressure sensors to monitor the valve body behaviour, and I send some HI or LO voltage signals in emulation of it.
2. I do use FreeRTOS for the 407. I don't need to, since I use a super loop and all my memory is either static or allocated on the stack.
2. I'd like to introduce you to "manualisation" [0]. It's where the solenoids of the 4 speed are wired directly to the gear selector switch. The 4 speed computer is surprisingly tolerant of this, and it forms the basis of my interface.
My interface provides enough information to the 4 speed computer to stop it from erroring out or putting my car into limp mode. However, it is aware that something has changed because changes in engine RPM do not correlate with its shift commands.
3. I mean in terms of software. I can modify the behaviour of my box more than a standard tune can. I can add a 0-100KM/h tracker to my system, or shift lights, I can fundamentally change the decision making process in shifting (for the moment it's torque based), etc.
I could go out on a limb and a GPS module and a map; it'd select a gear based on the corner angle and speed or so.
Thank you for kind words :) If you have any other questions, ask away!
I spend a tonne of time in the reference manual for the 6 speed, and things clicked for what my next steps should be. It was really about trying to familiarise myself with the problem as much as possible.
I have a manual license, but I'm not interested in them. Thanks for the suggestion anyway.
But yeah, the 4L60es are lemons in my eyes.
Keep in mind, with the 4 speeds I drove casually. With this 6 speed, I can push it hard and it's still going strong almost a year later.
They're quite an old (American) design bolted to a modern engine. It simply doesn't mix well. 4 speeds (4L60e) are the bread and butter of automatic transmission rebuilders in Australia.
My father killed one in his daily driver, and all it did was go 20km each way to and from work. My Aunt's Commodore was recently in the shop getting a new 4L60e. They're simply not suited to the car.
I contacted a VicRoads certified engineer in regards to the project and got the all clear.
Even my insurance was OK with it.
I think it's because most of the legislation is aimed at engine modifications.
Different situation, but I do admit when I first got into D I was wary of the UFCS feature and I avoided it, too.
Over time it felt a bit more natural and I began to appreciate it.
Sorry, no. I don't have a blog or website or anything. The closest thing I have to a devlog are some posts in a private Facebook group dedicated to the Holden Commodore.
I think this project is almost 12 months old now.
Injector width / time pretty much means the same thing (at least in my code base). My apologies for the confusion.
I have to go to bed, I have work in about 4 hours, so I'll reply when I can.
It is. I contacted a VicRoads approved engineer in regards to this project, and I received the all clear. I've been pulled over by cops, and they were cool with it.
My insurance is ok with it, too.
It does have a software watchdog, and failing that, the gearbox's hydraulics have a safety mechanism that allows for some limited driving.