libzahl - big integer library

http://git.suckless.org/libzahl/tree/
The rationale for its creation can be found on the README file.
What do you think?

But you cannot do everything alone.

That's the major problem with suckless. Because your ideas are shit, nobody wants to work with you.

>>41
Two developers would probably be enough to implement everything for one architecture. Only exceptionally large projects need more than 2 active developers. However, it is best to focus on the core and only move on to the extra functionallity once the core has been done.

>>42
Spoken like a true dumbass who has no clue what he's doing.

>>42
Pair programming with Sanae!

Unit testing with Suigintou!

>>41,43
Why don't you point out precise things you find libzahl is doing wrong instead of posting vague garbage? We get it that you don't like suckless, but so what? Is that all you wanted to say?

>>32
Say you're writing a library for simulating the effects of nuclear winters, libshtf, and you want to use libzahl internally, but don't want to expose libzahl in libshtf's interface. You also can't make assumptions about what a consuming program, say a nuclear winter visualizer (visnuke) might do. visnuke might use libzahl itself, it might not. Who then is responsible for calling zsetup? What if libshtf needs to call zsetup internally so it can clean itself up properly during an unwind, overriding anything visnuke has done. In order to chain the calls, one would have to pass in the jmp_buf originally used with the call to zsetup to libshtf, but that unnecessarily complicates libshtf's interface.

>>36
I got it working on a Debian 8 machine at my job. Wouldn't build on Void and Gentoo systems at home. It performs well on small code-fragments, but longer ones require a lot more care to how you configure the search space, otherwise it will give up or not make much progress. I haven't been able to get it to reproduce or outperform my hand-tuned assembly kernels yet, but I admittedly haven't spent enough time at it.

>>46
I don't care about what libzahl is doing. I care about the bullshit philosophy and failed ideas that suckless is promoting as somehow "correct". It's as poison to programming as fucking Islam is to modern life.

>>48
So what's the alternative? Lisp? Lisp is also dead.

>>49
You fuckheads are so fucking ignorant you can't even put together a coherent post. Did I say anything about the language at all? No. Read >>48 again, you literal retard.

>>50
Lisp isn't just a language. It's also an idea, with a philosophy behind it. We're talking about alternative philosophies here, are we not?

Seriously, what are you doing with your programming? What direction are you heading in, or looking at.

I'm not criticizing you, I'm just lamenting over the state of our field. I agree, it's all shit, and people like us on the fringe are desperately trying to find something that will bring about a new renaissance, something that will light the way to a Golden Path.

>>48

fucking Islam is to modern life.

What's wrong with Islam?

>>51
The state of the field is shit because people keep stepping back and reinventing wheels, instead of solving new problems.

The state of the field is shit because people don't even recognize problems with the field, but muddle through all the shit required due to inertia. Like the fact that source code is still fucking text files, instead of having semantic editors, or the incompatible application boundaries when you want to process data using functionality found in multiple programs. (and serialization to arbitrary text and/or bytes in the Unix way is a bullshit red herring that makes more problems than it solves)

The state of our field is shit because people focus on bytes & cycles when it's completely unnecessary, or limiting problem scopes to make things less difficult, to stroke their own cock via "programming" instead of getting real work done.

The state of our field is shit because OSes are still fundamentally based on C APIs, meaning that taint of brittleness will always be there.

Everything suckless says, does & stands for is right in the middle of the shittiest shit in the field.

>>53

Like the fact that source code is still fucking text files

What's wrong with that? Most knowledge is codified as written text anyway. Go make a game in Unity or something.

I code in DNA, mofos!

>>54
Why the fuck can't I embed rich data right in a source code file? Real binary data, images in my comments, dataflow graphs that can be executed. No, everything has to be a serial chain of character bytes, locked in order, preventing any other representation.

>>56
It's technically possible, but nobody wants to develop compilers that work with that kind of data. You might want to look into using Lisp to write a domain specific language that's designed to compile that kind of data into a computer program.

>>56,57
Terry A Davis from TempleOS did that.
Not even kidding.
https://www.youtube.com/watch?v=PCfFF9Flhp4&t=52s

>>56
If you consider that UNIX processes are like objects, and UNIX is kind of like an ad hoc programming environment that acts on text messages and operates on the filesystem, isn't processing a bunch of data using command line tools and shell scripts as glue the same thing?

>>56
it's an idea that appeals to me but it has too many problems with it - and you'll notice them when you try working with actual visual and dataflow languages, whether it's something like labview or some custom bullshit designed for an obscure game engine (I did both).

basically, we have plenty of good, varied tools for working with pure text. dozens of text editors (inb4 vi vs emacs), multiple IDEs (general purpose or language-specific), regex (which I hate but it is useful) and - if you're using a decent OS - command-line tools ranging from simple grep to DSLs like awk or sed.

the bigger your project gets the more you start noticing the lack of such tools for visual programming and dataflows. usually, you're either stuck with an annoying proprietary IDE or have to manually alter the internal representation of dataflows or whatever other bullshit your software uses. if you're lucky, you end up basically reverting to normal programming but in an obscure language. if you're unlucky, everything is represented by XML or binary blobs (keep in mind binary blobs are superior to XML because reverse engineering is actually quite fun).

Suigin and Mattias.
You may find C-Reduce useful too, in the same sense as STOKE.
https://embed.cs.utah.edu/creduce/
Should help keeping the source code even smaller and compact - less chances of bugs.

>>60
In other words, inertia of shit means sticking to said shit. Fuck you.

Thinking further, C-Reduce won't help in any way. Disregard my stupidity.

>>62
Oh, let's see your compiler so that we can shit on it too.

>>64
The focus isn't on the compiler, dickhole. Standard semantics can be fed through any given compiler. And yes, I've written tons of compilers for domain-specific projects with the features I want, except having to read multiple files to amalgamate all the formats I need.

It's just that everybody thinks that what we have with shitty text files suffices, so nobody works on anything better in the programming community & industry at large. What we have is what we know, and don't rock the boat.

And fuck you for thinking your little mind can shit on my compilers. I am superior to you in every way.

_{(this space left intentionally blank)}

>>62,64
well yeah, if I want to program something I use programming languages that already exist instead of making a new language, new OS, new computer hardware, new processor architecture, new computer and an entire new universe. if you want to create a whole new paradigm in which you program with dataflows, sound, motion controls or /prog/ shitposting then feel free to do it but don't expect everyone to do the same when they just want to write a piece of software. you don't invent new ways of baking bread, slaughtering pigs, harvesting crops, manufacturing knives and preserving meat every single time you want to eat a sandwich.

suigin's wip is finished!
hebimath is looking good.
https://github.com/suiginsoft/hebimath

I notice that both hebimath and libzahl have bechmarks.
https://github.com/suiginsoft/hebimath/tree/master/bench
http://git.suckless.org/libzahl/tree/bench

Couldn't maandree and suigin work together to unify benchmarking?

maandree's benchmarking strategy can be found on the page 17 of his document "Representing and working with almost none of the integers the suckless way" [0]

[0] http://libs.suckless.org/libzahl-paper-1.pdf

>>68
My work isn't quite done, but it was time to replace the old master branch. Some things aren't working properly yet.

I've been modifying the hebimath test fixture that comes with libzahl for benchmarking, when the time is right, I'll submit a patch for libzahl.

I can't believe it!
suigin-sama used a bashism.
Oh no!
[[ ... ]] is not defined by POSIX.

He's also using echo "$var". No good.
Read the beginning of this document.
http://www.etalabs.net/sh_tricks.html

What's libzahl exactly?
I am planing to use hebimath for my scheme, I am glad that it has rational support.

>>70
bourne shell a shit

Nevermind, I saw the multiple headers that used the other libraries at http://git.suckless.org/libzahl/tree/bench and thought that it was like a wrapper for multiple other math libraries instead of part of the benchmarking.

>>70
I'll fix it, thanks! It's not merely a bashism, I've been using mksh.

Suigin, are you planing to make manpages for the library? Also, what do the z and p directories stand for?

>>75
I'll be adding manpages and more documentation, but that's probably a month off. The library isn't quite ready for use just yet. If I didn't have a day job, I'd have it done by now. Instead, I'm plugging along at a slow and steady guacman pace.

z: integer functions, the 'z' comes from the symbol ℤ (zahlen) used for the set of integers
p: low-level SIMD packet oriented functions that operate on natural numbers

B-b-but... in the meantime, if you have any criticisms or suggestions, please feel free to air them, so I can take them into consideration and fix any problems.

Do you intend to use STOKE in the same ways as maandree, that is to get rid of assembly, but keep reasonable efficiency?

>>76
You must convince your employers that they need a new bignum library.
Make a report filled with marketing terms to get their attention. Then you can be paid to work on hebimath.

Suigin, you should delete wip branch now that it's merged.
Any advancements with STOKE so you can get rid of asm?

Also, slcon videos are out and there's one from maandree discussing libzahl. Actually, there were many great presentations this year. Did you like one in particular?