I always wonder why SQLite didn't expose a programmatic way for creating a query (as opposed to parsing SQL statements). Given that it was designed to be embedded, it seems to me that it would have made far more sense to provide an API based interface. Then, for example, stored procedures would just be function pointers passed as callbacks.
Don't bother, I tried with a disposable email address and they make you subscribe to a mailing list before sending you the download link. When you do eventually get it, it's a 3 page puff marketing PDF.
I converted it to TXT and pulled out the only bit of interest here:
Collabora Office Collabora Office Classic
Fresh, modern UX Classic, established UX
Javascript & CSS UI to match Collabora Online VCL-based classic UI
Simpler settings / streamlined defaults Very extensive options, menus & dialogs
No Java Java used for some features/wizards/DB drivers
No built-in Base app Includes Base UI
Runs macros Full macro editor & advanced BASIC/Python/UNO
Modern web tech (Canvas, WebGL, CSS) Custom toolkit (VCL)
Fast to iterate (edit JS, fewer recompiles) Core/C++ changes typically require recompiles
Initial release – Enterprise Support is coming Long term Enterprise Supported
Quick Start Guides and video tutorials Extensive manuals & books
If you don't give an email address, it doesn't even prompt you to ttry again. It just bugs out and redirects to a home page with a broken URL attempting to inject HTML from client side.
That's strange because the only reason for a user to use OpenOffice/Collabra is because they don't want to deal with an annoying company that makes a far superior product. If the inferior product is also run by an annoying company, why bother?
Yeah, I'd say that's the gist of it altogether... I get they want to monetize hosting/support etc.. but they should really try not to gatekeep what should be basic/public information.
I'd still probably put Collabra above Google Docs, but definitely a step below even MS Office Online, err 365, err CoPilot App or whatever the hell they're calling it now... (naming issues not withstanding). Though MS has been enshitifying the offline versions of office a lot, not to mention Outlook in particular.
Aside: Why MS hasn't done a version of "Microsoft Access Online" with a WASM port of VBA in order to lift/shift Access apps into a hosted environment that's backed by Azure SQL under the covers is kind of beyond me. I mean, it shouldn't take too much effort at this point with the level of tooling MS has been capable of.
Access was the distilled VB + Database apps kind of thing that a lot of SOHO really thrived on, and they could totally (re)capture that market with a bit of legacy uplift/support along with a newer model/design. Displacing the winforms models with webforms and a dedicated server/service system. 3 versions to start, a legacy/support, a bridge and a new model where it's TS/JS and monaco for editing instead of VBA/wasm/webforms in a browser/canvas. People are running older versions of Windows in wasm/x86 emulation... making that pretty and wrapping hosted access runtimes should be somewhat reasonable. Shouldn't it?
That I don't know, but the s7 author, Bill Schottstaedt (who I will ping about this) is very helpful on the email list and is deeply, deeply knowledgeable about Lisp, so you could definitely ask there!
In my context, I have rigged up a REPL in Max, so I wind up using that instead. (Which is freaking awesome, because I can script all of Max from my vim buffers.)
it's trivial to implement a REPL yourself, you "just" need to poll for stdin in your main loop and pass this to S7 for evaluation. I made a demo once upon a time live coding with DearImGui: https://www.youtube.com/watch?v=MgHsl0u26MY
For the emacs side I used cmuscheme which is basically comint. Of course you don't get the same experience as in common lisp, but I found S7 to be pleasant to work with also in regards to reporting errors etc
What is the revenue model for Tangled? This is why ATProto stuff worries me, the AppView is expensive to host and no one has created a paid service yet to achieve sustainability.
I had a similar issue when I first brought my iPad. Turns out, Apple doesn't like custom domains for emails. So, I had to make an Apple account with a Gmail account, then remove the Gmail account and add my email address with the custom domain.
Why? Who knows. Still remember my first experience after buying an iPad.
Might've had something to do with the state of the various email security measures on the domain. I have an Apple account on a custom domain with Fastmail and it's never been a problem.
I couldn't make an account on the website Digikey outsourced all their 3d models to with my work email. signed up with my personal gmail account in less than 30 seconds.
This is not some Apple specific problem.
Also this was yesterday. Never did I get any of the 3 confirmation emails they claim they sent to my work mail.
You have to reach a human to make a Flickr account in 2025 if you use a custom domain. It wasn't too difficult, they gave me some reason about abuse. Whatever.
You purchase your own domain name and use that domain name as your email address. For instance, if I had an email address that was me@afandian.com; the afandian.com would be a custom domain. It's not routed to @gmail.com, it's routed to @afandian.com. Now in practice you can have a custom domain and still have it managed by Google's Mail servers; but it's the domain name itself that sends up the flags.
I agree. When people bemoan the death of lisp machines and RAD and whatnot, remember that we deserve it. We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this.
> We do not want to invest in good tools and treat "Worse is Better" as some twisted virtue, and then wonder why everything sucks and most developer experience is stuck in 80s-90s technology paradigm. We deserve this.
Not terribly surprising that one of the most true comments is at the bottom. The Stockholm syndrome by devs desperately wanting to believe that bad tools are good is insane.
It's not even hard to see why Worse is Better is just worse - among many other tests, you can look at the number of production-grade systems and popular tools written in Perl (virtually non-existent) and bash (literally zero). Empirical evidence strongly contradicts the core value tenets of the ideology.
Yeah, the downvotes were expected. Developers do not like being called out for the miserly and self-destructive bunch that we are.
I was building an advance IDE for C and gave up when I realised that no one would buy it because "lol vim is free". Finally, I am gathering the strength to resume working on it, but only for personal use and with no expectation of selling more than 100 copies.
What bothers me the most is the hypocrisy. It's okay to make money by showing predatory ads to unsuspecting populace, but not by selling useful tools. No, that is immoral.
It seems that most research effort goes into better dtoa, and not enough in a better atod. There are probably a dozen dtoa algorithms now, and (I think?) two for atod. Anyone know why?
Good question. I am not familiar with string-to-double algorithms but maybe it's an easier problem? double-to-string is relatively complex, people even doing PhD in this area. There is also some inherent asymmetry: formatting is more common than parsing.
In implementing Rust's serde_json library, I have dealt with both string-to-double and double-to-string. Of the two, I found string-to-double was more complex.
Unlike formatting, correct parsing involves high precision arithmetic.
Example: the IEEE 754 double closest to the exact value "0.1" is 7205759403792794*2^-56, which has an exact value of A (see below). The next higher IEEE 754 double has an exact value of C (see below). Exactly halfway between these values is B=(A+C)/2.
So for correctness the algorithm needs the ability to distinguish the following extremely close values, because the first is closer to A (must parse to A) whereas the second is closer to C:
The problem of "string-to-double for the special case of strings produced by a good double-to-string algorithm" might be relatively easy compared to double-to-string, but correct string-to-double for arbitrarily big inputs is harder.
I guess one aspect of it is that in really high performance fields where you're taking in lots of stringy real inputs (FIX messages coming from trading venues for example, containing prices and quantities) you would simply parse directly to a fixed point decimal format, and only accept fixed (not scientific) notation inputs. Except for trailing or leading zeros there is no normalisation to be done.
Parsing a decimal ASCII string to a decimal value already optimizes well, because you can scale each digit by it's power of 10 in parallel and just add up the result.
For those wishing to read up on this subject, an excellent starting point is this comprehensive post by one of the main contributors of the fast algorithm currently used in core:
> Unlike formatting, correct parsing involves high precision arithmetic.
Formatting also requires high precision arithmetic unless you disallow user-specified precision. That's why {fmt} still has an implementation of Dragon4 as a fallback for such silly cases.
Is it, though? It's genuinely hard for me to tell.
There's both serialization and deserialization of data sets with, e.g., JSON including floating point numbers, implying formatting and parsing, respectively.
Source code (including unit tests etc.) with hard-coded floating point values is compiled, linted, automatically formatted again and again, implying lots of parsing.
Code I usually work with ingests a lot of floating point numbers, but whatever is calculated is seldom displayed as formatted strings and more often gets plotted on graphs.
For serialization and deserialization, when the goal is to produce strings that will be read again by a computer, I consider the use of decimal numbers as a serious mistake.
The conversion to string should produce a hexadecimal floating-point number (e.g. with the "a" or "A" printf conversion specifier of recent C library implementations), not a decimal number, so that both serialization and deserialization are trivial and they cannot introduce any errors.
Even if a human inspects the strings produced in this way, comparing numbers to see which is greater or less and examining the order of magnitude can be done as easy as with decimal numbers. Nobody will want to do exact arithmetic computations mentally with such numbers.
Think about things like logging and all the uses of printf which are not parsed back. But I agree that parsing is extremely common, just not the same level.
Can the metadata feature be used to ergonomically emulate HTML attributes? It's not clear from the docs, and the spec doesn't seem to document the feature at all.
i feel hiccup indexed based magic is a common design pattern you see in early Clojure and its less common now (id say hiccup is the exception that lives on)
SDL GPU is extremely disappointing in that it follows the Vulkan 1.0 model of static pipelines and rigid workflows. Using Vulkan 1.3 with a few extensions is actually far more ergonomic beyond a basic "Hello, World" than using SDL GPU.
That might exclude a lot of your user base. For example a big chunk of Android users, or Linux workstation users in enterprise settings who are on older LTS distributions.
reply