> Pointing capability: Gemini 3 has the ability to point at specific locations in images by outputting pixel-precise coordinates. Sequences of 2D points can be strung together to perform complex tasks, such as estimating human poses or reflecting trajectories over time
Does somebody know how to correctly prompt the model for these tasks or even better provide some docs? The pictures with the pretty markers are appreciated but that section is a bit vague and without references
For my CMS I’d love to get an AI to nicely frame a picture in certain aspect ratios. Like of I provide an image, give me coordinates for a widescreen, square, portrait, and 4x3 using a photographers eye.
Any model that can do that? I tried looking in huggingface but didn’t quite see anything.
This is a small TailwindCSS alternative based on a css template literal. I was inspired by styled-components and EmotionCSS, which however do not work well with ViteJS and specifically Preact.
I wanted something more optimized than other CSS-in-JS alternatives that generate CSS at runtime, so I created a ViteJS plugin. It extracts all style snippets, replaces them with classes like css-a1b2c3, and injects all the corresponding styles into a CSS file in place of an @extracted-css directive.
This provides a better experience than Tailwind, as you can use all CSS language features without learning new conventions while maintaining a per-component styling approach. This turns out to be more inspectable in the browser's dev-tools, as snippets are extracted as-is and are not fragmented across thousands of small classes.
There is also a preact options hook that adds a custom classList attribute, which maps to clsx for easy class composition (similarly to VueJS, Svelte, etc.).
P.S. I know other frameworks exist, but I have really been enjoying using Preact for frontend development recently.
Can we run an agent in Github CI? I create a Github issue with my requirements, the CI runner runs Aider scripting mode (it connects to say, OpenAI api) which looks at the comments, maintains a branch, runs tests, takes browser screenshots and then gives its replies.
> The only way to do fast inference here is to pipeline those layers by having one GPU handle the first ten layers, another handle the next ten, and so on. Otherwise you just won’t be able to fit all the weights in a single GPU’s memory, so you’ll spend a ton of time swapping weights in and out of memory and it’ll end up being really slow. During inference, each token (typically in a “micro batch” of a few tens of tokens each) passes sequentially through that pipeline of GPUs
I successfully converted a typst report to md/mdx last week using this technique. For complex layout primitives I just told the llm to write a comment with a warning todo of the missing part it wasn't able to convert
Yeah I really like Astro too, I often just start with the minimal template [1] that is just a couple of files. I used to do many experiments with custom SSG some time ago but since Astro came out I can't change back anymore.
If you don't want js on the frontend you can just use it as a nice html templating engine. It also renders markdown automatically for you as it recognizes different formats by the file extension.
I agree about relational languages. It's absurd when I think that SQL and Datalog came from the same foundations of relational calculus. It's just so much lost expressive power.
I really like what PRQL [1] did, at least it makes table operations easily chainable. Another one that comes to mind is Datomic [2].
I was struggling with doing interesting things with the semantic web circa 2007 and was thinking "OWL sucks" and looking at Datalog as an alternative. At that time Datalog was an obscure topic and hard to find information about it. 10 years later it was big.
(Funny after years of searching I found somebody who taught me how to do really complex modelling in OWL DL but from reading the literature I'm pretty sure the average PhD or prof in the field has no idea.)
I wrote up what I learned an a technical report that got sent to the editors at ISO a month or so ago and ought to appear pretty soon. Look up my profile and send me a note.
I have spent a lot of time trying to understand how we ended up with SQL. Best I can determine, we got SQL because it isn't relational, it is tablational. Tables are a lot easier than relations to understand for the layman, and they successfully pushed for what they were comfortable with, even if to the chagrin of technical people.
"RM:
What was key to SQL becoming the standard language for relational databases in the mid- 1980s? Was all down to good marketing?
CJD:
In other words, why did SQL became so popular? Especially given all its faults? Well, I think this is rather a sorry story. I said earlier that there has never been a mainstream DBMS product that’s truly relational. So the obvious question is: Why not? And I think a good way for me to answer your questions here is to have a go at answering this latter question in their place, which I’ll do by means of a kind of Q&A dialog. Like this:
Q:
Why has no truly relational DBMS has ever been widely available in the marketplace?
A:
Because SQL gained a stranglehold very early on, and SQL isn’t relational.
Q:
Why does SQL have such a stranglehold?
A:
Because SQL is “the standard language for RDBMSs.”
Q:
Why did the standard endorse SQL as such and not something else-something better?
A:
Because IBM endorsed SQL originally, when it decided to build what became DB2. IBM used to be more of a force in the marketplace than it is today. One effect of that state of affairs was that-in what might be seen as a self-fulfilling prophecy-competitors (most especially Relational Software Inc., which later became Oracle Corp.) simply assumed that SQL was going to become a big deal in the marketplace, and so they jumped on the SQL bandwagon very early on, with the consequence that SQL became a kind of de facto standard anyway.
Q:
Why did DB2 support SQL?
A:
Because (a) IBM Research had running code for an SQL prototype called System R and (b) the people in IBM management who made the decision to use System R as a basis on which to build DB2 didn’t understand that there’s all the difference in the world between a running prototype and an industrial strength product. They also, in my opinion, didn’t understand software (they certainly didn’t understand programming languages). They thought they had a bird in the hand.
Q:
Why did the System R prototype support SQL?
A:
My memory might be deficient here, but it’s my recollection that the System R implementers were interested primarily in showing that a relational-or “relational”-DBMS could achieve reasonable performance (recall that “relational will never perform” was a widely held mantra at the time). They weren’t so interested in the form or quality of the user interface. In fact, some of them, at least, freely admitted that they weren’t language designers as such. I’m pretty sure they weren’t all totally committed to SQL specifically. (On the other hand, it’s true that at least one of the original SQL language designers was a key player in the System R team.)
Q:
Why didn’t “the true relational fan club” in IBM-Ted and yourself in particular-make more fuss about SQL’s deficiencies at the time, when the DB2 decision was made?
A:
We did make some fuss but not enough. The fact is, we were so relieved that IBM had finally agreed to build a relational-or would-be relational-product that we didn’t want to rock the boat too much. At the same time, I have to say too that we didn’t realize how truly awful SQL was or would turn out to be (note that it’s much worse now than it was then, though it was pretty bad right from the outset). But I’m afraid I have to agree, somewhat, with the criticism that’s implicit in the question; that is, I think I have to admit that the present mess is partly my fault."
> Why has no truly relational DBMS has ever been widely available in the marketplace?
Postgres was "truly relational" for a significant portion of its life before finally losing the battle with the SQL virus. There is probably no DMBS more widely available. Granted, it wasn't widely used until the SQL transition.
> SQL isn’t relational.
This is key. Relations are too complicated for the layman, the one who is paying for it, to understand. Tables are more in tune to what is familiar to them. The hardcore math/software nerds might prefer relationality, but they aren't the ones negotiating multi-million dollar contracts with Oracle/IBM.
I remember when Postgres moved to SQL. People started billing it as being Oracle, but free. That got non-technical manager attention. Without that marking success appealing to the layman, I expect nobody would be using it today.
What I don't like about these state machine DSLs is that they are not really composable at the "machine level". It is a known fact that FSM are equivalent to regular expressions [1]
Alternatively, a regular language can be defined as a language recognised by a finite automaton. The equivalence of regular expressions and finite automata is known as Kleene's theorem
I think a cool state machine language would use this fact as a starting point for it's syntax. Another very useful feature would be "functions" to isolate specific repetitive parts of FSM
xstate and other libraries like it implement Harel's statecharts, which are an extension of FMSs with different semantics and composability (a.k.a. "hierarchy", where machines can embed other machines), so the relationship with regular expressions may not be that useful.
"Classic state diagrams require the creation of distinct nodes for every valid combination of parameters. For all but the simplest of systems, this can lead to a very large number of nodes and transitions between nodes (state and transition explosion), which reduces the readability of the state diagram." [1]
"What's missing in the traditional state machines is the mechanism for factoring out the common behavior in order to share it across many states. UML state machines address exactly this shortcoming of the conventional FSMs. They provide a number of features for eliminating the repetitions so that the complexity of a UML state machine no longer explodes..." [2]
FOMA is a finite state transducer library that creates composable FSTs. FSTs are generlaizations from one-sided FSAs in that while they accept input they also write and output (they are further elegant because they are not only composable but also reversable: switching input and output tames with "up" and "down" is trivial, so the same formalism can be used to analyze and generate).
FOMA [1] is an open source clone of the Xerox XFST tools [2,3] developed at Xerox Research Laboratory Europe in Grenoble under the late Prof. Lauri Karttunen.
While the FOMA/XFST family of tools are most suitable for linguistic applications and for teaching formal language theory, I have been impressed
by the fact that they are the only formalism that permits elegant naming and re-use of sub-automata.
Most common regex implementations are not composable at the language level but there are more modern alternatives like Pomsky [1] that introduce bindings and actually make regexes composable expressions.
By the way regular expressions are "composable" by definition as they are defined recursively as (in their simplest form)
- ε is the regex that matches the empty string
- given regexes A and B we can construct the new regex AB that matches first the regex A followed by B
- given regexes A and B we can construct A|B that matches A or B
- given a regex A the regex A* matches any number of repeated occurrences of A
Then for some reason languages like javascript don't provide a way of constructing
> - given regexes A and B we can construct the new regex AB that matches first the regex A followed by B
> - given regexes A and B we can construct A|B that matches A or B
Concatenation and alternation is not what one typically imagines when they utter the word composition (unless you expect me to understand "composition over inheritance" to mean actually "just use two classes instead of one").
Does somebody know how to correctly prompt the model for these tasks or even better provide some docs? The pictures with the pretty markers are appreciated but that section is a bit vague and without references
reply