This sounds like a cool project! Does anyone here knows how it compares to univerjs ?

I currently use univerjs to power the open source sql spreadsheet component I work on (https://github.com/sqlpage/sqlpage-spreadsheet/). My experience with it has been that it's very powerful, but quite difficult to use due to the boilerplate involved, the lacking documentation, and the fact that it seems to be developed mainly for the Chinese market.

Woah! I didn't realize luckysheets renamed to univerjs!

I think at the time being you should stick to univerjs as it is a finalized product. Once we reach version 1.0, IronCalc should be easier to deal with and you cold consider using one or the other.

> $ sqlite3 whois-log-copy.db "select source from queries"|sort|uniq|wc -l

Oh cool they saved the logs in a database ! Wait... |sort|uniq|wc -l ?? But why ?

SELECT COUNT( DISTINCT source ) FROM queries ORDER BY source ASC

-- COUNT ( DISTINCT ... ) ~= uniq | wc -l ;; sort without -u is this busybox? ORDER BY col ASC

-- wait this doesn't need sort and uniq if it's just being counted...

SELECT COUNT( DISTINCT source ) FROM queries

bash nerds vs sql nerds I guess, these people are bash nerds

beats up re-re-remembering how to do it in sql

And probably because for quick things like that you’re already working in a “pipeline”, where you first want to see some of the results so you output with SQLite, and then add more to the pipeline. Similarly, I often do ‘cat file | grep abc’ instead of just grep, might be probably out of habit.

I found that this is actually a good use case for LLMs. You can probably paste that one liner up there and ask it to create the corresponding SQL query.

yeah, they're good for cursed tools like that, ffmpeg, excel macros, etc etc

yeah, they could have done `sqlite …|sort -u|wc -l` instead and saved themselves a process invocation!

Hey now if you're just gonna count lines no need to sort it at all.

you need to sort it in order to uniq it, because uniq only removes duplicate consecutive lines.

You know, it's been so long since I've used it, I completely forgot that fact. Alright, you win the battle of best correct bad sql to bash pipeline :).

I think getting support requests from users who don't know what they are doing is actually a great problem to have.

I have a project that allows building web applications out of SQL queries [1]. When I started receiving support requests by people who did not know SQL and were basically learning it along, I was thrilled. I was happy that my tool had a greater audience than I initially envisioned.

In any given domain, specialists are the minority. If the thing I am building is unexpectedly appealing to non-specialists, I rejoice, even if it means getting strange support requests. In the end, it helps me making the project more approachable and easy to use for everyone.

[1] https://sql.datapage.app

It's strange to call CTEs a "postgres feature". It's standard SQL, it's in all databases.

Not in MySQL 5.7, which is officially my least favorite database to maintain.

Thank you! I'd love to get your feedback if you use it.

I would even go further: this sounds like a database problem.

Is the set of ship positions and watched polygons entirely different from run to run? If not, it should be possible to go much faster than even the new rust based approach that takes 6 hours.

I would have used a postgres database with a PostGIS spatial index.

I'd just throw it into a quadtree (or similar) and go get a coffee. I know there are some pretty fast bounding box algorithms from when I used to mess with such things but can't remember them off the top of my head.

Absolutely. It’s kind of amusing to read a post that’s kind of dragging the wrong tool for the job, and then recommends another wrong tool for the job. The whole time I’m just yelling, “This is a geodatabase problem!”

There’s the right way, the wrong way, and the Max Power way. Wrong but faster!

This. While reading the post, I wondered when he'd mention something about spatial databases or spatial indexes.

Agreed. As someone who often advocates for the use of Rust to speed up perf-sensitive Python functions (and in particular, in the GIS domain), this sounds like they haven't fully understood the problem or thought about how to solve it more efficiently with a spatial index (which is easily done in Geopandas, let alone PostGIS). However, the post is a bit vague on details so who really knows.

It's encouraging to see how digital tools are helping address the "legacy data backlog". This aligns well with the collaborative open-science approach.

For those interested, I recently translated an article by french archeologists on the same topic: https://sql.ophir.dev/blog.sql?post=How%20archaeology%20is%2...

How can it be a good idea to have a time limit for the compilation of expressions in a compiler ?

Doesn't that mean that your program can compile fine in the morning, and fail to compile in the afternoon because you have an HD youtube video playing in the background ?

Or the same program could compile fine on your computer, and fail to compile on less powerful CI servers ?

I think the justification is that outside of pathological cases, it allows writing clean code without too many type annotations, and the compiler just figures out everything for you.

    let result: Double = -(1 + 1) + -(1 + 1) - 1

Swift 6 takes 6.2 seconds to compile this one line.

That's crazy...

Swift programmers: do you face this kind of issues often?

That is outrageous. It also cannot be blamed on Hindley Milner. While HM in theory has exponential worst case time, the constructs to trigger it for OCaml and Standard ML are far more complex, carefully constructed and never occur in practice.

OCaml does have +. for floats to make type checking easier, but Standard ML does not. Also, if Swift has operator overloading, why isn't it instantly clear that the RHS is an int, which can be assigned to a double?

This just looks like a performance bug in the type checker, and nothing that is inherent to HM.

People have been complaining about this issue for 10 years. Presumably if there were an easy fix they would have fixed it by now. They painted themselves into a corner somehow with HM, polymorphic literals and function overloading. Haskell doesn’t have function overloading (except for type classes) and OCaml doesn’t have polymorphic literals.

It seems like it’s not only function overloading (which, as you point out, Haskell does too by way of typeclasses) but also the implicit conversion between Int and Double. OCaml, Haskell, and Rust all require you to convert between them explicitly so they don’t need to figure out whether each 1 in the expression is an Int or a Double.

Am I seeing this correctly? Is HM + polymorphic literals + implicit type conversion the cause of Swift’s exploding compile time in such cases?

Ok, but then they should explain this particular case better. The RHS can be figured out just by choosing the overloaded operators.

In C++ terms, if you have int& operator+(const int&x, const int& y) then (1 + 1) is not ambiguous and can be selected fast. Same for unary minus etc.

The Swift devs should then blog about this example and explain step by step what is going on. If the literal "1" can be both an int and a float, that of course would be insane. Is that what you meant by "polymorphic literals"?

Wow, that is crazy. For me (Swift 5.10) that single line is taking 11 seconds. Meanwhile, I have a 16,000 line app (importing AppKit, SceneKit and more) that compiles in 8 seconds.

Following up with compile time of a few variations.

    let result:Double = -(1 + 1) + -(1 + 1) - 1 // 10.829s
    let result:Double = -(1 + 1) + -(1 + 1)     // 1.724s
    let result:Double =  (1 + 1) +  (1 + 1) - 1 // 1.721s
    let result:Double = -(1 + 1)            - 1 // 0.763s
    let result:Int    = -(1 + 1) + -(1 + 1) - 1 // 0.571s

    let result:Double = -(1 + 1) + -(1 + 1) + 1
    //error: the compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

I've been doing a lot of SwiftUI stuff lately and the compilation times are pretty crap even for simple applications. Change one line and it's a minute or two of compilation again.

Then there's this fucker for whenever you make a programming error involving types:

>The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions

Basically, your code has a type error somewhere in it, and you need to figure out where and how it's wrong.

The devx is terrible. I came back to native iOS and SwiftUI. to upgrade some of my old apps after working in flutter for the last six months and I've been astonished at how slow and clunky it is. Runtime performance can also be quite bad if you do things in a straightforward way and optimizing things is not very straightforward.

Xcode is still awful too.

One minute compiling Swift UI code - is that without the worst case line above?

So every edit you need to take a minute to see how it renders?

If you're just doing UI changes, I think you can do pretty fast iterations using just the Xcode preview canvas. And while some light edits actually build in seconds, it does feel like it needs that minute compilation surprisingly often when doing fast iterations.

>do you face this kind of issues often

In my personal experience, no. That doesn't mean it's not a weakness of the language, but in practice you very rarely write a real expression with more than one or two type inferences in it. And when you do, you can just add explicit typing.

Nope this never happened to me but i'm always writing explicit types in every language :]

I don't know Swift, but you are declaring Double while using Int. 6.2 seconds seem pretty quick for something that I would expect to be: never.

They are using integer literals, not Ints. Any type can declare the ability to be representable by any literal. Double can be represented by floating point literals or integer literals (since Double, the type, can represent integers, the category of number).

  let x: Double = 2
  let y = 5 / x

y is a Double with a value of 2.5.

  let x: Int = 2
  let y = 5 / x

y is an Int with a value of 2.

  let x: Int = 2
  let y: Double = 5 / x

Code doesn't compile.