Shamar boosted

free software pol

I thought it was common knowledge among free software people, maybe even among open source people, that #gnome is not a #gnu project. Apparently I was wrong.

So I wanted to dig up a definitive reference for when Gnome left GNU. That is much harder than I expected.
Shamar boosted

@ekaitz_zarraga Btw, I managed to cross compile cat.c from Linux to with TinyCC and run it on Jehanne.

This means that, to some extent, static linking works.


tcc cat.c -m64 -nostdinc -nostdlib -g -I$JEHANNE/sys/include -I$JEHANNE/arch/amd64/include -L$JEHANNE/arch/amd64/lib$JEHANNE/arch/amd64/lib/crt* -ljehanne -static -Wl,-section-alignment=1000


I had to modify tccelf.c to use _main instead of _start as the elf starting point.

Tricky.
And a very little step forward (cat.c is very simple)

But a little hope.

Shamar boosted

9front FQA mit fruchtgeschmack

Shamar boosted

Entrevista a Ekaitz Zárraga, autor del libro “Programación en Python”

pybonacci.org/2021/04/14/entre

Shamar boosted

I have seen this claimed on reddit and imagur to be an actual composite image of a cell from "radiography, nuclear magnetic resonance and cryoelectron microscopy". Yet despite seeing it posted all over the inernet claiming its a real image I can not find a single scientific source for it. Anyone who can figure out if this is legit or not please comment.

Shamar boosted

@freemo I actually found the source, so even the density of molecules is apparently much lower than reality gaelmcgill.artstation.com/proj

Shamar boosted

Quelli del terzo segreto di satira sono bravi ma qua si superano, il loro "LOL Politik" è un capolavoro 😂

invidious.snopyta.org/watch?v=

Shamar boosted

EU Set to Ban Surveillance, Start Fines Under New AI Rules – Bloomberg ift.tt/3aadlAK

Shamar boosted

L' Unione Europea è pronta a vietare i sistemi #AI usati per la sorveglianza di massa e l'analisi #comportamentale.
Le aziende che non rispettano le nuove regole potrebbero incorrere in multe fino al 4% del fatturato.
Di Natalia #Drozdiak su #Bloomberg bloomberg.com/news/articles/20

@ekaitz_zarraga What I have in mind would be a function that take a string and return an AST. And then functions to traverse/validate/pattern match such AST.

It would not need a whole Turing complete language (and thus it should NOT be so), but could be more readable than --with-this=that -xcfs or the like.

AND the shell could do interesting things with the AST before passing to the command.

@ekaitz_zarraga Said this way, I can stop and redirect the home page to ! 😄

Probably Wirth was far ahead of... OUR times.

Shamar boosted

@Shamar So the whole Operating System is the Standard Library of the programs that run on it if you want to think about it that way. And the program execution in the shell is no more than the user living inside of the running program and calling functions from it. Just like any Lisp REPL does.

Also, you can think about it other way: programs extend the system, and they are indistinguishable from the core of it at some degree.

And you, as user-programmer, are part of the system too.

@ekaitz_zarraga technically speaking, that's true for any operating system (it is at least for and ): the program image of a program is cached so that already faulted page won't be load twice (unless there's high memory pressure and images are discarded).

This is a plain advantage of actual binaries over interpreted stuff, I think. And actually it's not easy to achieve outside kernel without an always running virtual machine.

@ekaitz_zarraga I mean: what if instead of "argc" and "argv" you had "length" and "program" where program was just a string to be interpreted in your specific (but very simple and conventional) language?

What if the shell could apply macro to commands' "programs" before calling exec()?

And what if the syntax was both homoiconic and pythonic?

Yes... I should sleep more... but it sounds VERY interesting in my head.

@ekaitz_zarraga a cheap alternative to a better solution

At times I wonder if command line arguments are half thought surrogates for a small interpreter in the standard library.

I wonder how life would be if every single command would implement his own mini language and exec() would take a string to be interpreted instead of an array of... arguments.

Such interpreter would likely be a sort of lisp (but veeery minimal..), and probably so would be the shell (but a bit more powerful).

Such approach would have interesting impacts on command line programs and general terminal UX.

I would not expect much fuss for such change kernel side.

I wonder if anybody else explored such approach (except on Lisp Machines, obviously)

Shamar boosted

@https://qoto.org/users/Shamar hello, hard to answer after a hard work day.

well, i don't know, i think they are comparable. oberon-07 is the simplest oberon compiler ever written. i actually have my implementation, that's the earliest port of wirth's compiler made in 2008. since then wirth changed his compiler a lot. i like my o7 implementation because it doesn't depend on libc, generates very compact code. but works only under 32bit linux. but because i wasn't sure i can distribute it, i started working on oberon-2 compiler by using op2 and ofront.

i recently figured out, it is not a problem so i published it, but i don't think it is very useful, compared to voc, because voc is ported to many platforms, and has a lot of libraries. i like in my o7c implementation that i have zero dependency on C code. the only deps are just GNU assembler and linker. i am thinking of writing a completely new compiler with the new parser, which won't be based on op2 or latest po13 wirth's compiler. i am thinking of supporting both o-07 and o-2 dialects in it.

so oberon-2 introduced so called 'type bound procedures' - the type of oop people tend to like.

i myself, however, whenever possible use just oberon-1 or oberon-07 style oop.

however i like that oberon-2 has syntax that explicitly mentions that a dynamic array is actually a 'POINTER TO ARRAY OF CHAR' but i know that wirth doesn't like that notation.

yes, btw, oberon-2 has dynamic arrays, oberon-07 doesn't, according to report. i think if i remember correctly, wirth's implementation has dynamic arrays that work with 'ARRAY OF CHAR' declaration.

i think overall oberon-2 and po2 based compilers are pretty mature, and a lot of code have been compiled with oberon-2, and it shown its strengths both in Oberon V4 and S3. also component pascal is basically an extension of oberon-2.

while i have an impression that wirth's latest compiler, though is a masterpiece of compiler design, and as i said, it's a simplest oberon compiler ever written, but i think it's not as mature, and it was not used as much, and therefore, debugged as much.

i like some features of oberon-07, such as read only global variable export. i also like the string assignment syntactic sugar of oberon-07, btw voc has it as well.

voc today is very practical. it works on linux/windows/macos, i used it on arm, on arm64, on many different platforms. its code is very fast, it has very low memory footprint. it is very easy to prepare wrappers to c libraries.

i wrote my irc bot with voc, it serves in several irc rooms today, including oberon room.

it's not a compiler of my dream, but it's practical.

i myself have mixed feelings, i like oberon-07, and i like oberon-2. i think it won't complicate my new compiler a lot if i support both languages in one, and have a commandline switch for the syntax check. let's see if i write it. (: i hope i'll find time. recently i am too busy at work, work under pressure, and have not much time for other activities.