If I create a view of a table containing JSON data (or any other kind of data), I can create columns from calculations on existing fields.
I'm guessing the advantage of generated columns is that they are real columns, not computed columns like in a view. This means that if an insert doesn't work with the new generated column an error will be generated? Is that a correct understanding ?
Is this perhaps the main advantage of this feature ?
The data creation and storage options, always computed or stored on write of dependant columns seems like a possible advantage too.
Main practical difference is that you can put index on generated column, and on view you cannot, SQLite has no materialized views. Constraint part you understood right, NOT NULL on generated column fails at insert, and note that VIRTUAL costs nothing on disk but can still be indexed, so STORED is mostly for when expression itself is expensive.
He has some great videos. I watched this one and was impressed at the calculations, the transparency and the celebration at the end when he reached supersonic speeds.
You could run C that way... but scScript is a scripting language using C-like syntax with features designed for scripting. For example, it provides dual variadic parameter/arg lists. Turns out having "in" (pass-by-val) and "out" (pass-by-ref) parameters are more pleasant (at least to me) than trying to return N values out of a function (especially since script languages run away from pointers). Perhaps it is a testament to my ignorance, but I am not aware of another language that does this.
The difficulty in designing a language is not so much implementing a compiler, but the iterative process of implementing and fine-tuning a given aesthetic... a given flavor as it were and it has to work well. Of course the other side is testing the damn thing... so my hats off to QA!
Nevertheless, I am sure good tool users could save a lot of time instead of hand implementing everything, as I would. So thumbs up to LLVM.
No (scripting) language with 2 parameter lists, the second all Var (to use the Pascal syntax). I could have included a Var keyword instead to differentiate, but a) that would complicate the variadic nature of scScript parameter lists and b) didn't quite look C-like to my eyes. (Then again I also have two Map functions in there for arrays and dicts.... so I should not claim purity.) (Yes, I stole them from LISP :-)
Then, there is the CH32v303 https://www.wch-ic.com/products/CH32V303.html, which is the lower end of the chips that support minimal floating point and USB host/client. These ones are a bit more pricey, https://www.lcsc.com/product-detail/C5456849.html at $US1.72 each. The extra price is QFP64 (64 pins, quad flat pack) and more features on the chip, USB, CAN, V4F extension giving one instruction multiply and some floating point operations.
Note that the fact that this chip uses an extension, V4F, for floating point (I think?) is part of the argument of Dmitry's piece on the RISC-V. The chip is pretty low price for a fair bit of power.
I feel like the Raspberry Pi products are inherently a special case.
They're probably produced in far greater numbers than most off-the-shelf STM32 or CH32V chips. You've got a huge ready market in hobbyist/educational products as well as the commercial products that have used it as a convenient choice.
There's that whole non-profit/educational heritage around them that likely selects for a different set of defaults and features than, say, a MCU designed specifically to be the controller for a SATA SSD or a $19 Roku clone.
They also have a small product range, as compared to the broad product matrix a lot of the more "commercial brand" MCUs come in. I know even the CH32v30x chips come in several variations multiplied by several package options (which vary enough to impact the features you can realistically use on them).
> They're probably produced in far greater numbers than most off-the-shelf STM32 or CH32V chips.
I highly doubt it. The RP2xxx lacks the built-in functionality for use in, say, a car, and it isn't cheap and fully-integrated enough for dime-a-dozen gadget application. They are great for hobbyists due to their low barrier to entry, but there really isn't a niche they serve when it comes to mass-produced electronics.
> They are great for hobbyists due to their low barrier to entry, but there really isn't a niche they serve when it comes to mass-produced electronics.
This.
Just programming a microcontroller is generally a pain, but a pain that hardware manufacturers can deal with, because they have employees with experience, who can read the long datasheets, get proper programmers and run the manufacturers software packages to program everything.
For hobbyists, you're basically limited to arduinos, esp??/??, and rpi picos, only those are guaranteed to have a lot of software support, documentation, easy availability on aliexpress etc. for cheap, and can be made to actually do some stuff in an afternoon of tinkering.
(technically it's the same with proper RPis, where they're the only SBC board (not x86 baed) that you're guaranteed will have at least some software support after 5+ years).
> technically it's the same with proper RPis, where they're the only SBC board (not x86 baed) that you're guaranteed will have at least some software support after 5+ years
This isn't quite true, though it's true at the RPi's price point. For example, Toradex (disclosure: I work for Toradex) produces the colibri-imx6 system-on-module that can be turned into an SBC with a stock carrier board. It was introduced in 2014, continues to be supported today, and will continue to be supported until 2036. But that level of long-term support and maintenance costs money, and the pricing reflects that.
This is often a gilded cage. Think about it. On one hand Great, you dont have to redesign your SBC, that would take whole ~1-2 engineering man months (small simple SBC at not bureaucratic nightmare small to middle size company, obviously man hours go thru the window at big many cook orgs). On the other hand you keep shipping SLOW AS ASS SBC to your customers while Chinese competition keeps redesigning _every year_ and offers smoother UI experience with more features for less money.
The real thing manufactures do is ensure that the SBC is available as long as they want it. My company started an embedded controller 6 years ago, at that time we got a contract from manufactures that all the parts would be available for 12 years, thus ensuring we won't have to redo that controller for 3-4 more years (and we might just renew the contracts). As a hobbyist you don't have that guarantee (except the 3 you named) it happens all too often you buy something only to discover not enough other hobbyists have the same board to give it a critical mass of people to make it work. It can still work, but you will personally have to do all the work to make it keep running which few hobbyists have the time/energy for (and often the deep technical knowledge is lacking as well)
A big part of the numbers game is on variants though. There's what, eight or ten total RP2040/2350/2354 parts to choose from? So all the volume is split between those.
Conversely, there are a lot more variations within other MCU lineups. Just looking at the WCH CH32v30x datasheet-- a single relatively low-popularity range from a single vendor, the datasheet shows 9 basic models with five different physical form factors, and there are theoretically different SKUs for different temperature ranges, etc.
And on the RP2354 you can swap one or both ARM cores for RISC-V cores at boot.
I think the CH32v303's single V4F core might be slightly more capable than the Hazard 3 cores RISC-V cores (as it has a hardware FPU), but for everything else the RP2354 is probably better (and the ARM cores do have hardware FPUs)
The "much more capable" is debatable. The RP2000 series is quite disappointing IO-wise: no timers, barely any ADC, no touch sensors, no CAN, bare minimum of USART/I2C/SPI, no I2S, no I3C, no ethernet, no USB PD...
And yeah, it has its PIO modules, but those aren't powerful enough to make up for it. They are fine as an alternative to bitbanging Neopixels, but you can't rely on some hobbyist's vibe-coded weekend PIO project which takes up all the PIO slices and 30% of one core to do application-critical communications.
I would take an RP2000 in a heartbeat for most of my hobbyist products, but for anything professional an STM32 is orders of magnitudes better, and even a CH32v303 looks like a more attractive option at first glance.
With missteps and imperial arrogance in Iran and Ukraine, perhaps the world might not be counting on the US as much militarily either?
"An army marches on its stomach"... If things at most soldiers homes aren't as good as they could easily be (financial prospects, opportunities..), maybe they don't have the same drive to fight with the same vision and discipline as they used to? I hope they will employ good vision and discipline.
I've always been very interested in the developments that occurred in WW2. I think The "Battle of the Beams" is one development that gave us the basis for what we use so much now in general aviation.
The BBC series "The Secret War" is a fantastic series that pulls apart how these discoveries were made. It has a lovely 1970s vibe to it and is very well narrated.
Interesting to realise that the cavity magnetron, providing higher resolution radar, was invented by the British and gifted to the United States. I believe the Germans researched it, but decided it was impossible. Please correct me if I'm wrong on this though.
If you watch "Greyhound", the tools that sunk the U-boats were British inventions, hedgehog and ASDIC. HuffDuff (High Frequency Direction Finding) is mentioned I think in the movie? It was made by a Polish engineer working for the British. Amazing that the Kriegsmarine didn't work out that their mandatory reporting schedule was sinking their U boats. With such a collection of defenses combined with doctrine changes for attacking U boat swarms, no wonder the U-Boat losses became so huge.
WW2 changed the world and brought us forward so much in terms of technology. Fascinating stuff.
It's a great place to explore the physics of it all, since the tools used were sometimes elementary (X-Ray machines to baffle direction beams).
Reginald Jones changed the world. Thanks hi_hi for the links.
The BBC "Secret War" series and RV Jones' books are superb. I would recommend also reading his "Reflections on Intelligence" - it was written later and is slightly more philosophical. By that time Jones had been burned by bureaucrats - he compares his small efficient wartime office to the post-war bloat.
The BBC series is really good. They don't make documentaries like that anymore. The "Still Secret" episode on Enigma is easily the best coverage of how the system worked, was cracked and the organisation behind it. There is also an accompanying book, which has many more details.
>I think The "Battle of the Beams" is one development that gave us the basis for what we use so much now in general aviation.
Actually it started the other way around. The beams were based on pre-war blind landing Lorentz system.
Ah, thanks. As I think about it, you're right. There was a Lorentz landing system in bombers that was far too accurate for just landing. Intelligence gathering extracted that from the crew's conversations. That was how they hid their direction finding... But the system already existed.
I think I got confused with radar, but radar isn't beams as such.
It is amazing how war accelerates technology development. Radar and the Manhattan project are cases in point, probably squashing 20 years of normal research into 3. Drones in Ukraine are a contemporary example.
However, when the war is over, things stagnate: The UK bombed the Falklands in 1982 with a radar which was essentially an upgraded wartime H2S/H2X set.
I have not seen these documentaries before. Indeed I had not seen video footage of RV Jones before. As a lifelong hero of mine, I’m looking forward to watching these in their entirety.
I’m currently in the process of reading Churchills autobiographies. While quite heavy, he writes with such clarity and knowledge. It’s a great account of how WW2 came about, and articulates how easily it could have been avoided if only a few people in positions of power had made different choices.
How different our world and technology could be if not for those terrible circumstances of war.
RV Jones was pretty incredible. From the interviews you get a bit of a picture of his initial attempts at getting his points across. He was persistent and knowledgeable.
Indeed, it's a shame that war brought us so many advances...
Somebody, either Buderi or Rhodes has the magnetron appearing in the MIT Radar labs and somebody saying "oh, thats obvious" and being asked "ok smartass, how does it work then..."
Sometimes, simple things are obvious in hindsight.
G'day Mattheus,
Was fun to see some of the things I find fascinating causing fascination in others. I'm a bit of a Common Lisp tragic and I also love the APE setup and using llava files to run local LLMs.... Even on tragically old servers!
Hope things go well. Thanks for doing the interview. I'll look into Lone Lisp.
Cheers
Yeah, jart's cosmopolitan is awesome. I've even sent some floating point code her way!
I have my own take on the "embed data into the executable" problem too. It's the one thing I've made that I think is truly novel. I developed a tool to copy the data into the ELF in such a way that Linux mmaps it in automatically. Lone can just reach it at runtime via the auxiliary vector. No need to read /proc/self/exe.
The ELF editor is written in C right now. I'm getting the language ready to host it as a lone application. That'll make it easy to redesign this feature and develop even more high level features on top of the code loading.
Really enjoyed the interview, and love the ideas behind Lone Lisp. I was curious, does it run on jart's Blink project, the tiny x86-64-linux emulator? https://github.com/jart/blink/
It failed to load an interpreter with a lone-embedded lisp program though. Rejected it as an invalid ELF because of a bug in my ELF editor.
The embedded segments my tool generates are page aligned and end up extending past the end of the file. Linux doesn't care, it mmaps those non-existent file regions just fine as zero filled pages. Blink rejects the ELF as invalid instead.
I'd say blink's behavior is correct but divergent from the Linux it's supposed to be emulating. Created issue #215 about it:
Very cool! I'm learning a lot from studying how Lone Lisp works, and will be exploring how to run it on Blink, which is itself a lovely educational project. Someone managed to port the latter to WebAssembly, so eventually I'd like to experiment with that too, not only for running in the browser but as a cross-platform (or platform agnostic) layer maybe. https://github.com/robalb/x86-64-playground
Anyway, looking forward to following Lone's progress. The technical details in the interview and in the articles on your site are so interesting, somewhat over my head but that's exactly the kind of material that I enjoy learning from. (:
I'd really like it if the United States could very soon get rid of or at the very least eventually vote out Donald Trump.
The Nature article points to the MOF Nobel prize winner going to China. I gather this is because science is getting defunded in the US? I think defunding science shows an incredibly short term view and damages the future for the world, starting with America.
I know there are problems with the US democracy that have been in play for decades. There is inequality, there is racism and religious bias... I think throwing out the entire system that largely worked doesn't solve these problems and in fact makes the future worse for our kids. The video above argues that the damage done now to universities will be noticeable in decades time. Even doing a large funding push to universities may not fully repair the damage being done now.
The US is not a perfect place nor a perfect actor, but when governed reasonably I think it is better than China in terms of its aims, philosophies and interactions. Hopefully his work done in China will be shared globally.
I heard an interview with him this morning, where he's already in China. Some of his stated reasons for the move (also listed in the articles below) include the slashed research funding in the USA, increasing restrictions on research and international collaborations, as well as wanting a stronger push for the AI revolution in science.
That might be his reason but Prof. Yaghi is from a Palestinian refugee family and born in Jordan. There are probably more than a few reasons he might not feel welcome in the US at the moment.
I'm guessing the advantage of generated columns is that they are real columns, not computed columns like in a view. This means that if an insert doesn't work with the new generated column an error will be generated? Is that a correct understanding ?
Is this perhaps the main advantage of this feature ?
The data creation and storage options, always computed or stored on write of dependant columns seems like a possible advantage too.
reply