I was mainly asking if this was even the case. If i go to the maintainers and say shit like this they b& me.
1- Not sure, I can't read; 2- Yes, Fish; 3- Yes, it fixed it.
I think that happens when app developers learn2optimize. Stop using interpreted bytecode languages on small processors!
My man we have UNIX because PDP-11 was expensive!
I posted my history
as a response to @Technus. I know about --no-install-recommends but that's an apt(1)
switch. How can I do that with dpkg(1)
? Check my history, I've been building more than I have been installing lately. Like, for a long time I have been looking for a 'useful' language to make, and then I remembered that there's a swath of programmers in my country who are addicted to Delphi, and Nkki W. has not pushed to Pascal upstream since 1974. So I decided to host a Pascal on JVM. I made ANTLR. But then, it kept complaining that some targets fail, so I had to remove them from pom.xml. I myself am new to Java toolchain tbqh. I think one language that most people build from source is NodeJS. NodejS toolchain is not as good as say, Ruby's or Guile's, but it's good enough and easy to use.
Thanks.
Podman, gotcha. I am freaking tired of these Docker-esque companies. They use their status as a FOSS application to grift people. As if it's really 'hard' to do what Docker does! It's just mixing a namespaces(7) with cgroups(7), some other stuff too, like seccomp(7). Hashicorp is one of these companies, I think you know, it went entirely closed-source a few months ago. But truly, what is so 'complex' about a secure hashtable database? GNU has one! You can use libcrypto + libtokyocabinet to make one in matter of hours. I think the issue is, most sysadmins, especially old ones, are either clueless about systems programming, or if they are, they are just too lazy to roll their own. I'm not saying 'roll your own', I'm saying, you don't necessarily need super-stable software. Companies like Hashicorp and Docker find giant customers with rich pockets, e.g. AWS, either that, or some degenerate Black-Rock-esque corporate buys them out and you know, I don't wanna prescribe anything to Americans because I don't wanna be the pot calling the kettle black, but damn, imprison those damn investment bankers! They don't understand that closed source doesn't necessarily mean 'more moola'. What it means is more obscurity, more trouble finding bugs, etc. The closed-source software died fucking ages ago. Even Micrsoft open-sourced DOS, most likely they will start open-sourcing 9x and then NT, or at least, release Windows' specs; pretty soon. Say whatever about micropeni$ but they produce more FOSS these days than closed-source software! E.g. VSCode, Terminal, TypeScript, etc (I don't use any of them, but I appreciate the gesture!).
Sorry for the rant.
I posted my uname -a, it's Pop_OS!, Debian-based but not Debian. My kernel is the latest version, I just did a fresh install and did a dist-upgrade (uname -r says 6.8.0-76060800daily20240311-generic
).
Here's my entire command history since I installed this one a few days back (I got nuthing to hide!)
So if you guys really think there's something fishy here, please do something!
Hey now, I am just a yokel from Mazar-Sharif, New York who sells dingbat carcasses for infant consumption, but does Android even use JVM? I was under the consumption it uses Dalvik? Let me consume a dingbat -- ok, so who cares what "java" gets compiled to, JIT, AOT even tree-walked, we're talking about JVM here. Here: https://sourceforge.net/projects/jasmin/ An ancient JVM bytecode assembler.
I think by 'GADTs' you mean an AST (could be mistaken). In that case, it would not be a bytecode interpreter, it would be a tree walker. In most languages, an AST is translated down to bytecode, and passed to a VM execution engine. How this engine deals with closures is highly compliant on the architecture of the AST.
First, keep this in mind: A closure is just a closure at the higher-level. Job of the AST is to translate it down to ta more abstract form, thus, a closure would most probably be inlined. Otherwise, it will be a global subroutine defined somewhere on the stack. It never makes sense not to inline closures, unless that closure is a 'hotzone', e.g. frequently used, in whcih case you should most obviously define as a subroutine, and if possible, JIT.
A VM lke NekoVM has a higher-order, terse IR with which you can handle closures like you do in JS.
Don't conflate higher-order constructs with intermediate representations. If you are interested to see a VM development in progress, star my RuppVM. Still early though. But i tend to work on it actively.
Thanks.
Are you specifying everything beforehand? If not, I'd recommend locking in on an ISA with stack effect pre-determined. Also, minimize as much as you can.
First off: Read Xia-Feng Li's excellent book if you have not.
Then.
Here are some minimization tips I am doing for my RuppVM. I just began working on it less that 24 hours ago. But the tips are based on over 6 months of off-and-on trying to make a VM, and failing. I am sure this one will take, because of these minimization efforts:
- Everything is a word: When you are reading the bytecode stream, read word-by-word, and by word I mean machine word. Don't waste your time on floats, you can implement IEEE-745 floats as a module, it will be good for practice. There's a good book for it here.
- No complex datatypes, BLESS!: So I said everything is a word, what about arrays? Structs? Basically, you need to 'bless' chunks. Blessing means taking a routine and turning it into a structure, see: Perl.
- No OS-level threads, BIND!: Just make 'green' threads, as I am doing in RuppVM. You can use the FFI to bind them to OS threads.
- Stop the World GC + Arena Allocation: Don't waste time on intricate GC, Just do stop-the-world mark and sweep, on arena-allocated memory (see my code).
- Super Basic FFI: Take a look at my
ISA.txt
file, look at what I am doing for FFI. You don't need intricate type mappings for the FFI. Just register a 'hook' to an address in memory (or ELF). - Avoid JiT/AoT for now: Don't focus on it at the beginning.
These variables are not exactly portable, but you can use them, abuse them, etc:
extern etext
-> First address past the text segment;extern edata
-> First address past the initialized data segment;extern end
-> end of bss
I think there are portable libraries for handling ELFs and PEs. You could also write your own Assembly code for it. For loading functions from files, for the FFI, these help a lot.
Another aspect you should implement is a 'signal trampoline'. This trampoline will help handle signals from the OS, and hook it to your green threads.
Now, don't take these as gospel. I am sure you know most of these already. But in case there's new info, feel free to adapt it.
Star RuppVM, I will be adding a lot of stuff to it soon.
EDIT: I looked, there does not seem to be any 'portable' libraries for handling PE and ELF with the same interface. I guess ther can't be, two different beasts.
EDIT 2: The FFI could prove to be much more complex than I thought? There's libffi though.
I know about all this
I actually began implementing my own JVM language a few days ago. I know Android uses Dalvik btw. But I guess a lot of people can use this info; infodump is always good. I do that.
btw I actually have messed around with libgcc-jit and I think at least on x86, it makes zero difference. I once did a test:
-- Find /e/ with MAWK -> 0.9s -- Find /e/ with JAWK -> 50s.
No shit! It's seriously slow.
Now compare this with go-awk: 19s.
Go has reference counting and heap etc, basically a 'compiled VM'. I think if you want fast code, ditch runtime.