You'd get a new browser running on any hardware/OS written in Zig that would just blow out the competition.
Oh and let's throw in Fabrice Bellard in there too just for the kicks.
```
~/cosmos $ uname -sm
Darwin arm64
~/cosmos $ ./bin/python
ape error: ./bin/python: prog mmap failed w/ errno 1
~/cosmos $ ./bin/ls
ape error: ./bin/ls: prog mmap failed w/ errno 1
~/cosmos $ sudo xattr -rd com.apple.quarantine bin/*
Password:
~/cosmos $ ./bin/ls
ape error: ./bin/ls: prog mmap failed w/ errno 1
```
Has anyone had any luck getting it to run on Macs?
Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine. Instead, it reconfigures stock GCC and Clang to output a POSIX-approved polyglot format that runs natively on Linux + Mac + Windows + FreeBSD + OpenBSD + NetBSD + BIOS with the best possible performance and the tiniest footprint imaginable.
But what I don't understand is the use case for an exe which supports both running as an user app on normal operating systems and from the BIOS. For which application specifically does it makes sense to run it in both these very different contexts?
But also: sbcl. You just know someone's going to do lisp-from-boot with this, if they haven't already.
I have seen the Ruby build process and it also links to libraries like OpenSSL.
Reference: https://docs.ruby-lang.org/en/master/contributing/building_r...
Packages to install: 1 (use-package-2.4.5). Proceed? (y or
n) y
Operation [ Install 1 ] started
Contacting host: melpa.org:443
Opening TLS connection to ‘melpa.org’...
Opening TLS connection with ‘gnutls-cli --x509cafile nil -p
443 melpa.org’...failed
Opening TLS connection with ‘gnutls-cli --x509cafile nil -p
443 melpa.org --protocols ssl3’...failed
Opening TLS connection to ‘melpa.org’...failedSo so so awesome.
The code to do it would probably go in here: https://github.com/jart/cosmopolitan/blob/master/libc/stdio/...
I mean, I know why it's not done (parsing floats correctly is a lot harder than it would at first seem to be) and I'm not complaining, more like hinting to some of the fine people that haunt this website who might find such a task interesting.
https://github.com/jart/cosmopolitan/pull/924
Oops, I only now realized there's a test suite. I'll be adding tests too... After I get some sleep.
I'm building my copy of cosmopolitan right now. If I succeed, I'll send you a pull request on GitHub.
Of course to get fewer distribution formats you had to make one more distribution format but in this one case it might actually work.
bin ./bashWhy non-native?
Some corporate IT shops manage user machines with tooling that can't deploy software specific to machine os/version/hardware/etc. This often caused problems with 32-bit vs 64-bit windows machines or differing windows versions (XP/Vista/....). We also couldn't easily make linux or osx executables available for the end-users due to corporate IT policies.
Users don't install software anymore, outside of mobile. Most things are now doable through the browser. The browser isn't perfect, but from a user perspective, it's a much better app delivery service than anything that's existed before
The only things I find myself installing recently are text editors, programming languages/command line tools, and games. What else? WSL is pretty good so I can even run a lot of Linux things from within Windows now
If I need something that needs raw power that's too much for a browser, like a database server or running an LLM model, I'm just gonna use Linux - why do I need cross compatibility?
2. Browsers are great at GUI apps, but depend on HTTP servers and emulate terminals poorly.
So I view the two as being complementary. I imagine it's one of the reasons why Mozilla supported the project. Both platforms solve the portability problem, except for fundamentally different areas. Put them together and you get something greater than the sum of your parts.
Web apps require servers, servers that need to be patched, updated, certificates, DDOS protection, and a number of other things. The apps themselves need management, and maintenance. So a "web app" is a service, no matter how you slice it.
An installed program can work for decades. My personal Wiki (WikidPad) that I run every day, is from an installer compiled in 2015. It just works. I tried to run it under Linux, where it was installed from source, and it won't work. The folks at WxWindows made a major breaking change, so none of the GUI forms/dialogs work, it just seems to work, until you need to change a setting, then it dies.
In theory, you could now create an installer that would work for the next 20 years without issue across operating systems.
That’s a pretty strong statement without any evidence to back it up. It sounds like the kind of statement I hear often from people who spend all of their time in the web-dev echo chambers. Lots of us install software and don’t spend much time in browsers beyond browsing the web and the handful of Electron apps that we have no choice but to use.
But it’s not hyperbole to say the browser has become the dominant software delivery platform outside of mobile. Email, CRMs, CMSs, electronic dictionaries, word processors, online chat, filing tax returns are just a few examples of things that used to require installing native apps and now are largely browser-based.
Ah, that brings me to something else that someone like jart might want to take on:
# bringing static linking for C into the 21st century
What's wrong with static linking in C? Well, it's still stuck with 1970s semantics, while dynamic linking has much nicer semantics. Specifically:
- static linking flattens the dependency
tree, which causes
- symbol collision issues
- also, there's no RPATH equiv. for static
linking
- write dependency metadata (-lfoo, rpath,
-L/...) into a "hidden" .o that has just
this metadata encoded in it
- make the static linker look for that
metadata in dependencies and resolve
conflicts the same way as in dynamic
linking
- for each link-edit, including the final
link-edit of the executable, require
only that direct -lfoo dependencies be
listed
Tell us more?
On Linux you’ll have one global variable. On Windows each DLL will have its own copy.
Which is better? It depends. Personally I think it’s much better for each shared/dynamic library to be a black box with a clearly defined API boundary. Thus I think the Windows approach is better.
The root evil here is that C++ is underdefined and what should really really really be a language level rule is actually left up to the platform.
I also think globals are evil and should almost never be used. But that’s a separate topic.
> The root evil here is that C++ is underdefined and what should really really really be a language level rule is actually left up to the platform.
Well, the issue is that C++ shares linking semantics with C, and C's linking semantics are not that well specified, because there's static linking -broken- and ELF -which has evolved to fix the problem you mention-.
Linux has eleventy billion config settings. If you very carefully set them, maintain them, and make regular blood moon sacrifices you can induce the desired behavior.
I think the Windows model is better. I think Linux generally handles shared libraries poorly.
You probably love Linux and think its preferences are great. That’s fine.
AFAIK, the gnu dynamic linker doesn't do any namespacing (as opposed to Solaris').
In the versioned symbols case this is done via decorating symbols in the dependent with the SONAME and version of the dependency that is expected to provide them. In direct binding this is done by decorating symbols in the dependent with just the SONAME of the dependency that is expected to provide them.
The versioned symbol technique allows a shared object to provide multiple versions of a symbol with the same name, which can be useful for some things, but direct binding is just much easier to use than versioned symbols: just add `-B direct` to the link-edits and you're done.
Even in the absence of symbol versioning and direct binding, the fact that each object records its dependencies means that symbol conflicts will be only among those dependencies, and this can be discovered at link-edit time.
LD_PRELOAD interposers, on the other hand, can cause symbol conflicts in spite of all the foregoing. For this you can use `-B protected` or similar, but you may not want to.
Seems to be a really well thought-out project.
That was my dream when I worked on the TensorFlow team. One of the questions I asked myself is, if a MatMul kernel takes milliseconds to perform an op, and it takes microseconds to launch a subprocess, then why do I need to dynamically link a 50mb TensorFlow DSO when I can just whip up a simple C program to perform the very small amount of native math, system calls, and data crunching that I need for TensorBoard?
Well, now with Cosmopolitan, it's finally possible. Just whip up the ~100 or so lines of C/C++ code that's impossible to do with Python into a small fat static APE binary, and vendor that program like any other .txt or .dat file asset. Then launch it when you need to, while never caring or needing to worry about shipping multiple .whl files or setting up Jenkins build farms for BSDs, Windows, etc. Life stays easy.
On my laptop (ASUS GA503QM, 5800HS), running /usr/bin/true to completion takes around 400μs, demonstrated by these three different approaches to spawning a thousand processes:
$ python -m timeit -n 1000 --setup 'import subprocess' 'subprocess.run(["/usr/bin/true"])'
1000 loops, best of 5: 441 usec per loop
$ rustc -o x - <<<'fn main() {
for _ in 0..1000 {
let _ = std::process::Command::new("/usr/bin/true").status();
}
}' && time ./x
./x 0.33s user 0.07s system 99% cpu 0.402 total
$ time (i=0; while [ $i -lt 1000 ]; do i=$(($i + 1)); /usr/bin/true; done)
[elided] 0.66s user 0.43s system 100% cpu 1.088 total
If you’re going to be using such calls often, spawning just one persistent process and using IPC for I/O is likely to be much faster.
Indeed.
> I’m not certain of the current state though I think it improved a few years ago
It did? I feel like it gets slower and slower every time.
> I believe it’s still considerably more than one millisecond; 10–20ms is the vague number that’s lodged in my memory, but not supported, and I can’t test it now. (I invite anyone running Windows to provide figures.)
Yep. On the Windows 10 machine I have it's around 4ms, though that's antivirus and other similar sources of slowness disabled. You could probably get it closer to 2-3ms on a faster machine, but that's the ballpark.
PyTorch and the neural net implementations built on it are the whole reason I'm using Python at all. If the answer was "build the native extensions you need for PyTorch/etc into the Python binary" that would be fine too, I have no love for dynamic library loading. But I don't see the PyTorch team going out of their way to change anything about their build process or runtime to work with Cosmopolitan, as much as I wish they would, so my guess is I won't be able to use Cosmopolitan Python for the foreseeable future.
I personally haven't been focusing on bare metal support myself the past several months, but we've got a talented member of the team (tkchia) who actively works on maintaining metal and expanding its capabilities. See also the list of supported system calls for bare metal here: https://justine.lol/cosmopolitan/functions.html As you can see, we still have a lot of work to do. But it's really cool to have, and I have high hopes for it someday as a cloud native deployment format. Hypervisors are in many ways the new OSes, so why do we need a traditional OS in-between?
- Nevertheless, well done!
Nevertheless - well done!
Anyone knows roughly how it is broken down? Because that seems massive for a small team. Or is it counting the LOCs of softwares it has wrapped up/fork of libc?
$ for x in ape examples libc/* tool/* net/* test/*/*; do echo $x $(wc -l $x/*.{c,cc,S,h,sh,mk,inc} $x/*/*.{c,cc,S,h,sh,inc} $x/*/*/*.{c,S,h,sh} $x/*.S | tail -n1 | awk1); done 2>/dev/null | sort -nrk2 | head -n25
libc/calls 38690
libc/tinymath 33400 (mostly copied from fdlibm/arm/musl/freebsd/openbsd actually)
libc/intrin 28243 (a good chunk of this is from arm and llvm)
libc/nt 26738 (it's just win32 interface boilerplate)
libc/stdio 21829
examples 19740 (a big chunk of that is actually dash)
libc/sysv 18305
tool/build 17811
test/libc/xed 17581 (mostly generated actually)
libc/nexgen32e 16695
tool/net 15058
libc/str 12150
tool/viz 11511
libc/runtime 10823
test/libc/calls 9460
ape 7507
libc/sock 7436
tool/plinko 7075
libc/proc 6956
net/http 6901
libc/thread 6757
libc/vga 5518
test/libc/stdio 5057
libc/log 4759
libc/time 4749
test/libc/tinymath 4555
libc/testlib 4217
If you haven't and you're on Firefox, go to `about:preferences#privacy`, then scroll to the bottom and you should be able to activate it there.
I'm not sure how common it is for hosting providers to allow that kind of traffic (I think many do not) and I'm not sure how their privacy policy for that kind of use compares to others but at least they don't try to MITM traffic. Occasionally I get sites that simply block the address range (like Wikipedia for editing last I checked, although viewing works fine) and limitations or oddities will likely be worse at first (Google really wanted to redirect me to their Hong Kong search page for a while when I first stared doing this) but it is rare that I have an issue now. I'm also on CenturyLink (which I chose as still better than Comcast since you can at least use your own device) and I recommend this method (also helpful when using wifi). Another potential downside is that you don't get the local CDN caches, which I'd guess most impacts the online movie services (I don't use them and only have a 12mbps download anyway so it would hardly be the bottleneck). I think routing DNS through SOCKS helps get the closest CDN locations to the proxy (at least using encrypted DNS is a must since CenturyLink messes with that too if you try to use another DNS provider unencrypted).
jart@nightmare:~$ /opt/cosmos/bin/assimilate --help
assimilate: illegal option -- -
actually portable executable assimilate v1.6
copyright 2023 justine alexandra roberts tunney
usage: assimilate [-xapembfchv] [-o PATH] FILE...
-h show help
-v show version
-f ignore soft errors
-b don't remove freebsd from elf os/abi
-c clobber input path w/o making backup
-e convert to elf regardless of host os
-m convert to macho regardless of host os
-x convert to amd64 regardless of host cpu
-a convert to arm64 regardless of host cpu
-p convert to ppc64 regardless of host cpu
-o PATH write modified binary to different file
Once assimilated, you're free to turn it into a setuid binary.
We also have patches in flight for the Linux Kernel as well as BSDs, to make APE native. https://justine.lol/ape.patch
Is there an actual written spec somewhere describing how this works? What happens if the APE embeds an ELF header and something else? Or multiple ELF headers?
ISTM if this thing goes in the Linux kernel (and maybe a BSD kernel and maybe a Windows kernel, yeah right), it should at least be written down cleanly. It doesn’t necessarily need to be a PDF. (Linux can load ELF files. ELF has a spec or five that are only mostly horrible, and I’m not actually aware of a unified ELF spec that covers everything, but this isn’t really a showstopper.)
Off the top of my head, it seems like it would be nice for whatever bit of the shell-compatible header encodes an ELF header to also indicate that it’s ELF (as opposed to something else) and maybe even that it’s Linux-flavored ELF. Maybe like:
#ELF-Linux-LE print…
#ELF-BSD-LE print…
#ELF-U-boot-BE print…
This isn’t intended to be a real proposal. Little- and big-endian in the same binary would be even more amusing than the average APE binary, and I don’t remember off the top of my head exactly which properties of the target can be unambiguously determined from the binary encoding of the ELF header.
(And obviously there would be some shell-flavored conditions in the middle.)
With that in mind, is there a "slim binary" mode that lets me only export the code to run the binaries on my system, so that I can reap these benefits for personal use without added "bloat" for a feature that I won't need? (where "bloat" is contextual, with the current context being "not actually planning to make use of portability")
That predefined mode is actually a friendly wrapper around a more generalized platform support system Cosmopolitan offers, which is called `-DSUPPORT_VECTOR` where you can define a bitset of specifically what platforms you want to be supported. Then dead code elimination takes care of the rest. The same concept also generally applies to microarchitecture support, where you can have as much or as little runtime dispatching as you want.
> In the Cosmos, every program is statically linked and contains a PKZIP central directory where its /usr/share dependencies are embedded.
Sounds really neat, even the data and configuration files are linked into the executable. Can't wait to see what else you'll come up with.
Just kidding, I’ve played around with some of the stuff @jart and other contributors have created and it’s mind blowing. Well done and keep up the good work.
I ended up finding a solution:
> If you want to run them on Windows, then you simply need to rename the file so that it has the .com suffix. Better yet, consider making that a symlink (a.k.a. reparse point).
What does this refer to?
The latest POSIX standard was released 2007. [1]
I still have no idea what the quote is referring to, though, and given Justine’s slightly (deliberately?) unhinged manner of writing, I’d give even odds the change is in fact from 2001 or something like that.
[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
I'm not sure whether the proposed changes have actually made it into a published edition of the specification.
Why not?
(say, Qt WebAssembly? ...something else?)
Or is there a even better route to run-anywhere Cosmopolitan apps with a GUI?
You can then integrate additional libraries as you please, such as sqlite3 to give yourself fast, local database access over an endpoint on the embedded HTTP/S/2 (or websocket) server.
https://github.com/pkulchenko/fullmoon
So far it's been a lovely experience and Paul is super responsive. Redbean is massively faster at startup so I can build/bounce to do hot reload in real time basically where the spring app takes about 6 seconds to start up.
Like, wouldn't you just download the binary that's been compiled specifically for the platform and architecture that you're using? Rather than relying on a potentially quite fragile method of cross-platform execution.
In a way it kind of reminds me of Urbit. Very clever, very cool, but also very niche and more of a hobbyist showcase project than anything else. Not that there's anything wrong with that of course.
Blender, GIMP, Emacs, Vim, Pidgin, Evince, Firefox, gEdit, Inkscape, Krita, FFmpeg, Python, Perl, ... I could go on and on.
Perhaps not what you intended, but I believe this is that exactly what Cosmopolitan is doing: - They are writing portable software in that it can run on various architectures and operating systems - They compile it for each platform, even if the output is a single binary - For the best performance and functionality, they mention several examples of how Cosmopolitan outperforms the native alternatives
I'm sure there are plenty of rebuttals ("Emacs on Windows is a port", "Cygwin isn't portable", "they could make the native version of $WHATEVER more performant", "Cosmopolitan isn't always faster", etc.), all of which are well and good, but would be missing the bigger picture, which is that there are reasons for both approaches (among others!) to exist, an idea that far transcends software.
But for the developer, it means setting up 9 different build pipelines and artifacts (and realistically, most won't bother with BSD builds and a lot still don't bother with arm64 builds).
It's not necessarily a huge hurdle or an unbearable expense with modern CI services, but it's still a massive deal that this project can make it all unnecessary for every single C/C++ developer out there. If this were a paid product, literally millions of companies would be happy to pay a small fee to save on CI costs, time and maintenance.
EDIT: not sure what is controversial about this statement. I'm not saying it's the only solution, but it does qualify.
I'm also kind of jealous. Like most of us I work on big systems with millions of lines of spaghetti code. I think that building very small, reliable tools like Justine's would be much more impactful work.
[0] https://web.archive.org/web/20070625105727/http://www.intel-...
That even explains part of their success: nobody pays attention to toys, and once they become ubiquitous it's too late to fight them.
I like to mention my use case when this comes up: my log file viewer (https://lnav.org) uploads an agent to remote hosts in order to tail log files on that host[1]. While lnav itself is not built using cosmo, the agent is. So, it works on multiple OSs without having to compile and include multiple versions of the agent.
Extremely cool, I will definitely check out lnav when I get a chance. I've been battling with the big players for a few months now and their systems are just so overengineered and complex for my needs that it's silly.
I just need tail -f for 10-ish servers and desktops.
I haven't even read the project readme, but I presume lnav is exactly what I wanted. Excellent!
The suite of useful tools included in the post seems like a good counter example to the claim that this is inherently not useful for anything serious.
Fat multi-arch binaries are a thing on other platforms like darwin, where they are used extremely widely. What makes this approach so different?
Sure if one wants to live in the world of UNIX before X Windows, I guess it is ok.
With that in mind, "plugins" to cross platform applications instead of standalone apps could be an interesting use case though. That's something which has typically went towards per platform, interpreted/jited, or VM'd solutions - all of which have their downsides for a typical user, don't really care about the rest of the system as much, and don't need to be anything but "behind the scenes processing" in most cases.
If this means I can FFI link against one ONNX library instead of one for linux64, Linux ARM, macOS arm, macOS Intel, android, iOS, win x64, win ARM, I'm all for it though.
I'd stay away from it unless you have a very pressing need.
My above repo contains example with the Rust standard library that build as fat executables with Cosmopolitan Libc.
I also got ripgrep to build https://github.com/ahgamut/ripgrep/tree/cosmopolitan, but it wasn't part of the cosmocc binaries because some crates that are part of the build require `#!feature(rustc_private)]` to be added to their source code. Same goes for bat and fd.
To summarize, Rust CLI tools can be built with Cosmopolitan Libc, but to build them like we can build gcc/emacs/git right now, we will need some support and Rust expertise.
Also it says it supports WASM (wasi?) so some applications might work out of the box with that.
<meta name="viewport" content="width=device-width, initial-scale=1">That is to say, it's definitely a hack but I wouldn't call it useless, at least originally. These days it's a lot less useful since the number of pages that do benefit from this treatment has decreased dramatically. But at this point the die has been cast.
Love your work! <3
- a compiler outputting a portable executable
- POSIX shims for multiple platforms that get statically linked to resulting binary
I'm not sure why it compares itself to Java, the closest thing would be Cygwin/MinGW.
If you've never read their blog or announcements before, I don't know why you would expect them to cater to you.
HN's headline policy makes it especially hard here, because the submitter can't provide context.
Its odd to think someone should not expect new user interest when they've made a new thing. Announcements are for new users and old users alike.
The first sub-title headline tells you, but it isn't clear to someone new if this is "one of the features of something" or "the thing."
> Build Once Anywhere, Run Anywhere C/C++
I clicked to the home page and then to here: https://justine.lol/cosmopolitan/
Then I understood!
> Cosmopolitan Libc makes C a build-once run-anywhere language, like Java, except it doesn't need an interpreter or virtual machine.
While anyone familiar probably finds these comments "stupid", just some helpful advice to the author - if it matters to you, there are people discovering this for the first time who might not realize what "it" is until you tell them!
That's the gripe! It's all context! Here it is with SUNSHINE 3.0.1:
After nearly one year of development, I'm pleased to announce our version 3.0.1 release of Sunshine. The project is an entirely new day. For starters, Apple sponsored our work as part of their FLOWER program. Google also awarded me an open source peer bonus for my work on Sunshine, which is a rare honor, and it's nice to see our project listed up there among the greats, e.g. OPEN, QUIT, etc. In terms of this release, we're living up to the great expectations you've all held for this project in a number of ways. The first is we invented a new widget that lets you grow large dirt which...Kinda feels like they are super intelligent alien beings from another planet trying to save us from software bloat and fragmentation.
> POSIX even changed their rules about binary in shell scripts specifically to let us do it.
I don't know what to say.
https://github.com/jart/cosmopolitan/releases/download/3.0.1... is 213MB file which contains "fat binaries" (single binaries that execute on a bewildering array of hardware platforms and operating systems) for dozens of programs, including zip, curl, git, wget, python, ctags and even my own Datasette Python application!
It's absolutely wild that this works.
I just tried it out (on macOS). I downloaded and extracted that zip and did this:
cd ~/Downloads/cosmos-3.0.1/bin
./python -c 'print(4 + 5)'
Likewise, this worked:
./datasette -m datasette -p 8000
Git works too:
./git clone https://github.com/simonw/sqlite-utils
$ unzip cosmos-3.0.1.zip
$ cd bin
$ ./python -c 'print(2+3)'
zsh: exec format error: ./pythonIt does? I would rather argue that portability between desktop OS matters today less than twenty years ago as the niches are carved out, WSL 2 becomes actually usable and the desktop metaphor as a whole declines.
should also allow anything to run without opening settings
The bigger challenge would be LLM with plugins. Those add all sorts of extra dependencies to help LLM run models directly - PyTorch, Transformers, llama-cpp-python etc.
I'd be surprised to see "llm install llm-gpt4all" work for example, since that pulls in compiled Python wheels and I'm not sure it would know which architecture to use.
pip install DOES work:
$ ./python -m pip install httpx
Defaulting to user installation because normal site-packages is not writeable
Collecting httpx
Downloading httpx-0.25.0-py3-none-any.whl (75 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 75.7/75.7 kB 2.7 MB/s eta 0:00:00
...
Successfully installed anyio-4.0.0 h11-0.14.0 httpcore-0.18.0 httpx-0.25.0 sniffio-1.3.0
$ ./python
Python 3.11.4 (heads/pypack1:65ac8ac, Oct 16 2023, 02:35:05) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import httpx
>>> httpx
<module 'httpx' from '/Users/simon/.local/lib/python3.11/site-packages/httpx/__init__.py'>
$ ls ~/.local/lib/python3.11/site-packages
anyio
anyio-4.0.0.dist-info
h11
h11-0.14.0.dist-info
httpcore
httpcore-0.18.0.dist-info
httpx
httpx-0.25.0.dist-info
sniffio
sniffio-1.3.0.dist-info
Unfortunately "./python -m pip install llm" didn't quite work, I got this:
./python -m pip install llm
Defaulting to user installation because normal site-packages is not writeable
Collecting llm
Downloading llm-0.11.1-py3-none-any.whl (36 kB)
Requirement already satisfied: click in /zip/Lib/site-packages (from llm) (8.1.6)
Collecting openai (from llm)
Downloading openai-0.28.1-py3-none-any.whl (76 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 77.0/77.0 kB 31.0 MB/s eta 0:00:00
Collecting click-default-group>=1.2.3 (from llm)
Downloading click_default_group-1.2.4-py2.py3-none-any.whl (4.1 kB)
Collecting sqlite-utils>=3.35.0 (from llm)
Downloading sqlite_utils-3.35.1-py3-none-any.whl (67 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 67.2/67.2 kB 4.9 MB/s eta 0:00:00
Collecting sqlite-migrate>=0.1a2 (from llm)
Downloading sqlite_migrate-0.1b0-py3-none-any.whl (10.0 kB)
Requirement already satisfied: pydantic>=1.10.2 in /zip/Lib/site-packages (from llm) (1.10.12)
Requirement already satisfied: PyYAML in /zip/Lib/site-packages (from llm) (6.0)
Collecting pluggy (from llm)
Downloading pluggy-1.3.0-py3-none-any.whl (18 kB)
Collecting python-ulid (from llm)
Downloading python_ulid-2.2.0-py3-none-any.whl (9.4 kB)
Requirement already satisfied: setuptools in /zip/Lib/site-packages (from llm) (68.0.0)
Requirement already satisfied: pip in /zip/Lib/site-packages (from llm) (23.1.2)
Requirement already satisfied: typing-extensions>=4.2.0 in /zip/Lib/site-packages (from pydantic>=1.10.2->llm) (4.7.1)
Collecting sqlite-fts4 (from sqlite-utils>=3.35.0->llm)
Downloading sqlite_fts4-1.0.3-py3-none-any.whl (10.0 kB)
Collecting tabulate (from sqlite-utils>=3.35.0->llm)
Downloading tabulate-0.9.0-py3-none-any.whl (35 kB)
Requirement already satisfied: python-dateutil in /zip/Lib/site-packages (from sqlite-utils>=3.35.0->llm) (2.8.2)
Requirement already satisfied: requests>=2.20 in /zip/Lib/site-packages (from openai->llm) (2.31.0)
Collecting tqdm (from openai->llm)
Downloading tqdm-4.66.1-py3-none-any.whl (78 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 78.3/78.3 kB 41.9 MB/s eta 0:00:00
Collecting aiohttp (from openai->llm)
Downloading aiohttp-3.8.6-cp311-cp311-macosx_11_0_arm64.whl (343 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 343.5/343.5 kB 3.5 MB/s eta 0:00:00
Requirement already satisfied: charset-normalizer<4,>=2 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.2.0)
Requirement already satisfied: idna<4,>=2.5 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (3.4)
Requirement already satisfied: urllib3<3,>=1.21.1 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (2.0.4)
Requirement already satisfied: certifi>=2017.4.17 in /zip/Lib/site-packages (from requests>=2.20->openai->llm) (2023.7.22)
Collecting attrs>=17.3.0 (from aiohttp->openai->llm)
Downloading attrs-23.1.0-py3-none-any.whl (61 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.2/61.2 kB 41.9 MB/s eta 0:00:00
Collecting multidict<7.0,>=4.5 (from aiohttp->openai->llm)
Downloading multidict-6.0.4-cp311-cp311-macosx_11_0_arm64.whl (29 kB)
Collecting async-timeout<5.0,>=4.0.0a3 (from aiohttp->openai->llm)
Downloading async_timeout-4.0.3-py3-none-any.whl (5.7 kB)
Collecting yarl<2.0,>=1.0 (from aiohttp->openai->llm)
Downloading yarl-1.9.2-cp311-cp311-macosx_11_0_arm64.whl (61 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 61.3/61.3 kB 427.1 kB/s eta 0:00:00
Collecting frozenlist>=1.1.1 (from aiohttp->openai->llm)
Downloading frozenlist-1.4.0-cp311-cp311-macosx_11_0_arm64.whl (46 kB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 46.7/46.7 kB 14.8 MB/s eta 0:00:00
Collecting aiosignal>=1.1.2 (from aiohttp->openai->llm)
Downloading aiosignal-1.3.1-py3-none-any.whl (7.6 kB)
Requirement already satisfied: six>=1.5 in /zip/Lib/site-packages (from python-dateutil->sqlite-utils>=3.35.0->llm) (1.16.0)
Installing collected packages: sqlite-fts4, tqdm, tabulate, python-ulid, pluggy, multidict, frozenlist, click-default-group, attrs, async-timeout, yarl, sqlite-utils, aiosignal, sqlite-migrate, aiohttp, openai, llm
ERROR: Could not install packages due to an OSError: [Errno 2] ENOENT/2/No such file or directory: '/Users/simon/.local/bin/sqlite-utils'pip install requires modifying the APE, so I end up installing pure-Python libraries as follows:
mkdir Lib
./python -m pip download httpx
unzip ./*.whl -d ./Lib
mv python python.com # in case the next step doesn't work
zip -r ./python.com Lib
mv python.com python
./python
Python 3.11.4 (heads/pypack1:65ac8ac, Oct 16 2023, 02:35:05) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> sqlite3
<module 'sqlite3' from '/zip/Lib/sqlite3/__init__.pyc'>
>>> import pathlib
>>> list(pathlib.Path("/zip").glob("*"))
[PosixPath('/zip/.symtab.amd64'), PosixPath('/zip/.symtab.arm64'), PosixPath('/zip/usr'), PosixPath('/zip/.cosmo'), PosixPath('/zip/Lib'), PosixPath('/zip/build')]
Also, to add new pure-python packages, you just need to unzip them into a local folder "./Lib", and add that folder to the APE.
Other than bash itself, does it mean it can be used to make whole set of GNU tools cross platform?
Even though Windows 10 already has Terminal and I was getting
[error 2147942405 (0x80070005) when launching `C:\bin\bash -l']
The application was unable to start correctly (0xc0000142).
PS C:\WINDOWS\system32> $ACL = Get-ACL -Path C:\Users\jtunn
PS C:\WINDOWS\system32> $ACL | Set-ACL -Path C:\bin
> It actually goes 2x faster than the native WIN32 port that the Emacs authors wrote on their own. Cosmo Emacs loads my dotfiles in 1.2 seconds whereas GNU Emacs on Windows loads them in 2.3 seconds.
Impressive stuff.
But we should keep in mind that this project is what POSIX should have been, this is a big patch to make things right, as they should have been more than 20 years ago.
It seems magical because of the failure of numerous other teams and people who never managed to tackle the portability issue with the right mindset and skills.
Most new development in tech, including software, have some dependencies on something that was not available before.
POSIX was not limited to the Unix world, the goal was for it to be implemented by all OS vendors, and it was partially done.
I must be missing something. How are you getting from "just implement POSIX interfaces" to "compile once run everywhere"?
Wouldn't the former just promise that you could compile the same source on any POSIX-compliant OSs and get a binary that runs on that OS, on that architecture?