mg

As I understand it, "RETURN" means that the function will return something. And that when you define a function that returns nothing, but only does something, you just use "HOW TO".

Well, not as bad as something like

    public static function words(string $document): array {

which some languages these days are coming up with.

The first example in the lanuage introduction (https://homepages.cwi.nl/~steven/abc/):

   HOW TO RETURN words document:
      PUT {} IN collection
      FOR line IN document:
         FOR word IN split line:
            IF word not.in collection:
               INSERT word IN collection
      RETURN collection

In Python it would be:

    def words(document):
       collection = set()
       for line in document:
          for word in line.split():
             if word not in collection:
                collection.add(word)
       return collection

I kept the splitting by line and "if word not in collection:" in there even though they don't have an impact on the outcome. I have the feeling that even in the original example they have only been put there to show the language constructs, not to do anything useful. If one wanted to optimize it, it could all be collapsed to just "return set(text.split())", but that would not show off the language features.

ABC uses 225 chars, Python 218 chars. 3% less.

So one could say Python is 3% more efficient than ABC.

Six months of one developer tuning the kernel?

That seems like not much compared to the hundreds of billions of dollars US companies currently invest into their AI stack? OpenAI pays thousands of engineers and researchers full time.

560g is fine. But I wouldn't want to work on a 11.5" device. Something between 13" and 14" is my preferred size.

And I would want to do a normal Debian stable installation. Just like I can on a Lenovo laptop. The Librem 11 comes with their own Debian based distro and I can't find any info if I can install a normal Debian on it from scratch.

Does that mean that one will be able to purchase tablets with this chip and replace the OS with Linux?

That would be great. As far as I know, there currently are no options for lightweight tablets that support Linux.

Not sure how well WSL2 on tablets work. Does anybody here have experiences with WSL2 on tablets like the new Microsoft Surface Pro that uses the Snapdragon X Elite chip?

8.6 MB - wow!

There must be way more in there than just running Python code.

I once implemented a small subset of PHP in PHP (just enough to run the code I wanted it to run) and it took me 320 lines of code. The file (gloriously named php.php) was less than 10k in size.

Still, loading 8.7 MB is kinda ok. It takes about 2s on my pretty normal home connection.

Indeed, https://pyodide.org/en/stable/console.html loads a wasm that is 8.7 MB.

It also loads "python_stdlib.zip" which is 2.42 MB. Maybe that is the whole standard lib in compressed form? I wonder why they publish a zip. Browsers natively support all kinds of nice compression.

I guess there are leaner implementations than CPython?

https://pyscript.net loads a file "mircopython.wasm" that is 434 KB.

I think it shouldn't be too hard to just output g-code via a Python program?

That is the direction I will probably first look into when I get to the g-code level of my 3d-journey.

For the core of my engine, I just need to build some basic mesh tools like mesh(), combine(), intersect(), difference(). Everything else, common objects like cube(), sphere(), disk() and common operations like move() and rotate() is then simple.

SolidPython: This seems to rely on OpenScad. I think a solution without dependencies will fare better in the long run.

PythonSCAD: This also seems to be heavily interwoven with OpenScad.

CadQuery: This might be interesting. I will probably start with some code for mesh(), combine(), intersect(), difference() that I write myself and then look into libraries like this one and evaluate if it makes sense to swap out my own for one of them. But I have the feeling they will not match my preferred architecture closely enough.

What do you mean by "Due to the large size, python really isn't suitable for embedding in wasm"? In what regard is Python "big"?

From what I have seen so far, OpenScad is the closest to how I would like to build my objects.

The two main differences to how I want to work are:

1: I want to use a web-based solution. I don't like to install software. I just want to open a website. No matter if I am on Linux, Android or iOS - it should just work.

2: Instead of the SCAD language, I want to use Python.

Fullcontrol looks interesting, thanks!

I just started 3D printing a few weeks ago. I already realized that I need to write my own CAD software. None of the existing ones are the way I want to design objects. That will probably take a few months. Then I will probably want to control the prints down to the gcode level and look into the situation then.

I wouldn't mind long print times.

I am not sure, but "fuzzy skin" seems to intentionally sacrifice some adherence to the object's exact shape? "folded outline" would not do that. If the printer prints it exactly, the print would match the object just as precisely as a normal outline.

The IdeaMaker repo on GitHub says it is abandoned. Maybe there are other options? An open source slicer written in Python without dependencies that works on the command line would be my favorite starting point. If there is none, writing a new one might also be feasible?

I often wonder if there should be something like a "folded outline" mode in slicers. For example, it would make the outer left wall of an object:

    │││││││
    │││││││
    │││││││
    │││││││  Inside of the object
    │││││││  is here
    │││││││
    │││││││
    │││││││
    

Look like this instead:

    ┌────
    └─────┐
    ┌─────┘
    └─────┐ Inside of the object
    ┌─────┘ is here
    └─────┐
    ┌─────┘
    └─────
    

The seam (where the print head moves up a layer) could then be on the inside of the object:

    ┌────
    └─────┐
    ┌─────┘
    └─────  <-- Print head moves up here
    ┌─────┘
    └─────┐
    ┌─────┘
    └─────

This might result in having no visible seam but instead evenly distributed vertical lines, similar to the horizontal lines that all 3D prints have. The horizontal lines look quite nice when the print is otherwise perfect. So maybe doing this and having horizontal AND vertical lines would look good overall?

For now it seems to be just a list.

If it had a "significance" attached to each event and a slider one can use to set the significance threshold, then it would be what I mean.

This misses the overview. It has lots and lots of technologies all at the same size. And no way to zoom out.

Yes, but I think it makes a nice view to point to some first popular instance of something. Otherwise everything becomes fuzzy. For example, there was AI in the 60s. But ChatGPT was the first that achieved mass adoption.

I put Facebook up there to point towards the beginning of social media.

I always wanted something like a "History of human progress" which when zoomed out shows me something like this:

    -2000000 Stone tools
    -1000000 Using fire
       -6000 Metal tools
       -6000 Agriculture
       -4000 Writing
        1550 Printing
        1888 Telephones
        1888 Cars
        1903 Planes
        1941 Penicillin
        1941 First computer
        1982 Homecomputers
        1983 Mobile phones
        1990 The internet
        2001 Wikipedia
        2004 Facebook 
        2007 IPhone
        2022 ChatGPT

And then I can zoom in on particular areas of time and see smaller milestones.

When I look at the new pipe syntax ...

    $output = $input
        |> trim(...)
        |> (fn (string $string) => str_replace(' ', '-', $string))
        |> (fn (string $string) => str_replace(['.', '/', '…'], '', $string))
        |> strtolower(...);

... I think why not just something like the following?

    $output = $input
        |> trim($)
        |> str_replace(' ', '-', $)
        |> str_replace(['.', '/', '…'], '', $)
        |> strtolower($);

Neither are humans.

That makes me wonder if we could simply test this by letting the LLM add or multiply a long list of numbers?

Here is an experiment:

https://www.gnod.com/search/#q=%23%20Calcuate%20the%20below%...

The correct answer:

    Correct:    20,192,642.460942328

Here is what I got from different models on the first try:

    ChatGPT:    20,384,918.24
    Perplexity: 20,000,000
    Google:     25,167,098.4
    Mistral:    200,000,000
    Grok:       Timed out after 300s of thinking

If a model is not making use of the whole context window - shouldn't that be very noticeable when the prompt is code?

For example when querying a model to refactor a piece of code - would that really work if it forgets about one part of the code while it refactors another part?

I concatenate a lot of code files into a single prompt multiple times a day and ask LLMs to refactor them, implement features or review the code.

So far, I never had the impression that filling the context window with a lot of code causes problems.

I also use very long lists of instructions on code style on top of my prompts. And the LLMs seem to be able to follow all of them just fine.

The match/when approach also needs more code. 393 instead of 360 chars.

Hmm... one moment. The first example function they provide:

    function handleResponse(response) {
        return match (response) {
        when ({ status: 200, data }) -> data
        when ({ status: 401 }) -> throw new Error(’Unauthorized’)
        when ({ status: 404 }) -> throw new Error(’Not Found’)
        when ({ status: s if s >= 500 }) -> throw new Error(’Server Error’)
        default -> throw new Error(’Unknown Error’)
      };
    }

Is less readable to me than the way I would write it without the match/when construct:

    function handleResponse(response) {
        status = response.status;
        data   = response.data;
        if (status === 200 && data) return data;
        if (status === 401) throw new Error(’Unauthorized’);
        if (status === 404) throw new Error(’Not Found’);
        if (status  >= 500) throw new Error(’Server Error’);
        throw new Error(’Unknown Error’);
    }

RedShift1 complains that GCP is "deprecating stuff". I wouldn't put doing regular updates in the same problem category as having to deal with part of your stack disappearing.

To me "I wish they would stop deprecating stuff" sounds like any part of the stack has something like a 1% or even 10% chance in any given year to be shut off.

I would expect that by carefully choosing your stack from open source software in the Debian repos, you can bring the probability of any given part being gone with no successor to less than 0.1% per year. As an example - could you imagine Python becoming unavailable in 2026? Or SQLite? Docker?

One approach to prevent being hit by "stack rot" is to build everything on top of plain Linux VMs.

Those rarely change.

Looking at the syntax, I wonder how close one could get to it in a "normal" programming language.

    x -> y: hello world

    declares a connection between two
    shapes, x and y, with the label,
    hello world

When I read this, I see this Python line in my mind:

    connect('x', 'y', 'hello world')

This is of course a lot longer. The reason is that D2 seems to rather use operators than functions. So another approach could be

    'x' * 'y' + 'hello world'

This would be possible to implement if the language supports overloading the __add__ and __mul__ functions of the str class. Python does not support it though. So I guess one would have to put at least one instance of a custom class into the mix. Say 'scene', then one might be able to achieve the above with this line:

    scene + 'x' * 'y' + 'hello world'

Meaning "Put a connection between x and y with label 'hello world' into the scene".

Hmm.. also not very close to the D2 syntax. So a DSL for diagrams seems to be warranted.

That definition would mean that smarter investors, who can think faster and further ahead, get information faster. And therefore have information now that others do not.

That seems to be directly the opposite of the common definition of the EMH, which emphasizes how the market reacts to new information. And not how it produces information. For example in TFA:

"the market rapidly responds to new information"

Wikipedia starts the "Theoretical background" with an example on how information becomes widely available to all investors, not how one fast smart thinker generates it:

    Suppose that a piece of information about the value
    of a stock (say, about a future merger) is widely
    available to investors.

https://en.wikipedia.org/wiki/Efficient-market_hypothesis

So $400B per year is currently spent on datacenter buildout?

To see if that is too much or not, we have to put that number in relation to the value those datacenters will create in the future.

If global GDP is $100T and labor is 50% of that, then the current TAM for intelligence is around $50T.

How much of that has to be automated per year to justify $400B of investment? For a 10% ROI it would be around 1%, right? But the datacenters will not be the only cost of generating artificial work. We also need energy, software and robots. So let's say 2%.

So it comes down to the question whether those datacenters built for $400B will automate 2% of global GDP in the foreseeable future.

And there is another option: That the TAM increases. That we use the new possibilities we have to build more products and services. And see global GDP grow. 2% AI driven global GDP growth would also justify the $400B datacenter buildout.

So let's think about a mix: 1% labor automation and 1% GDP growth per year via AI. That would be needed to justify continued spending of $400B per year for the AI buildout.

But do we see that happen?

That would mean that the p/e-ratio of a company would rise sharply long before the profits set in. And that rise would be called "mysterious" by the general public. And then only when the profits set in, the p/e would come down.

I can't see that in Nvidia for example:

https://www.macrotrends.net/stocks/charts/NVDA/nvidia/pe-rat...

The price roughly rose along the earnings. Even though the foundations for generative AI became clear in 2015.