I would love to work at the places you have been where you are given enough time to throw out the prototype and do it properly. In my almost 20 years of professional experience this has never been the case and prototype and exploratory code has only been given minimal polishing time before reaching production and in use state.
We are all too well aware of the tragedy that is modern software engineering lol. Sadly I too have never seen that situation where I was given enough time to do the requisite multiple passes for proper design...
I have been reprimanded and tediously spent collectively combing over said quick prototype code for far longer than the time originally provided to work on it though, as a proof of my incompetence! Does that count?
This is neat, but how does this get away with being zero allocation? It appears to use `Func<T,U>` for its predicates, and since `Func<T>` is a reference type this will allocate. The IL definitely generates definitely seems like it's forming a reference type from what I can tell.
The JIT can optimize this. I know for sure if there's no captures in the lambda it won't allocate. It's likely also smart enough to recognize when a function parameter doesn't have its lifetime extended past the caller's, which is a case where it would also be possible to not allocate.
Also, I would point out that there are cases where it doesn't change significant amount of the language or hamper things.
The transpiler also works for Linux eBPF kernel side applications without unsafe pointers and other odd things I need to do for SNES.
Since you can have methods on c# struct instances, things can still work pretty idiomatically.
You also do have statically sized arrays, or heap allocated arrays (the latter is only supported if host C application passes it in before hand, and is responsible for free ing it).
It's not clear that Fable would fit the constraints, especially since F# heavily relies on reference types for discriminated unions and lots of other features. It's possible that Fable wouldn't be able to compile down to lower end embedded platforms, or even things like Linux eBPF applications (like my transpiler can do).
You can for some features tag the type with a [<Struct>] attribute and it will compile down to a struct/value type representation. That includes records, DUs, active patterns, etc.
In theory, allocation could be hacked in with an arena allocator. I just need to add in reference type support and custom allocation strategies into the transpiler.
Then again, that's only viable if you don't use enough memory to require rom bank switching, or have better control over which class gets placed in which rom bank.
Strings become `char*` so they are supported as long as they are not dynamically generated (no concatenation for example, but some things like `printf()` templates do work.
One thing it potentially buys you (besides things mentioned in other posts) is faster iteration cycles.
The C stubbed methods can potentially be populated with logic that sets up a fake SNES logic in it, and makes calls to a custom rendering and input handling (monogame calls for example).
This means you can test a bunch of your logic in a monogame app for easier logic debugging, then use the transpiler to test it on a real system.
I might need to play with this; I have been looking for an excuse to play with the retro console homebrew scene, this seems like as good an excuse as any.
Feel free to write up any issues in the repo if you encounter them. It's likely to encounter MSIL opcodes that my transpiler is missing support for.
Also the pvsneslib docs will probably be crucial for working with the SNES in general.
The Maven 2 SNES emulator was pretty useful for debugging. If you are on windows there's also a no$sns emulator that pvsnseslib has console message support for debugging.
I'm not going to promise it's a super polished effort in its current state :)
When I started this journey I had a hard time figuring out how open source il2cpp actually was, and it seemed to be heavily tied to unity. All the docs seemed heavily geared towards unity usage as well.
Likewise, some of my long term goals with the project involve writing code that can run on low end embedded platforms that may not have the C++ standard library available to it. So I had two main goals:
1. Create a system where C# could be run on very low end systems (esp32, arduino, etc...)
2. Allow the C# code to be easily referenced in a non-C# project for platforms that don't allow it.
So I ended up making my own system, as il2cpp and others didn't quite fit some of these bills. I targetted C to make sure that any C compiler could be used, so if an embedded platform has a custom gcc based compiler it could still be used (I think that's the case with the compiler that PVSnesLib uses for its `tcc` compiler).
Author here, yes I am on an insane quest to get C# to run anywhere and SNES was just a random side tangent to that :D.
So the code in the game example is very much a "port directly from the example C code to make sure it's possible and it works". The next step was to start looking at where things can be made more idiomatic.
For example, C# supports static methods in interfaces now. This means instead of passing function pointers around for things you can create a class that implements an interface and call `InitObjects<T>()` instead of `InitObjects(&initFunction, &updateFunction, null)`, and I think I can do that in a no overhead way.
There are some other ideas I have for making things more idiomatic, but I really wanted to make sure I had a working ROM first before I started mangling the examples and trying to figure out if it's my transpiler or my logic that's breaking things.
There is a limit to how idiomatic I can make it though. Since the SNES has limited memory, any stack variable you create risks accidentally overwriting other memory. So it seems like you want to limit how many stack variables you use, which ends up meaning storing things in pointers and globals when using them.
There are some other slight advantages, like better enums, but yeah. At the end of the day this is a usecase of my transpiler allowing C# to be used on non-standard platforms.
If 'T' is a struct, yup, although that's specific to the way it is compiled by CoreCLR's JIT or ILC.
For constructor semantics it's best to expose a static abstract interface method Create<T> and have the interface be SomeInterface<Self> where Self : ISomeInterface<Self>.
For example, that's how `INumber<T>` interface works so you can further down the line write `T.Zero`.
Electrical charging on the road is expensive, because those are fast chargers, and not normal chargers a home would have.
A ~7kw charger you'd install in a home or a business has is relatively cheap wiring electrically, and the stalls are not that expensive.
Rivian adventure network uses chargers that have to output 220kw into the car. This requires significantly higher cost for getting electricity to each stall, the stall needs to be able to handle that much power transfer, and they must be actively cooled (since that much power causes a significant amount of heat). They also require a decent amount of maintenance.
These stalls can cost upwards of $100k per stall for installation.
This is all done so you can charge in ~20 minutes (as opposed to several hours it would take at a normal 7kwh one).
That's why fast chargers cost significantly more. They also need higher profit margins to make back the installation and maintenance cost depending on utilization rates they expect, otherwise installing these chargers doesn't make a lot of sense for businesses.
It also likely gives you cancer over time. It likely also gives the rest of us cancer, asthma, and a number of other health conditions. It also poisons our water and air.
You also must charge at a station, whereas electric vehicles can be charged at home, so this 20 minute charging situation is generally exceptional, whereas you having to drive to a station to fill up is a requirement.
I know this isn't usual for most people but it's fairly common for adventure vehicles to carry extra gas with them. I have a fuel bottle I'll take on my motorcycle if I know I'm going to be out in the sticks for a while, Jeeps/off roaders will carry jerry cans/rotopax, etc.
No one is saying _you must use an EV_ if your use-case doesn't fit. That doesn't change the fact that most people aren't you. I've for example never brought around extra gas.
The goal is to have most cars shifted over to EV as they fit the common uses-cases, and to eventually expand to the abnormal use-cases.
No, you do not have to refill at a station. What a ridiculous thing to even attempt to say.
The whole point of the comment was that you can refill anywhere. In the absolute middle of nowhere. Because "you can carry 100 miles of range in a pail"
You can carry gas any way that you would carry water. You can walk and carry 1-3 gallons of gas and it only weighs a few pounds to get 30-100 miles of range in a modestly inefficient car that only gets 30 mpg, forget a hybrid that gets 50mpg. It takes hundreds of pounds and idk how many cubic feet of battery to give 30-100 miles of range.
As for needing the infrastructure to produce the gas, well, A, you need equivalent infrastructure to create solar panels and copper wire, and B, you can brew various forms of deisel and alcohol from anything that grows with no infrastructure if you really had to. There are various low-tech ways to make electricity too, though you still need at least good wire which will be hard to make in a bathtub, but let's grant the wire just to be generous, so I think the whole "needing a station" is a wash on all points except the fact that there is no electric equivalent of how practical the fuel itself is to handle and transport. The closest might be, if you had extra solar panels, instead of walking however many miles to some other tank, you could sit and wait a day and get about 30 miles from solar in a day, assuming the vehicle is not in shade. .. even when I try to steel-man the other argument, it's still full of caveats for requirements and limitations that gas does not have.
And you don't lose ANY in the transfer while pouring the gas from one tank to another. You lose a lot while using one battery to charge another, or when doing any form of transmission or conversion at all.
And the tools and materials you need to accomplish the transfer are nothing. No exotic cabling to handle crazy amps without overheating, no computers to negotiate and monitor, nothing.
And for all that energy packed into that gas, it's almost as safe as an equal pail of water. It isn't trying desperately to explode itself at all times only held back by undamaged films. You can throw a lit cigarrette right into a pail of gas and it just puts the cigarette out. If you spill the gas and create an area of dangerous fumes that would be easy to ignite, that danger actually dissipates in a few minutes all by itself as the gas evaporates to nothing.
There is no comparison in utility.
The advantages of electric are obvious and can not be denied. But there simply are also serious disadvantages that have not yet found any even remotely reasonable answer.
My dude. No one in their sane mind is making their own gasoline. Like, I can get the idea that some folks want to bring extra fuel around with them for off-roading, but you're talking extreme off-the-grid use-cases and no one cares about that. Keep your gas if you're going to do that. You're in such an ultra minority that it doesn't matter if you use EVs or not.
We're talking about normal use-cases here. Like, my car is in my house attached to my wall socket vs needing to take 15 minutes out of your commute to go to a gas station. Most EV owners can avoid going to a "station" completely, for their day-to-day use, and for road trips may need to go to one once or twice, ideally charging while they eat.
> No one in their sane mind is making their own gasoline.
In your apparently limited experience.
First time I met someone cleaning biodiesel at their home was back in 1980 and since then I've met such people at least once a year or so, particularly in the off road and farming communities.
It's a neat saving for bulk fuel users to collect waste cooking oils from resturants, chip shops, etc and filter, centrifuge, tap, clean and blend into 44 gallon drums for later use.
It's entirely sane to make a bit of cash taking people's waste and saving on fuel purchases by blending in.
It's still the absolute minority of people, and they can continue using biodiesel for their cases. No one is going to force them to switch, and it doesn't change the fact that nearly all people who use gas need to go to a station.
It's a minority of people that launch unicorn startups, it's a minority of people that fill 10 acres with graded rock and soil for construction sales, own second hand bobcats and excavators, make money collecting oil waste, and reduce costs by blending.
> They also need higher profit margins to make back the installation and maintenance cost depending on utilization rates they expect, otherwise installing these chargers doesn't make a lot of sense for businesses.
While I respect the right of the business to make its own decisions about what the payback time ought to be, I'd also guess that other than replacing the very cheap jack/socket and the payment tablet, these devices will last decades. The only reason they need high profit margins is a desire for a short payback time, much, much shorter than the likely life of the device.
Given the fact that the other plug is basically the standard at this point and the fact that Rivan's doing the "Rivan Adventure Network" for Rivan vehicles, what's the usage? If they're only getting used 10% of the time, some back of the envelope math says charging $0.61 per kWh is the five year to payback timeline.
What's an acceptable timeline to RoI for you that a business owner is allowed to have?
From my POV, if a business owner buys a piece of equipment that can entirely reasonably be expected to last 20 years, the timeline for ROI is on the order of 20 years. Maybe 10, maybe 15.
But I'm not insisting that this a hard and fast rule; rather, I'm suggesting that "a 5 year ROI" is also not a hard and fast rule.
Is there anything resembling a guarantee Rivan will be around in twenty years? Not just a "yeah probably", but something solid that would make you feel good about placing a $100k+ bet on them being around?
That's completely missing the point they're making, they weren't calling out Rivian as different to competitors it was just an example brand for the discussion of what timeline is reasonable to plan over.
and (some) people wonder why (other) people think that charging infrastructure should be either (a) standardized to be manufacturer neutral (b) publically owned or (c) both.
Normally a long payback time is fine, but I would expect that in ~5 years, faster charging will be prevalent and the current chargers will already be obsolete, or at least less popular.
But shouldn't these fast chargers be doing much more "volume" of charges on a per-hour basis? I.e., if they can pump 3x the kWh shouldn't that somewhat alleviate the need to charge more per kWh?
No, for most people who own an electric car, its cheaper (ex. charging at off-peak, and slower) and more convenient to charge at home. I only use those super chargers on road trips which isn't my normal commute.
It might not have been slowing down much in that time due to a thing called Ground Effect. Since the wheels weren't down, the flat body of the bottom of the aircraft + wings would have actually reduced drag and cushioned the plane for a bit, causing it to not slow down as much as you would assume.
