Re: [dev] lex and yacc

[Louis Santillan]

On Sun, Mar 10, 2019 at 6:48 AM  wrote:
>
> On Sun, Mar 10, 2019 at 06:17:16AM +0100, Markus Wichmann wrote:
> > Well, other people have made that point before: Why use a regex to
> > identify a token when a simple loop will do?
> >
> > So for lexing, usually a simple token parser in C will do the job
> > better. And for parsing, you get the problem that yacc will create an
> > LALR parser, which is a bottom-up parser. Which may be faster but
> > doesn't allow for good error messages on faulty input ("error: expected
> > this, that, or the other token before this one"). That's why top-down
> > recursive-descent parsers (or LL(1) parsers) are superior. Maybe
> > supplemented with a shunting-yard algorithm to get the binary
> > expressions right without having to call layer after layer of functions.
>
> This is exactly what I am experiencing while coding this little/simple custom
> language parser.
> Yep, I guess lex/yacc (then GNU flex/GNU bison) are inappropriate, I even 
> would
> generalize to they do not belong in "suckless".


There's options.  Have you tried Lemon Parser [0] or miniyacc + qbe
[1][2]?  ucpp [3] lexes/parses C-like languages with C pre-processing.
re2c [4] is a great lexer.  Crockford prefers Pratt's Top-Down
Operator Precedence [5][6] and his webpage source repo even includes a
nifty lexer that is easy to translate from JS to C [7].

HTH,

[0] https://www.hwaci.com/sw/lemon/
[1] http://c9x.me/yacc/
[2] http://c9x.me/compile/
[3] https://github.com/lpsantil/ucpp
[4] http://re2c.org/
[5] http://crockford.com/javascript/tdop/tdop.html
[6] https://www.oilshell.org/blog/2016/11/02.html
[7] https://github.com/douglascrockford/TDOP/blob/master/tokens.js

Re: [dev] Xorg implementations

[Louis Santillan]

For XOrg compilation instructions/process, I'd look at CRUX's ports
[0][1].  It's at least a couple dozen ports to read through but at
least they're simple port/shell scripts.

As for Nano-X (nee, microwindows), it's an X11-like API (though not
compatible) derived from mini-X.  microwindows adds a Win32 compatible
API, and NXLib adds an X11 compatible API.  You can even add
non-accelerated OpenGL to it.  The server architecture model is closer
to classic X11 (all drivers built-in or built-out).  It was an
interesting set if code 15 years ago.  Mozilla was even ported to it,
before Mozilla obsoleted the X11-port and dedicated their time
gtk-port.

[0] http://crux.nu/ports/crux-3.3/xorg/xorg-server/Pkgfile
[1] https://crux.nu/portdb/?a=repo=xorg

On Sun, Jul 2, 2017 at 6:43 AM, Alba Pompeo  wrote:
> There's tinyxserver and the accompanying tinyxlib but they are kind of
> abandoned.
> I never tried it myself but if you do I'd be interested to know how it goes.
> https://github.com/idunham/tinyxserver
> https://github.com/idunham/tinyxlib
>
> There's also Nano-X and the accompanying nxlib but I don't know how
> they compare.
> https://github.com/ghaerr/microwindows
> https://github.com/ghaerr/nxlib
>
> Good luck.
>
>
> On Sun, Jul 2, 2017 at 8:14 AM, Hiltjo Posthuma  
> wrote:
>> On Sun, Jul 02, 2017 at 09:06:22AM +0200, Laslo Hunhold wrote:
>>>
>>> Wayland in itself actually is a very nice protocol. However, you cannot
>>> do much with it alone, as the compositor and everything on top (input
>>> handling, clipboard, keyboard-layouts, ...) have to be done by hand.
>>>
>>
>> Can you elaborate what you think is nice about the protocol vs X11 ?
>>
>> --
>> Kind regards,
>> Hiltjo
>>
>

Re: [dev] Interesting Web Browser Decoupling Concept

[Louis Santillan]

:D

On Mon, Jun 12, 2017 at 4:35 PM, Bobby Powers  wrote:
> Rendov Norra  wrote:
>> Yes, remote arbitrary code execution is already the norm. And if you
>> ask me, is precisely the reason Web browsers suck as much as they do.
>> Maybe it could be done well, but you'll have to forgive me, I've been
>> burned too many times.
>
> Fun fact, arbitrary code execution is also occasionally referred to as
> "executing a program".
>

Re: [dev] Interesting Web Browser Decoupling Concept

[Louis Santillan]

On Sun, Jun 11, 2017 at 5:19 AM, Hiltjo Posthuma <hil...@codemadness.org> wrote:
> On Sat, Jun 10, 2017 at 01:30:12PM -0700, Louis Santillan wrote:
>> https://youtu.be/1uflg7LDmzI?t=5m35s
>>
>> James Mickens calls it Project Atlantis.
>
> I could not find any Project Atlantis code, do you know where to find it?

I haven't either.  Presumably, it's locked up somewhere in MS
Research, Havard, or MIT.  :/

>
>> Make the web/content developers responsible for their own rendering
>> and content parsing.
>
> No, this is exactly what you don't want. Current accessibility is already
> terrible. I'd like it if HTML goes back to a document-based model like it was
> created instead of a "pixel-precise" rendering model. The W3C should be more
> strict when defining these standards instead of adding random battery-reading
> APIs[0]! Currently using well-formed simple HTML or (the "old") Gopher it is
> possible to display (or listen!) to the document in any way.

I think if completely human readable markups were required (my
preference would be Creole+Salt+OpenIconic), then we could improve
accessibility.  I actually have nostalgic feelings for gopher.  One
thing that was lacking in gopher was the ability to deliver
applications.  And I think the current web has proven that a
zero-install (or zero-friction install, or easily uninstallable)
application delivery platform has huge value.  Ian Hickson also
mentioned that content-neutrality [0] is important in replacing HTML5.

> In relation to HTML: I think ideally Javascript and other custom client-side
> execution should be completely removed, but some semantic-context should
> be added to the current HTML.

I think client-side script should be made entirely optional and that
content should not depend on it.  Maybe the way is to limit the amount
of code or to limit amount of content in each transfer/request.

> There are some useful things where Javascript is (ab)used right now, because
> alternatives are missing or inconsistent:
>
> - Implementations of more native missing/inconsistent control types: 
> datepicker,
>   colorpicker, etc.
> - Client-side form validation to indicate the user: should be native in HTML.
>   (similar to ).
> - Sending form data in a "dynamic" way (using XMLHttpRequest).
> - etc...

I agree with your point about the missing & inconsistent features.

[SNIP]
>
> W3C is also already "succumbing" (see editors list) to adding DRM[4] to your
> browser, wake up sheeple!

That has been disheartening.  Even more so that Mozilla (who claims to
be for the people and the web) has accepted & implemented EME [1].

>> Narrow & simplify the scope of what a browser needs to be (shouldn't
>> duplicate all the functions of an OS).  His Deny First Same Origin
[SNIP]
>
> Adding abstractions is not the solution in my opinion.
>
> It doesn't seem to simplify the scope. The rendering part is "just" given
> as responsibility to the developers and a RPC layer is added, but at this
> point you are already screwed in various ways.

Micken's intent is to reduce the abstraction.  Rendering in this case
doesn't mean the same thing in this architecture.  It's more of the
layout responsibility that CSS is supposed to fulfill.

[SNIP]
> Coming back to the real practical world: until then I try to keep my 
> (personal)
> HTML pages simple[5] and use as little Javascript as possible (no jQuery!).

I agree.  I'm planning on porting my notes over to Creole.


[0] https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
[1] https://www.eff.org/deeplinks/2016/04/save-firefox

Re: [dev] Interesting Web Browser Decoupling Concept

[Louis Santillan]

You have remote arbitrary code execution now (because of HTML, CSS,
JS, and plugins) in your current web browsers.  However, if the remote
code was effectively constrained (yes, a difficult problem [0][1][2]),
there could be hope.

The code bloat of others isn't something you have to worry about.
They optimize when they need to (or when it affects their bottom
line).  But if you could start off with a better, smaller, faster,
more secure base, would you want to?

I think, requiring PKI style handshakes (or maybe what Crockford
suggests [3]) for session oriented communications [4], communicating
only in human readable markups (like Markdown [5], ASCIIDoc [6],
Wiki/Creole [7]/Creole+Salt+OpenIconic [8]) without content
negotiation, and creating smaller API interfaces, there could be
important improvements there.

[0] https://developers.google.com/caja/
[1] http://www.adsafe.org/
[2] http://restrictmode.org/
[3] http://www.seif.place/seifhandshake.html
[4] 
https://github.com/paypal/seif-protocol/blob/master/seif-protocol-specification.pdf
[5] http://spec.commonmark.org/
[6] http://asciidoctor.org/docs/what-is-asciidoc/
[7] http://www.wikicreole.org/wiki/Creole1.0
[8] http://plantuml.com/salt

On Sun, Jun 11, 2017 at 7:53 PM, Rendov Norra <tsobf...@gmail.com> wrote:
> I fail to see how remote arbitrary code execution is a feature. Maybe
> I'm missing something.
>
> I suppose in essence it would suck less in that there'd be fewer APIs,
> but you'll just get the same lazy code and bloat that most software
> exhibits, but with the ease of visiting a webpage.
>
> On 6/10/17, Louis Santillan <lpsan...@gmail.com> wrote:
>> https://youtu.be/1uflg7LDmzI?t=5m35s
>>
>> James Mickens calls it Project Atlantis.  Make the web/content
>> developers responsible for their own rendering and content parsing.
>> Narrow & simplify the scope of what a browser needs to be (shouldn't
>> duplicate all the functions of an OS).  His Deny First Same Origin
>> Policy is also a worthy change to current standards.  This coupled
>> with some of the concepts from Seif [0] (though not the current code
>> base, I disagree with the choice of nodejs & Qt), could make web
>> browsing . . . better, safer, more performant.
>>
>> Interesting things to consider with some of the suckless ethos.
>>
>> [0] https://youtu.be/0w6tZEbrHIY
>>
>>
>

[dev] Interesting Web Browser Decoupling Concept

[Louis Santillan]

https://youtu.be/1uflg7LDmzI?t=5m35s

James Mickens calls it Project Atlantis.  Make the web/content
developers responsible for their own rendering and content parsing.
Narrow & simplify the scope of what a browser needs to be (shouldn't
duplicate all the functions of an OS).  His Deny First Same Origin
Policy is also a worthy change to current standards.  This coupled
with some of the concepts from Seif [0] (though not the current code
base, I disagree with the choice of nodejs & Qt), could make web
browsing . . . better, safer, more performant.

Interesting things to consider with some of the suckless ethos.

[0] https://youtu.be/0w6tZEbrHIY

Re: [dev] Request for name suggestions: suckless video editor

[Louis Santillan]

(ht) Hot Tub
(httm) Hot Tub Time Machine
(ufeh) *nix Flying Erase-Head (an early video editing machines)
(ued) *nix EditDroid
(vzmx) Vision Mixer


Github suggests:
(pos) psychic-octo-spork
(sdd) super-duper-doodle
(syen) symmetrical-enigma
(vpara) vigilant-parakeet
(sspoon) super-spoon



On Wed, Jan 11, 2017 at 7:56 PM, Mattias Andrée  wrote:
> On Thu, 12 Jan 2017 05:52:27 +0200
> Amer  wrote:
>
>> >I want the tools to have a common prefix of 2 to 4
>> >characters plus a dash. Any other ideas of awesome
>> >arbitrary things, I cannot think of anything else that
>> >is not already used?
>>
>> Short names were exhausted, really?)
>> At least AUR is free of them.
>>
>> eiv
>> eivy
>> evior
>> eviour
>> ouvie
>> muv
>> cvq
>> veq
>> yvi
>> vidj
>> vwet
>> koe
>> koan
>> fyu
>> hevu
>> ...
>>
>
> The name can be long, but it must have a short
> abbreviation that I can use as a prefix for the
> names of the commands.

Re: [dev] seif opinions?

[Louis Santillan]

I personally feel that Hixie's Laws of the Web (I'm trademarking that
since I just thought of it) #3 & #4 are mishandled but as a result of
the experiences of the early web.

I remember the early "mobile" web (Palm Treo 650 & BB World Edition in
2004-2009).  They weren't as bad as many people made them out to be.
Especially if sites focused on content over media.  I never did any
WAP/WML browsing [0][1] but I guess that was good for Asia & Europe
for a little while (?).

My answer to #3 is to not worry about it.  Vendors & developers
naturally respond and improve the experience (usually by removing
stuff).  MIME/Content types are then important and fallback rendering
should be something useable.  Must use "IE Edge v. 50+" is a cop out
especially if no fallback mode is provided.  I'll go somewhere else to
get that content, thank you!

I remember the early web (95-97) having dozens of plugins available to
do different things.  And they were shitty (slow, broken, etc).  And
super insecure (and the matter was compounded by the insecurity of
Windows).  They required too much of the browser's context and the
plugin's context to be shared.  Eventually the web down-selected to a
few (Java & Flash).

My answer to #4 is to have something like sandboxed plugins which act
more file extension handlers.  I really hate that my browser decides
to render a PDF for me instead of downloading it.  Browsers have
become more complex than OSes and that's not good.  Let a native app
handle it.

[0] https://en.wikipedia.org/wiki/Wireless_Application_Protocol
[1] https://en.wikipedia.org/wiki/Wireless_Markup_Language

On Mon, Sep 26, 2016 at 11:49 PM, Martin Kühne  wrote:
> So, what about the impact of #3 and #4 on the code size of modern browsers.
> That means it should be easier to understand (and implement) than DOM.
> Or is there an even harder problem?
>
> cheers!
> mar77i
>

Re: [dev] seif opinions?

[Louis Santillan]

On Sun, Sep 25, 2016 at 1:47 AM, Hiltjo Posthuma <hil...@codemadness.org> wrote:
> On Sat, Sep 24, 2016 at 10:44:33PM -0700, Louis Santillan wrote:
>> Has anybody considered seif [0][1]?
>>
>> I disagree with the choice of nodejs & Qt, and the idea of capturing
>> entropy from microphone and camera are interesting but gameable. I
>> think the overall concept is viable.
>>
>> [0] (Repo) http://www.seif.place
>> [1] (Talk) https://www.oreilly.com/ideas/the-seif-project
>>
>
> Can you give a (brief) background information what the project does?

Sorry, not brief.

The talks, the code [0][1] and the lone protocol document [2] say it
best.  A little what like the HTTPSSH [3] Sylvain was describing but
prescriptive as to the technology stack.

Instead of HTTP or HTTPS (which is HTTP+TLS these days), replace the
negotiation of the HTTP protocol with a PKI style 2 packet handshake
over TCP that are in the form of JSON messages.  All future (also
encrypted JSON message) commands & responses are then processed using
nodejs client/servers.  Instead using a markup + stylesheets (or SVG
or VRML or XForm or etc or W3C crap standard) as the presentation
layer, specify & utilize Qt.  Lastly, to support eventual replacement
of the web (instead of wholesale replacement) create & support an open
browser plugin so that seif clients/servers can be ed &
utilized in the current set of web infrastructure.  A new
browser/client/mobile app is also supportable if a large
infrastructure player (like a bank {PayPal} or healthcare provider or
etc) can provide value through it.

The specification is so far very high level and client/server examples
are relatively new.  I would have leaned towards extending a gopher
protocol like solution.

What I like:
* Use of the PKI-style handshake for secure communication without CA
infrstructure
* Non-use of HTML/CSS
* The use of JSON as command response language (almost anything is an
improvement over HTTP though)
* Use of an actual GUI command set

What I dislike:
* The specification of nodejs
* The specification of Qt (I would have been ok even a new GUI lib but
understand that this is compromise of what's available)
* The invasive & prescriptive use of hardware for entropy collection
* The lack of unencrypted fallback for human readable messages & debugging
* The lack of a document mode (or text mode) vs. application mode


[0] https://github.com/paypal/seifnode
[1] https://github.com/paypal/seif-protocol/blob/master/examples/
[2] 
https://raw.githubusercontent.com/paypal/seif-protocol/master/doc/seifhandshake.html
[3] http://lists.suckless.org/dev/1609/30541.html

[dev] seif opinions?

[Louis Santillan]

Has anybody considered seif [0][1]?

I disagree with the choice of nodejs & Qt, and the idea of capturing
entropy from microphone and camera are interesting but gameable. I
think the overall concept is viable.

[0] (Repo) http://www.seif.place
[1] (Talk) https://www.oreilly.com/ideas/the-seif-project

Re: [dev] ot: C Standard noreturn

[Louis Santillan]

On Thu, Sep 22, 2016 at 11:04 AM,   wrote:
>
> Hi,
>
> how does noreturn attribute work? Trying to get this [0] to work, I
> error on noreturn.
>
> /* Note how buffer overruns are undefined behavior and the compilers tend to
>optimize these checks away if you wrote them yourself, this only works
>robustly because the compiler did it itself. */
> extern uintptr_t __stack_chk_guard;
> noreturn void __stack_chk_fail(void);
> void foo(const char* str)
> {
> uintptr_t canary = __stack_chk_guard;
> char buffer[16];
> strcpy(buffer, str);
> if ( (canary = canary ^ __stack_chk_guard) != 0 )
> __stack_chk_fail();
> }
>
>
>
> main.c:7:10: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before 
> ‘void’
>  noreturn void __stack_chk_fail(void);
>
> tried
> void __stack_chk_fail(void) __attribute ((noreturn));
> instead.
>
>
> [0]  http://wiki.osdev.org/Stack_Smashing_Protector
>

`noreturn` is usually used in exception code, kernel code, libc [0],
or other systems code.  It signifies to the compiler, whether there is
a return type or void, that it is possible that the callee function
will not return to the caller function.  Often you will see a `while(
true );` or `for(;;);` at the end of the function to make it more
obvious for the next developer.  Adding a `noreturn` will keep the
compiler from complaining/ warning/ erroring when it encounters this
function.

For your case, you may need to add that infinite loop at the end of
the function.

[0] 
https://git.musl-libc.org/cgit/musl/tree/src/exit/_Exit.c?id=e738b8cbe64b6dd3ed9f47b6d4cd7eb2c422b38d

Re: [dev] Kilo - small, simple text editor with syntax highlighting in ~1K lines of code

[Louis Santillan]

Syntax highlighting color:
https://github.com/antirez/kilo/blob/master/kilo.c#L505

On Tue, Jul 19, 2016 at 11:07 AM, Eric Pruitt  wrote:
> On Tue, Jul 19, 2016 at 07:51:49PM +0200, lukáš Hozda wrote:
>> Oh, this looks pretty neat. How does the syntax highlighting work? Is
>> it hardcoded or are the some configuration files somewhere?
>
> It's hardcoded: https://github.com/antirez/kilo/blob/master/kilo.c#L350
>
> Eric
>

[dev] Kilo - small, simple text editor with syntax highlighting in ~1K lines of code

[Louis Santillan]

[repo] https://github.com/antirez/kilo
[blog] http://antirez.com/news/108
[demo[ https://asciinema.org/a/90r2i9bq8po03nazhqtsifksb


No curses, just 3 key bindings, and syntax highlighting.

Re: [dev] JIT & VM discussion

[Louis Santillan]

There's several examples of P-code/Pascal VMs around [0][1][2][3].
Some more detailed than others.


[0] https://en.wikipedia.org/wiki/P-code_machine#Example_machine
[1] http://www.icodeguru.com/vc/10book/books/book4/secg.htm
[2] http://blackmesatech.com/2011/12/pl0/pl0.xhtml
[3] https://github.com/lkesteloot/turbopascal


On Sat, Jun 18, 2016 at 10:39 AM, Kamil Cholewiński  wrote:
> On Sat, 18 Jun 2016, Connor Lane Smith  wrote:
>> Hi all,
>>
>> I was wondering if others had an opinion on JIT. Suppose we don't need
>> anything fancy like adaptive optimisation, but just wanted to compile
>> a program at runtime. One possibility might be to generate C code and
>> store that in a file and then call the C compiler and then execute the
>> resulting binary... But that seems a bit unpleasant, prone to
>> compilation failure, and not particularly lightweight either.
>>
>> One solution could be simply to produce assembly code, but then that
>> is tied to a specific architecture, which is unfortunate. There's also
>> LLVM, but that is a very big and complicated dependency, which
>> shouldn't really be necessary if we're just jitting something quickly
>> and don't mind it being a little unoptimised for the sake of
>> simplicity and speed of compilation. We just want to portably generate
>> machine code and then run it.
>>
>> An ideal might be something like an abstract instruction set together
>> with a JIT for the abstract machine. To be honest a JIT might not even
>> be necessary so long as it is has very little interpretation overhead,
>> the instruction set is general purpose and fixed, and it plays well
>> with the C memory model.
>>
>> Does anyone have any ideas?
>>
>> Thanks,
>> cls
>
> Hi Connor,
>
> Creating a simple and general-purpose VM shouldn't be hard! It used to
> be my favourite exercise for learning a new programming language.
>
> Probably much more difficult to get real-world performance; I wouldn't
> be surprised if the initial efforts resulted in a 1000x-slower-than-C
> execution speed for typical programs.
>
> With lots of test cases, tuning, benchmarks, and generally a lot of hard
> work, I can imagine you could bring it to the 10-100x-slower[1] class.
>
> [1]: 
> https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=python3=gcc
>
> Of course this doesn't matter that much if your purpose is mostly
> scripting behavior (games), or IO-bound stuff (as in waiting for
> database - things like Snabb[2] actually do need some real power).
> Having good C interop via FFI can save you in many cases.
>
> [2]: https://github.com/snabbco/snabb
>
> Yes, JITing is inherently architecture-specific, but the bytecode can be
> designed with trade-offs between interpretation and compilation speed.
> These days supporting x86-64, ARM and MIPS probably covers >99% of the
> devices you'll ever encounter in the wild; the rest can run a bit slower
> until someone is motivated enough to write a JIT backend.
>
> I've never had a close look at any of the Big Name VMs, as most of that
> code must suck horribly. Some real-world VMs however remained
> relatively simple - I think there might be a lot to learn from Dis[3]
> and LuaJIT[4].
>
> [3]: http://doc.cat-v.org/inferno/4th_edition/dis_VM_design
> [4]: http://luajit.org/
>
> If you have some concrete applications in mind, please do share. I'd
> gladly give a shot at prototyping something in this area.
>
> <3,K.
>

Re: [dev] [lnanosmtp]

[Louis Santillan]

On Fri, Jun 10, 2016 at 3:20 AM, FRIGN <d...@frign.de> wrote:
> On Fri, 10 Jun 2016 03:02:44 -0700
> Louis Santillan <lpsan...@gmail.com> wrote:
>
> Hey Louis,
>
>> As to justification, I'd say, that depends.  Libc (and C in general)
>> has some well known, well documented bugs that exists simply to keep
>> old code compiling (many methods that start with str*, malloc/free
>> corner but frequent cases, etc).  I'd say that's sucks.  And that is
>> why we have seen the proliferation of languages in the last 30 years
>> (since ansi c acceptance).  A condition of NIH and a far worse sin
>> than trying to fix the situation by utilizing a lower level api.
>
> can you give an example? Posix sometimes does some weird shit, but
> definitely not are bugs standardized.
> What I noticed though is that Posix likes to keep the use of "char"
> even though it means "byte".

I you pointed to a perfect example.  While extremely it is extremely
convenient for some architectures to represent strings as a pointer to
char/bytes + an implicit terminator, Pascal strings (really, a
struct/object containing pointer + length) are imminently safer.  As
is, strings in C are this ambiguous type that lie somewhere in between
pointers, arrays, and structs/objects.  Complicating this further is
the modern need for internationalization (UTF8, UCS2, UTF16,
WideChar?) which increases the ambiguity of the underlying data
storage and how to interact with it.   Making strings an object could
fix that.

>> Take Plan 9 or Go-lang.  Is that NIH?  Or is that someone
>> experimenting and/or seizing an opportunity to suck less?
>
> Woah, hold your horses there for a minute. You are comparing a
> hacky libc-wannabe-codechunk, hardcoded on top of Linux syscalls
> and arch-specific with one maintainer with Plan 9 oder Go?
>
> I would be the first to go forward and call for maybe a simpler
> approach to this whole (or)deal, however, I really don't see
> so much that would justify tipping over all existing code built
> on top of the libc and starting anew.

Does success, or scale, or commercial support, or number of developers
make an idea "the right way to do things(tm)" or well designed?  If
that's true, we all ought to change the subject to Java, JavaScript,
and C#/.Net.  Instead, I think things/ideas like suckless or Plan9 or
Go or alternatives to libc need much work and usage to prove their
worth.  There are still people waiting on Lisp and Smalltalk.

Re: [dev] [lnanosmtp]

[Louis Santillan]

On Fri, Jun 10, 2016 at 3:19 AM, Kamil Cholewiński <harry6...@gmail.com> wrote:
> On Fri, 10 Jun 2016, Louis Santillan <lpsan...@gmail.com> wrote:
>> As to justification, I'd say, that depends.  Libc (and C in general)
>> has some well known, well documented bugs that exists simply to keep
>> old code compiling (many methods that start with str*, malloc/free
>> corner but frequent cases, etc).  I'd say that's sucks.  And that is
>> why we have seen the proliferation of languages in the last 30 years
>> (since ansi c acceptance).  A condition of NIH and a far worse sin
>> than trying to fix the situation by utilizing a lower level api.
>>
>> Take Plan 9 or Go-lang.  Is that NIH?  Or is that someone
>> experimenting and/or seizing an opportunity to suckless?
>
> Very good points. However I don't think such a low-level framework
> belongs as a part of an smtpd. If libc sucks, write a better libc! But
> make sure it's well-tested, portable, bug-free, usable, uses good and
> sane interfaces, etc etc etc. Then measure adoption in applications
> versus other libnih's.

I agree Kamil.  ulinux could live (and should stand) on its own.

Re: [dev] [lnanosmtp]

[Louis Santillan]

On Friday, June 10, 2016, FRIGN <d...@frign.de> wrote:
>
> On Thu, 9 Jun 2016 23:06:54 -0700
> Louis Santillan <lpsan...@gmail.com> wrote:
>
> Hey Louis,
>
> > Good job for getting this working.  I'm a believer that suckless
> > indirectly speaks to API design in addition to software design.  There
> > are many parts of libc that suck, IMO.  Years ago, when I found Felix
> > von Leitner's talk about software design [0], and dietlibc [1], and
> > libdjb [2], and libowfat [3], I became curious about exploring other
> > runtimes for C [4][5][6][7][8][9].  Keep applying your ulinux runtime.
>
> are you joking? This reeks of NiH. In many regards, Posix has issues
> and without doubt, they can hinder you. But does it really justify
> just handrolling your own, unportable, probably buggy libc?


As to justification, I'd say, that depends.  Libc (and C in general)
has some well known, well documented bugs that exists simply to keep
old code compiling (many methods that start with str*, malloc/free
corner but frequent cases, etc).  I'd say that's sucks.  And that is
why we have seen the proliferation of languages in the last 30 years
(since ansi c acceptance).  A condition of NIH and a far worse sin
than trying to fix the situation by utilizing a lower level api.

Take Plan 9 or Go-lang.  Is that NIH?  Or is that someone
experimenting and/or seizing an opportunity to suckless?

Re: [dev] [lnanosmtp]

[Louis Santillan]

Sylvain,

Good job for getting this working.  I'm a believer that suckless
indirectly speaks to API design in addition to software design.  There
are many parts of libc that suck, IMO.  Years ago, when I found Felix
von Leitner's talk about software design [0], and dietlibc [1], and
libdjb [2], and libowfat [3], I became curious about exploring other
runtimes for C [4][5][6][7][8][9].  Keep applying your ulinux runtime.


[0] https://www.fefe.de/dietlibc/diet.pdf
[1] https://www.fefe.de/dietlibc/
[2] https://www.fefe.de/djb/
[3] https://www.fefe.de/libowfat/
[4] https://github.com/lpsantil/rt0
[5] https://github.com/lunixbochs/lib43
[6] https://gist.github.com/lpsantil/99cddf60ad6c8ae8756f
[7] http://www.erik-n.net/studies/linux_boot_c/linux_boot_c.pdf
[8] https://blogs.oracle.com/ksplice/entry/hello_from_a_libc_free
[9] http://c0.typesafety.net/tutorial/Strings.html

On Thu, Jun 9, 2016 at 6:09 PM, Sylvain BERTRAND
 wrote:
> On Thu, Jun 09, 2016 at 07:18:21PM +0200, Markus Wichmann wrote:
>> 3. smtp_line_send() can't handle short writes, because the pointer that
>> is handed in as second argument to write() is never advanced...
>
> Fixed.
>
> Thx!
>
> --
> Sylvain
>

Re: [dev] Re: Linux distros that don't suck too too much

[Louis Santillan]

On Thu, May 12, 2016 at 4:31 PM, Jason Young  wrote:
[SNIP]
> suckless is about *simplicity*. Simplicity != easy to use. Simplicity
> means, basically, there's fewer parts to break, and there *being* fewer
> parts, it's easier to see *where* it breaks. Unfortunately, the more
> "easy to use" you make a piece of software, the bigger it gets and the
> more dependencies it accrues, and you're right back at suck software.

I don't believe the second part of this paragraph is a necessary
result or consequence of suckless.  In fact, I'd argue that suckless
advocates for verified dependencies as opposed superfluous or presumed
dependencies.  I feel like the following two quotes are corollaries of
suckless.

“Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away.” - Antoine de Saint-Exupe

“Everything should be made as simple as possible, but not simpler.” -
Albert Einstein

Re: [dev] Linux distros that don't suck too too much

[Louis Santillan]

There's also CRUX [0] and tinycorelinux [1].  CRUX has more of a
BSD-style init system feel.  There's also a CruxEX [2] which includes
a DE.  However, I need to spin up a VM of AlpineLinux and see what
it's all about.

[0] https://crux.nu/
[1] http://tinycorelinux.net/
[2] http://cruxex.exton.net/

On Wed, May 11, 2016 at 3:26 PM, Marc Collin  wrote:
> Arch Linux was suckless maybe in 2008. Today it's messy, confused and bloated.
> For once, it was one of the first distributions to embrace Systemd.
> I think these emails about "what's a suckless distribution" are always
> bad, but I'll give my advice (research is on you).
>
> From most usable to least usable (as of today)
> --- Alpine Linux
> --- OpenBSD
> --- 9front
> --- stali
>
>
>
> On Wed, May 11, 2016 at 4:36 PM, Calvin Morrison  
> wrote:
>> On 11 May 2016 at 06:56, Nick  wrote:
>>> Hi folks,
>>>
>>> A few nights ago my too-expensive laptop met with too-cheap wine and now
>>> it is a far-too-expensive brick. As it's therefore time for me to
>>> install a new OS on a new laptop, I was wondering what people would
>>> recommend. I've been using Debian Stable for years now, which while it
>>> sucks does work well enough that I don't have to think about it very
>>> much, so I can do more interesting things with my time. But particularly
>>> after reading a few good articles about issues with debian [0] [1] I
>>> find myself wondering if there's a better option out there. A rolling
>>> release distribution would be fine with me, but only if it didn't break
>>> often at all; I enjoyed using Gentoo years ago when I was a student, but
>>> keeping it working took a lot of time that I do not want to dedicate to
>>> keeping a working system these days. I'd like to try something like
>>> morpheus [2], but I suspect that would take quite a lot of time and
>>> energy to get going and maintain.
>>>
>>> Any suggestions / thoughts?
>>
>> I highly recommend archlinux. The biggest benefit is the no-bullshit
>> packaging. They don't patch, they don't fix software, they simply
>> package it. If something is a problem, take it up with the software
>> developers, not the packagers. Compare that to debian who patches very
>> many packages.
>>
>

Re: [dev] [lnanohttp] nanonimal http server for linux

[Louis Santillan]

Not really.  The old asmutils httpd [0] does 100s of requests per sec
(probably thousands on modern procs), is less than 1K of disk, and,
32K of RAM per fork.   I've seen other versions which were used half
the RAM and were just as fast as well.  Just NASM compile without
SENDFILE usage.  Something in the way they're using the SENDFILE
syscall broke in more recent kernels (either syscall number changed or
parameters changed) and the httpd just waits on the kernel forever.
What's more, it's a really straight forward httpd.  Nothing really
fancy about it other than it being written in NASM.




[0] https://github.com/leto/asmutils/blob/master/src/httpd.asm


On Wed, Apr 20, 2016 at 7:22 AM, Lee Fallat  wrote:
> On Tue, Apr 19, 2016 at 11:17 PM, Sylvain BERTRAND
>  wrote:
>> Hi,
>>
>> For my personnal use, I needed a small http server. All "mini" http servers 
>> out
>> there I had a look were, IMHO,  bloaty (SDK included).
>>
>> lnanohttp is really small (including dependencies and SDK), straight on 
>> linux kernel
>> syscalls with a thin layer. Tested only on x86 and with a gcc/binutils
>> toolchain for the moment (planing to buy an armv8 raspberry board).
>>
>> Can be use easily as a base for a beefier http server.
>>
>> https://github.com/sylware/lnanohttp
>> https://repo.or.cz/lnanohttp.git
>>
>> regards,
>>
>> --
>> Sylvain
>>
>
> What do people typically use these small http servers for? I'm
> genuinely interested. I personally would make my own as an exercise.
> Probably for an embedded system. To create something as efficient as
> the bigger players though? That sounds difficult.
>

Re: [dev] [scc] issues with invoking

[Louis Santillan]

The C version of Let's Build a Compiler is here [0][1].  There are
multiple versions/recent updates by people other than Peter Gray's
original translation [2][3][4].  The original/Pascal version by Jack
Crenshaw is here [5].  I've also been reading Wirth's original Pascal
compiler writing books & works [6].  His code style is just so clear
and succinct it makes the task of (re-)learning the theory easier even
after I did a Compilers class in college with Dragon book.

[0] http://www.gtoal.com/compilers101/tinc/
[1] http://www.gtoal.com/compilers101/tinc/01_Peter_Gray/TinC_1_3/History.txt
[2] http://www.gtoal.com/compilers101/tinc/02_Graham_Toal/
[3] http://www.gtoal.com/compilers101/tinc/03_Ed_Davis/
[4] http://www.gtoal.com/compilers101/tinc/06_Rainer_Thonnes/
[5] http://compilers.iecc.com/crenshaw/
[6] https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs

On Thu, Apr 14, 2016 at 11:27 AM,   wrote:
>
>> I think compilers are way over my level, but it's a subject that interest me 
>> and
>> clang is massive c++, gcc is nonstandard bloat, tcc doesnt seem sufficient,
>> so I wanna help.
>
> There are a lot of places were helping without having a big idea about
> compilers.  The scc driver is one of the places.  Accepting flags like
> -I, -S or piping the output of cc2 to gas are things that must be
> done.
>
>> Where would be a good place to start learning?
>>
>> I have a book called "Compiler Construction: Principles and Practice", but I
>> find it very tedious.
>> If you know this book, would you say my impression is correct or am I just 
>> too
>> stupid yet for such an advanced subject?
>
> Yes, this is true.  Ususally books about compilers are really hard.
> They are usually very theoretial, and with too much mathematic.  My
> suggestion for a beginner is "Let's build a compiler".  It is a serie
> of articles about how to write a compiler without talking about the
> theory.  The original articles used Pascal, and I think there is some
> version in internet that translated it to C.
>
> Regards,
>
>

Re: [dev] suckless shared tools

[Louis Santillan]

Got a link to google repo?

On Mon, Feb 29, 2016 at 12:43 AM, Anselm R Garbe  wrote:
> On 28 February 2016 at 02:03, Daniel Kowalski  wrote:
>> Synchronization of common code between projects is built into git:
>> https://git-scm.com/docs/git-submodule
>
> git submodules are an abomination. They touch git repos for no good
> reason. If someone really wants to manage a tree of git repos,
> something like Google's repo tool is more appropriate, despite its
> ugly dependency on XML config files.
>
>> Maybe libsl should be submodule of other projects that use it?
>
> No. Each project maintainer has to make sure that his version of libsl
> is updated from time to time. But we don't force projects to break if
> someone updates libsl.
>
> Nevertheless, libsl should be the master for any adoption occurrence.
>
> -Anselm
>

Re: [dev] [surf] Switching to webkit2 as default

[Louis Santillan]

On Thu, Feb 4, 2016 at 10:16 AM, FRIGN  wrote:
> On Thu, 4 Feb 2016 17:50:05 +
> Nick  wrote:
>
> Hey Nick,
>
>> I try not to keep too abreast of things like GTK and WebKit, for the
>> sake of my sanity, but I read this[0] today which was a pretty scary
>> read, really.
>
> I also read this article a while ago.
>
>> One thing that is particularly important is that webkitgtk2 is
>> receiving security updates, whereas webkitgtk1 is not, and hasn't
>> for quite a while. I was not aware of this. Web browsing is a
>> dangerous thing, and I didn't realise quite how many known
>> vulnerabilities I have been surfing with, and would like to reduce
>> that number.
>
> Thing is, to use the only sane backend we would have to port surf
> to GTK3. I am not that deeply involved in surf development, but given
> there are other backends around (the Chrome blink backend for example
> and others) it's not an easy decision to make.
> In my humble opinion, I like the Chrome backend because they cut out
> considerable amounts of Apple legacy stuff, whereas the normal webkit
> a bit more crufted (all webkit versions are bloated).

When you say Chrome backend, are you speaking of CEF3 [0][1][2][3]?

 One of the things I don't like about the Chrome (and specifically v8)
 codebase is how google-centric the build process is.  By that I mean the
 build basically assumes you're a googler with dozens of cores and TBs of
 RAM and infrastructure to throw at the build process.  And if you're trying
 to build on your laptop, fine, it'll work, but it'll take an hour or two.
 Heck [3] says bring 6GB RAM & 40GB of disk to build a browser. :P

 [0] https://bitbucket.org/chromiumembedded/cef/wiki/Tutorial
 [1] https://bitbucket.org/chromiumembedded/cef
 [2]
 http://blog.nalates.net/2015/10/10/tutorial-chromium-embedded-framework-cef/
 [3]
 
https://bitbucket.org/chromiumembedded/cef/wiki/MasterBuildQuickStart#markdown-header-linux-setup

Re: [dev] automating running and building

[Louis Santillan]

Do mean something like this in a makefile?  Essentially adding a
`./$@` to end of `dwm` target:

```
SRC = drw.c dwm.c util.c
OBJ = ${SRC:.c=.o}

all: dwm

.c.o:
   @echo CC $<
   @${CC} -c ${CFLAGS} $<

${OBJ}: config.h config.mk


dwm: ${OBJ}
   @echo CC -o $@
   @${CC} -o $@ ${OBJ} ${LDFLAGS}
   ./$@
```

On Thu, Jan 7, 2016 at 3:53 PM, hiro <23h...@gmail.com> wrote:
> are you asking how to compile "make program; program" into a C program?
>
> On 1/7/16, Greg Reagle  wrote:
>> In the same spirit as my previous post about automating with entr ...
>>
>> I would love to be able to have some way for running a compiled C
>> program that automatically runs make on the program before actually
>> running the program.
>>
>> Of course I don't want all of my programs to work this way, but when I
>> am working on a program's source code, it would save a lot of time and
>> keystrokes.
>>
>> I know that I could use the compound command "make program; program" and
>> that is not a bad solution as far as it goes, except that if I am using
>> other programs that run/exec/fork program, then they fail to do the make
>> which I want to be automatic.
>>
>>
>

Re: [dev] automating running and building

[Louis Santillan]

Build & execute by simply typing `make`
```
SRC = dummy.c
OBJ = $(SRC:.c=.o)
EXE = dummy

all: $(EXE)
@./$(EXE)

.c.o:
$(CC) -c $(CFLAGS) $<

$(EXE): $(OBJ)
$(CC) -o $(EXE) $(OBJ) $(LDFLAGS)

```


On Thu, Jan 7, 2016 at 7:08 PM, Greg Reagle <greg.rea...@umbc.edu> wrote:
> On Thu, Jan 07, 2016 at 05:22:38PM -0800, Louis Santillan wrote:
>> Do mean something like this in a makefile?  Essentially adding a
>> `./$@` to end of `dwm` target:
>
> I tried it and it does not seem to be a solution.  If dwm is up to date,
> Make won't run the recipe and ./$@ won't be run.  So you have to use 'make
> dwm; ./dwm' every time, in which case, there is no need to modify the
> Makefile.
>

Re: [dev] Re: Font edition tooling

[Louis Santillan]

On Wed, Dec 23, 2015 at 7:09 AM, Mattias Andrée  wrote:
> On Wed, 23 Dec 2015 16:06:12 +0100
> Christian Neukirchen  wrote:
>
>> quen...@c9x.me (mpu) writes:
>>
>> > Ben Woolley  wrote:
>> >> What licenses are the tools and the font? There doesn't
>> >> seem to be a copyright statement or license anywhere.
>> >> Maybe
>> >>I am missing something obvious...
>> >
>> > The license and the font are now public domain, maybe
>> > I'll put a BSD license on the font some day, when I
>> > judge the quality makes it worth it.
>>
>> In the US and in Germany, pixel fonts can not be
>> copyrighted and are thus public domain.
>>
>
> WTF‽ That is the stupidest thing ever. They are equally
> difficult and time consuming to make.

However, the font name is copyrightable which is often way you see
similar looking fonts (possibly copied) with a derivative name.

Re: [dev] C package manager-ish

[Louis Santillan]

On Tue, Dec 15, 2015 at 9:45 AM, Mattias Andrée <maand...@kth.se> wrote:
> On Tue, 15 Dec 2015 09:10:50 -0800
> Louis Santillan <lpsan...@gmail.com> wrote:
>> On Tue, Dec 15, 2015 at 2:20 AM, Adrian Grigore
>> The small part may sound like suckless, but I find it to
>
> It should be noted that suckless is not about small
> software packages (with no reduction in the total
> size of all package), it is about simple (and clear
> and frugal) software. There is nothing in the philosophy
> saying that libraries should be split into pieces.

That was the point I was trying to make.  nodejs/npm crowd confuse
small with simple, clear, and frugal.  Everywhere you see "only 1.2kb
when gzipped!" which is a false measure of complexity, performance,
and design.

> Really, their community made something called
> "Modern JavaScript"? How vain and arrogant.

Yeah...everything after the rise to popularity of nodejs, I call
"modern JS".  As someone who started embedding SpiderMonkey JS 18
years ago, and continues today with V8, I intentionally call it
"modern JS" (lowercase m).  People are really making some dumb ass
language & ecosystem decisions these days, getting bit by the
"agile/devops/continuous delivery" bug, and adding features to JS
every other year, including many features that seem to add little or
no performance/developer productivity.  ...But I digress...

Re: [dev] C package manager-ish

[Louis Santillan]

On Tue, Dec 15, 2015 at 2:20 AM, Adrian Grigore
 wrote:
> I wanted to know what's your general opinion on https://github.com/clibs/clib.

I take issue with some of the libs included, especially tj's [0].
He's also the creator of clibs, a noted contributor to nodejs (among
other things), so I would have expected him to respect licensing &
upstream contributions better.

Overall, it's a kind of a nodejs/npm approach to C (dozens small
modules glued together to make an app).  The small part may sound like
suckless, but I find it to be less collaborative, fewer abrasive
personalities, less rigorous, and less cohesive of development process
than what suckless philosophy tends to promote.  IMO,
nodejs/npm/modern JS has a high noise to signal ratio (dozens to
hundreds of modules to do the same thing that are all incompatible and
inconsistent) while suckless is happier to produce fewer but higher
quality lines of code (and removal of code is of even higher value).

[0] 
https://github.com/clibs/jsmn/commit/8ef1413ada1b963795f15c6264aa487c95ed0779

Re: [dev] suckless bignum library

[Louis Santillan]

On Thu, Dec 10, 2015 at 10:26 AM, Mattias Andrée  wrote:
> If you are counting the informal license
> "Distribute like mad!" as a making it "public domain".
> First, that depends on jurisdiction. But!
> The README in the zipfile says it is proprietary
> (for personal use only.)

Understood.  I don't believe David wrote that code so he can't claim
copyright to it.  In any case, emails to David & Tom could probably
clear up the situation.  However, if the code does not appear useful,
no need to go through the effort.

Re: [dev] suckless bignum library

[Louis Santillan]

On Thu, Dec 10, 2015 at 10:36 AM, Greg Reagle  wrote:
> On 12/10/2015 12:57 PM, FRIGN wrote:
>>
>> What does the base have to do with the results?
>
>
> A lot.  For instance, "Many non-integral values, such as decimal 0.2, have
> an infinite place-value representation in binary (.001100110011...) but have
> a finite place-value in binary-coded decimal (0.0010). Consequently a system
> based on binary-coded decimal representations of decimal fractions avoids
> errors representing and calculating such values." from
> https://en.wikipedia.org/wiki/Binary-coded_decimal#Advantages
>

Ala the famous IEEE 754 example that became popular again with JavaScript [0].

[0] http://0.30004.com/

Re: [dev] suckless bignum library

[Louis Santillan]

On Thu, Dec 10, 2015 at 7:30 AM, FRIGN <d...@frign.de> wrote:
>
> On Wed, 9 Dec 2015 23:44:11 -0800
> Louis Santillan <lpsan...@gmail.com> wrote:
>
> > Are libtommath [0]/tomsfastmath [1] not suckless?
> >
> > [0] https://github.com/libtom/libtommath
> > [1] https://github.com/libtom/tomsfastmath
>
> too complex for my tastes, but don't get me wrong. I know that for
> numerical perfection, you have to dig out very complex methods.
> A good example here are ODE-solvers (Euler, Runge-Kutta,...).
> I think a suckless bignum library should be much more lightweight.
> In the end, we don't want to do simulations on big mainframes,
> but just a library with just enough functions to get around with
> to handle tasks like dc(1) and bc(1).


Well, buried in David Dunfield's Micro-C site and within his
mc323exa.zip [0][1][2] file under MISC/LNUM.C is a Tom St. Denis
ported version of libtommath to the 16-bit not quite ANSI Micro-C.
It's 502 sloc, and will compile with gcc 4.8.4 on Ubuntu 14.04.3 using
CFLAGS="-c -Wall -ansi -pedantic" after you massage it lightly (add
#include ) to the top.  I haven't tested it so it may make
some bad assumptions about word size, endianess, etc.  Like most of
Tom St. Denis' work, it appears to be not-copyrighted (or public
domain, "Tom St Denis (t...@dasoft.org), Jan 2000.  Distribute like
mad!!!").  See the accompanying MISC/LNUM.TXT [2].  A file list from
the header is copied below.  And if you remember SOH-CAH-TOA, you have
some trig functions as well.

[0] http://www.classiccmp.org/dunfield/dos/index.htm
[1] http://www.classiccmp.org/dunfield/dos/sample.txt
[2] http://www.classiccmp.org/dunfield/dos/mc323exa.zip

Function list
--
void l_copy(word *a, word *b) [ Copy the bignum from a to b ]
void l_clear(word *a) [ Set a to zero ]
void l_set(word *a, word n) [ Set a to the digit n ]

int l_iszero(word *a) [ is a == 0 ]
int l_cmp(word *a, word *b) [ compare a and b ]
int l_cmp_d(word *a, word b) [ compare a and 'b' ]

int l_shr(word *a, word *b) [ b = a/2  (return carry) ]
int l_shr_s(word *a) [ a = a/2  (return carry) ]
int l_shl(word *a, word *b) [ b = 2a (return carry) ]
int l_shl_s(word *a) [ a = 2a (return carry) ]

void l_add(word *a, word *b, word *c) [ c = a + b ]
void l_add_s(word *a, word *b) [ a += b ]
void l_add_d(word *a, word b) [ a += 'b' ]
void l_sub(word *a, word *b, word *c) [ c = a - b ]
void l_sub_s(word *a, word *b) [ a -= b ]
void l_sub_d(word *a, word b) [ a -= 'b']
void l_mul(word *a, word *b, word *c) [ c = ab ]
void l_mul_s(word *a, word *b) [ a *= b ]
void l_mul_d(word *a, word b) [ a *= 'b']
void l_div(word *a, word *b, word *q, word *r) [ q = a/b, r = a%b ]
void l_div_s(word *a, word *b) [ a /= b ]
void l_div_d(word *a, word b) [ a /= 'b']
void l_mod(word *a, word *b, word *c) [ c = a%b ]
void l_mod_s(word *a, word *b) [ a %= b ]
word l_mod_d(word *a, word b) [ returns a mod b ]

void l_addmod(word *a, word *b, word *m, word *c) [ c = (a+b) mod m ]
void l_submod(word *a, word *b, word *m, word *c) [ c = (a-b) mod m ]
void l_mulmod(word *a, word *b, word *m, word *c) [ c = (ab) mod m ]

void l_sqr(word *a) [ c = a^2 ]
void l_sqrmod(word *a, word *m, word *c) [ c = a^2 mod m ]
void l_expt(word *a, word *b, word *c) [ c = a^b ]
void l_exptmod(word *a, word *b, word *m, word *c)  [ c = a^b mod m ]

void l_gcd(word *a, word *b, word *c) [ c = gcd(a, b) ]
void l_lcm(word *a, word *b, word *c) [ c = lcm(a, b) ]
void l_invmod(word *a, word *n, word *b) [ b = a^-1 mod n ]
void l_sqrt(word *n, word *N) [ N = n^1/2 ]

void l_print(word *a, word radix, FILE *out) [ Output ]
void l_println(word *a, word radix, FILE *out) [ Output with new line ]

[ radixes from 2 to 64 ]
void l_toradix(word *a, word radix, char *out) [ put in buffer ]
void l_fromradix(char *a, word radix, word *b) [ read string ]

void l_readraw(word *a, unsigned char *in, int len) [ read binary ]
int l_toraw(word *a, unsigned char *out) [ write binary ]

Re: [dev] suckless bignum library

[Louis Santillan]

On Tue, Dec 8, 2015 at 7:09 AM, Marc Collin  wrote:
> A proposal of a suckless bignum library is finally taking shape.
>
> The discussion that lead to it (and is still ongoing) can be found
> here. 
> http://bbs.progrider.org/prog/read/1447711906/1,35,41,48,51,52,54,60,61,64,67-69,71-75,77,78,80,82,84-105
>
> If you're just interested in the code, it's here.
> https://github.com/suiginsoft/hebimath
>
> Just letting you guys know about the development.
> Let people know what you think and come to a solution together.
>
> Have a nice week.
>
> PS: I told suigin to write to this mailing list, but I think he forgot
> or something, so I'm doing it since I think this pertains a lot to the
> suckless discussion ML.
>

I was wondering...

Are libtommath [0]/tomsfastmath [1] not suckless?

[0] https://github.com/libtom/libtommath
[1] https://github.com/libtom/tomsfastmath

Re: [dev] Re: [farbfeld] announce

[Louis Santillan]

On Tue, Nov 17, 2015 at 4:47 PM, David Phillips  wrote:
[SNIP]
> I intend to do some more widespread testing on a large sample of
> different images which I can share the results on. But I can confirm
> that as it stands bzip2 looks likely to be the best candidate.

Try lzham [0] (for more compression, better utilization of multicore,
faster than bzip2, 7zip, zlib) or lz4 [1] (zlib level of compression
with near memcpy speed decompression).

[0] https://github.com/richgel999/lzham_codec
[1] https://github.com/Cyan4973/lz4

Re: [dev] a suckless hex editor

[Louis Santillan]

On Fri, Nov 13, 2015 at 8:55 AM, Greg Reagle  wrote:
> On 11/13/2015 11:45 AM, Alex Pilon wrote:
>>
>> xxd's provided by vim. As convenient as it is, should a "suckless hex
>> editor" really depend on that? It should be the user's choice or not to
>> install vim, regardless of anybody's feeling's on this list *either* way.
>
>
> Is there another tool that can do a reverse dump?
>
> Command od of sbase is halfway there--it can dump (od -Ax -tx1).  If it were
> enhanced to reverse dump, we could use it.
>
> On the other hand, it kind of sucks to reinvent the wheel.  Combining
> already existing tools sucks less, and xxd already exists.


tr, bc & awk?

Re: [dev] dmenu segfaults when pressing control+enter without a selection

[Louis Santillan]

On Mon, Nov 9, 2015 at 8:08 PM, Pickfire  wrote:
[SNIP]
> I am not very sure why people use int instead of booleans in C.
>
> I think stylistic code changes can make it easier to maintain on the
> early stages.

It used to be, before C99 (and newer) became as prevalent as they are
today, to portably use bools, you might include code like

#ifndef __bool_true_false_are_defined
   #ifdef _Bool
  #define bool _Bool
   #else
  #define bool char
   #endif
   #define true  1
   #define false 0
   #define __bool_true_false_are_defined 1
#endif

Nowadays, including stdbool is the way to go.

Re: [dev] Is Wayland really a solution to X11 cruft?

[Louis Santillan]

Nano-X Window System [0][1].

It's really nice that tinyxserver builds with musl.


[0] https://en.wikipedia.org/wiki/Microwindows
[1] http://www.microwindows.org/

On Fri, Oct 30, 2015 at 6:57 AM, Amadeus Folego  wrote:
> Marc, see:
>
> http://blog.mecheye.net/2012/06/the-linux-graphics-stack/#rendering-stack
>
> You'll notice how the architecture can't be improved without
> rewriting the whole application.
>
> On Fri, Oct 30, 2015 at 11:57:41AM -0200, Marc Collin wrote:
>> They don't see to know what they are trying to "fix" in the first place.
>> How about reimplementations of Xorg that actually sucks less?
>> Like https://github.com/idunham/tinyxserver for example (really far
>> from being suckless, but looks like a start).
>>
>

Re: [dev] A suckless issue tracker

[Louis Santillan]

Gopher server as a goal!  I love it.  Especially since I've been
reading up on the protocol recently.

But seriously, when I need a light-weight, private Issue Tracker, I
reach for cvstrac [0].  It supported SQLite for almost a decade before
Richard Hipp replaced it with Fossil [1].  Supports cvs, svn, git.

[0] http://www.cvstrac.org/index.html/doc/trunk/www/index.html
[1] http://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki



On Mon, Apr 6, 2015 at 3:54 PM, Mattias Andrée maand...@kth.se wrote:
 On Mon, 6 Apr 2015 23:08:18 +0200
 FRIGN d...@frign.de wrote:

 On Mon, 6 Apr 2015 22:58:49 +0200
 Mattias Andrée maand...@member.fsf.org wrote:

 Hey Mattias,

  Well it was on the list of software you needed,
  so I thought I could help out. (So no, it is not
  a NIH-timewaster.)
 
  I have not spent too much time researching the
  area. (But I assumed you had.) The best solution
  to the problem that I know if is bugseverywhere,
  but I think it is poorly designed and last time
  I used it, it was very buggy. I guess one could
  build a solution around it but I think that would
  be a half-assed solution.
 
  The entry in 'project ideas' as not very
  descriptive of what is needed, but I thought
  that addressed later.

 Please don't CC the mail to me directly, the ml
 doesn't work like this here. ;)

 @topic: The software list is hopelessly outdated
 in many parts (I just removed a request to port
 stuff to bionic libc, which was an obvious DoA a
 few months ago).

 Please again tell me what it does better than
 bugseverywhere than only being less bug-ridden.

 Here is a list of what I think should be implemented.
 https://raw.githubusercontent.com/maandree/sit/master/doc/goals


 Cheers

 FRIGN

Re: [dev] sbase echo.c doesn't respect POSIX

[Louis Santillan]

On Fri, Apr 3, 2015 at 4:39 AM, FRIGN d...@frign.de wrote:
 This is not WhatsApp.
 ^
 |
I love you guys!--|

:D

Re: [dev] Address to the suckless community concerning freedom

[Louis Santillan]

I meant Windows 8/10 Metro UI.

On Wed, Apr 1, 2015 at 2:35 PM, Dimitris Papastamos s...@2f30.org wrote:
 On Wed, Apr 01, 2015 at 02:11:15PM -0700, Louis Santillan wrote:
 This is more satire than an April Fool's Joke unless you've changed
 your name to Richard. :D

 Maybe a pull request/enhancement request to have ubase/sbase support
 Windows would have been more apropos.

 sbase should work on Windows with cygwin or midipix (no joke).

Re: [dev] Address to the suckless community concerning freedom

[Louis Santillan]

This is more satire than an April Fool's Joke unless you've changed
your name to Richard. :D

Maybe a pull request/enhancement request to have ubase/sbase support
Windows would have been more apropos.

On Wed, Apr 1, 2015 at 2:00 PM, Richard Stallman d...@frign.de wrote:
 [[[ To any NSA and FBI agents reading my email: please consider]]]
 [[[ whether defending the US Constitution against all enemies, ]]]
 [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

 Good evening,

 you should already know me. I am Dr. Richard Stallman, founder of the
 Free Software Foundation and the philosophic basis of Free Software.
 Don't mistake Open Source Software with Free Software, both are
 completely different concepts.

 Reading about what suckless is about, I've got the impression that
 you do not know what Free Software is about. You choose to publish
 your code under permissive licenses which in the end might be used
 by rogue states like Iran, North Korea and the USA to shoot innocent
 civilians in the world's battlefields.
 I do not agree with that in two ways:

 * Software freedom comes from control. Don't fool yourself with
 licenses which actually allow the user to use the software freely.
 You write the software, the users have to do what you want.
 Child rapists and racists use MIT and ISC licenses every day.
 Don't get into the same boat, use the GPL.

 * Permissive licenses are too complex to use! Look at all the cruft
 hidden behind the simplistic wording of these licenses.
 Our FSF lawyers took their time, did their honest job and wrote
 every possible remote direct and indirect possible use-case of the
 GPL-software you write and put it under specific terms.
 Don't worry about loopholes. You can read it all up in the license
 itself!

 suckless is ruined! What the hell am I supposed to do? Start over?
 I can't write another essay on why the GPL is the best software
 license around. Don't question my authority!

 If you are to question the truths presented by myself and the FSF,
 we will publish your name, home address and other relevant data
 on the new FSF pillory [http://www.fsf.org/pillory/] to shut you
 up.
 If you don't watch out, your deliberate attempts to subjugate the
 users and attack software freedom might turn our society into a
 police state!

 Also, try to obtain your food from Open Sores like on your foot,
 ankle, nose or buttocks. Given I can't live off my feet alone,
 I've recently tapped a new source of protein: The lice in facial
 and head hair. Happy feasting!

 --
 Dr Richard Stallman
 President, Free Software Foundation
 51 Franklin St
 Boston MA 02110
 USA
 www.fsf.org  www.gnu.org
 Skype: No way! That's nonfree (freedom-denying) software.
   Use Ekiga or an ordinary phone call.

Re: [dev] Suckless unit testing in C?

[Louis Santillan]

I'm asking an honest question here because there is a lot of wisdom on
mailing list and I very well lack that perspective.  How is main() the
unit test?  I read that almost as I don't always test, but when I do,
I do it production.

Re: [dev] Suckless unit testing in C?

[Louis Santillan]

Of course I understand there's some C++ stuff in there.  Throw it out.
Not necessary.  Two methods is all you need, his plan()  ok().
Testing, IMO, is always good.  You speak about well-designed
interfaces.  How do you know if some implementation detail change
breaks your usage?  And lets say this implementation is still
compliant to the interface.  A test could help you with that.  A
well-designed interface is still not a perfect interface, nor is it
the same thing as perfect/correct usage of such an interface.
However, those things are easy to test.  As for test coverage, a
well-designed interface deserves a well-designed test case.

On Tue, Feb 24, 2015 at 2:21 PM, FRIGN d...@frign.de wrote:
 On Tue, 24 Feb 2015 13:58:16 -0800
 Louis Santillan lpsan...@gmail.com wrote:

 Hey Louis,

 I'm a fan of TAP frameworks [0].  Very minimal, easy to roll you own,
 consumable by many Unix tools, human  machine readable.  clibs links
 to a bunch of pre-written libs as well [1].  kazuho had written this
 35 line example of a lib [2] that exports all you need to basic TAP,
 which is like 75% of all TAP.  See an example usage here [3].

 you do realize this is written in C++? Come to think of it, what's the
 purpose of that? You could use asserts then anyway. And asserts are bad,
 same applies to any unit testing in smaller projects.

 If you projects grow too large, there might be some reason to have tests,
 but as already discussed earlier, if you are careful, things won't out-
 grow on a well-designed interface and if you set up tests, they often
 end up covering one are but not the other.

 Cheers

 FRIGN

 [0] http://en.wikipedia.org/wiki/Test_Anything_Protocol
 [1] https://github.com/clibs/clib/wiki/Packages#testingquality-assurance
 [2] https://github.com/kazuho/picogc/blob/master/t/test.h
 [3] https://github.com/lpsantil/picotap/blob/master/t/test.c

 --
 FRIGN d...@frign.de

Re: [dev] Suckless unit testing in C?

[Louis Santillan]

I'm a fan of TAP frameworks [0].  Very minimal, easy to roll you own,
consumable by many Unix tools, human  machine readable.  clibs links
to a bunch of pre-written libs as well [1].  kazuho had written this
35 line example of a lib [2] that exports all you need to basic TAP,
which is like 75% of all TAP.  See an example usage here [3].

[0] http://en.wikipedia.org/wiki/Test_Anything_Protocol
[1] https://github.com/clibs/clib/wiki/Packages#testingquality-assurance
[2] https://github.com/kazuho/picogc/blob/master/t/test.h
[3] https://github.com/lpsantil/picotap/blob/master/t/test.c

On Tue, Feb 24, 2015 at 1:21 PM, Sam Dodrill shadow.h...@gmail.com wrote:
 Hey all,

 I was wondering what you all use for a suckless style unit testing
 framework in C.

 Thanks,

 --

 Sam Dodrill
 shadow.h...@gmail.com / x...@yolo-swag.com

Re: [dev] Object-Oriented C for interface safety?

[Louis Santillan]

Personally, I feel like the public/private/protected/friend (data 
code hiding) tenet of OOP is the least beneficial.  I get that it
helps make the interface contracts stronger, but that's only a concern
for me in languages that don't have strong or static typing.  Simple
Inheritance (object extension), Encapsulation (grouped data and
related code), and Polymorphism (shared interfaces) are much more
beneficial.  A better treatment for OOP in C, IMO, is Object-Oriented
Programming With ANSI-C [0][1].

[0] http://www.cs.rit.edu/~ats/books/ooc.pdf
[1] http://www.cs.rit.edu/~ats/books/ooc-14.01.03.tar.gz

On Wed, Nov 26, 2014 at 1:38 PM, Charles Thorley char...@thorley.us wrote:
 THIS IS NOT A TROLL

 I understand that there is zero love for object-oriented programming
 methodologies on this list, and I am not particularly interested in this
 strategy myself, although some languages that I like (i.e. Python) make
 it hard to avoid in many ways.  Regardless, this question is not meant
 to poll suckless devs on their feelings surrounding baroque,
 masturbatory abstraction; I know the answer to that question.

 I am attempting to learn C, and in my interweb travels I have
 encountered Object Oriented C.  One particular theme surrounding this
 approach, which I found quite interesting, was the idea of creating safe
 and robust interfaces through (relatively?) simple means; namely,
 modeling the public/private metaphor in OOP by placing
 differently-privileged code in separate files, and managing access
 through header files.  A link that describes this technique:

 http://www.embedded.com/electronics-blogs/object-oriented-c/4397794/Object-oriented-C-is-simple-

 I know just enough about programming to be intrigued by the idea, but
 not nearly enough to understand its implications in practice.  My
 questions are:

 1. Is this practice (potentially) suckless?
 2. If so, under what conditions would this be a suckless strategy?

 My apologies if this has been covered previously; googling the list did
 not suggest that this is the case, although my attempts to learn C have
 revealed that my google-fu has a giant blind spot when it comes to
 producing useful results for single-character keywords.

Re: [dev] Operating system choice

[Louis Santillan]

I'm surprised nobody has mentioned TinyCore Linux.  Not everything
about it is suckless, but at least it's frugal on resources once you
get it configured how you like.

For my development machines, I started on RedHat in the 90s and
continued on with Fedora until I found Crux around 2002.  Loved it but
maintaining and upgrading between versions is iffy.  Finally converted
Ubuntu around 2008.  Been stuck with it ever since.  Got a bunch RPi's
I play with that have Debian, XBian, XBMC, etc.  Experimented with
TinyCore Linux, Slax, Arch, CrunchBang, others.  I also maintain a few
VPSes with Ubuntu.

I eagerly await the victor of sabotage/Morpheus/sta.li.  I'd love to
get simpler and not get hit by the systemd bus.  I guess we'll see who
comes out on top.  What I'd really like is a statically linked Crux
built on busybox or toybox or sbase/ubase running the system/root
binaries off a RAM disk and apps off SSD.

For day-to-day stuff, I use OSX (Mac Mini  Mac Book Air).  It's just
too easy that way.

Re: [dev] [sbase] style

[Louis Santillan]

Returning error code doesn't work well for many asynchronous calls
(aio_*) [0].  It also makes errno (possibly) inconsistent, but I
didn't come up with that standard.  I guess someone decided that
making errno inconsistent is less of an issue than make the return
code of libc inconsistent.

[0] 
http://www.gnu.org/software/libc/manual/html_node/Asynchronous-Reads_002fWrites.html#Asynchronous-Reads_002fWrites

On Tue, Nov 18, 2014 at 8:47 AM, Dimitris Papastamos s...@2f30.org wrote:
 On Tue, Nov 18, 2014 at 11:35:04AM -0500, M Farkas-Dyck wrote:
 On 18/11/2014, Dimitris Papastamos s...@2f30.org wrote:
  On a side note here, for a failing syscall or similar, I think the
  idea is to check for  0 rather than == -1.  I am not opposed to the
  latter except that is already used less frequently in sbase.

 On an edge note, it would be much saner for many syscalls and libc
 functions to return minus the error code rather than return -1 and set
 errno, and in the future suckless-dominated world we could do so. The
 OpenBSD kernel already often does so internally. To check  0 rather
 than == -1 would ease transition.

 Yes I've always wondered.

Re: [dev] c++-style comments [was fsbm]

[Louis Santillan]

Hey...I try.  :D

On Fri, Nov 7, 2014 at 9:37 AM, koneu kone...@googlemail.com wrote:

 You disgust me.

Re: [dev] c++-style comments [was fsbm]

[Louis Santillan]

 There is one case where C++ style comment create a useful feature that I
 don't believe C style comments are able to replicate.  Some might disagree.
 In a color syntax highlighting editor in a C99 codebase, you can prefix C
 style comments with C++ style comments and get single character feature
 enable/disabling.

   //* Remove first / to disable this block
   doSomething();
   //*/

 In a color syntax highlighting editor, doSomething(); takes on normal
 highlighting when enabled, and takes on comment colored highlighting when
 disabled.  Visually, that's slightly improved over something like

   #ifdef DEBUG
   doSomething();
   #endif

 where you need to know what defines are created in your codebase, and maybe
 there is a clash with a header or deep in the header chain, and you need to
 know what defines are created on the command line.

On Thu, Nov 6, 2014 at 8:37 AM, Dimitris Papastamos s...@2f30.org wrote:
 On Thu, Nov 06, 2014 at 10:28:51AM -0500, Bobby Powers wrote:
 Can someone explain why they think /* */ sucks less than // ?  It
 doesn't seem like it is for compatibility when st and dwm require C99
 anyway.  An internet search did not turn up much, apologies if I've
 missed an obvious link or previous discussion.

 For consistency with multiline comments and for allowing the code
 to compile with C89.

 Also // looks terrible.

 And no, the fact that /* */ cannot be nested is not an argument in
 favor of //.

Re: [dev] c++-style comments [was fsbm]

[Louis Santillan]

It's a joke only if you're laughing.  Hey, it's no worse than
stringifying/blobbing a C file [0] (which works well in gcc/clang).
All people have done is game cpp and the standard.

  #define STRINGIFY(src) #src

  inline const char* Kernels() {
static const char* kernels = STRINGIFY(
  #include kernels/util.cl
  #include kernels/basic.cl
);
return kernels;
  }


[0] 
http://stackoverflow.com/questions/6502173/preprocessor-tomfoolery-stringifying-a-include

On Thu, Nov 6, 2014 at 9:45 AM, FRIGN d...@frign.de wrote:
 On Thu, 6 Nov 2014 09:34:17 -0800
 Louis Santillan lpsan...@gmail.com wrote:

  There is one case where C++ style comment create a useful feature that I
  don't believe C style comments are able to replicate.  Some might disagree.
  In a color syntax highlighting editor in a C99 codebase, you can prefix C
  style comments with C++ style comments and get single character feature
  enable/disabling.

//* Remove first / to disable this block
doSomething();
//*/

  In a color syntax highlighting editor, doSomething(); takes on normal
  highlighting when enabled, and takes on comment colored highlighting when
  disabled.

 Is this a joke?

 --
 FRIGN d...@frign.de

Re: [dev] surf rewrite for WebKit2GTK

[Louis Santillan]

FYI,

There's also quad-wheel [0] which claims ES3 compliance and based upon ANSI C.

[0] https://code.google.com/p/quad-wheel/

On Sun, Oct 26, 2014 at 9:58 PM, Louis Santillan lpsan...@gmail.com wrote:
 duktape is a great find and appears quite complete.  But still seems
 quite large.  There's also Tiny-JS [0] (2k-ish LOC), 42Tiny-JS [1] (a
 forked, enhanced, more complete version), and Espruinio [2] (same
 original author as Tiny-JS, more complete but focused on Arduino
 applications).

 [0] https://code.google.com/p/tiny-js/
 [1] https://code.google.com/p/42tiny-js/
 [2] https://github.com/espruino/Espruino


 On Sun, Oct 26, 2014 at 11:23 AM, Anthony J. Bentley anth...@cathet.us 
 wrote:
 F Hssn writes:
 On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote:
  On 10/25/14 13:41, F Hssn wrote:
 
  Following suckless's minimal philosophy, I'd be interested to find out
  ... snip ...
  latest webkit.
 
 
  Do you really want to write your own Javascript engine?
 

 Well, I hadn't thought of that but now that you mentioned, I
 downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both
 mostly C++). Then in v8 I noticed it has directories for architectures
 like arm arm64 mips mips64 ia32. I removed those directories and left
 only x87 and x64 and ended up with 333k, with 223k lines of C++ source
 files.

 To answer your question, I guess it comes down to how much time I have
 (as always) which is, not much. But I would definitely like some
 suckless cleanup in this direction, just like in other directions.

 Duktape isn't perfect but it's at least within the realm of sanity:
 http://duktape.org/

 --
 Anthony J. Bentley

Re: [dev] rebooting the web (it was: surf rewrite for WebKit2GTK)

[Louis Santillan]

Some of the ideas you identified in rebooting the web were more
clearly and concisely conveyed in Ian Hickson's Google+ post [0][1].
Specifically, Ian mentioned that anything that replaces the web will
have to be radically better (faster, easier to author in, easier to
develop for, easier to monetize).  Several people have pointed out
why other attempts like XML, XForms, Java, Flash, and .Net have
failed.  And, I agree with Crockford [2] when he states that parsing
source code like JS is better (faster, safer, portable, extensible)
than verifying bytecode (Java, .Net, Flash).

While I think 9P/Styx, I think many web developers would recognize
that as RESTful APIs [3] built on URIs/URLs, HTTP verbs, and JSON.
But, it looks like someone else has already considered porting Inferno
to the current web [4].

[0] https://plus.google.com/+IanHickson/posts/SiLdNL9MsFw
[1] http://www.sitepoint.com/will-html-ever-be-replaced/
[2] 
http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebPart2MadnessOrJustInsanity.aspx
[3] http://en.wikipedia.org/wiki/Representational_state_transfer
[4] https://code.google.com/p/limbo-machine/wiki/JS



On Tue, Oct 28, 2014 at 7:41 PM, Daniel Camolês bigat...@gmail.com wrote:
 2014-10-28 22:04 GMT-02:00 M Farkas-Dyck strake...@gmail.com:
 VM is an option, tho a less versatile one. We could use capabilities
 where available and VM elsewhere.

 Well, that's already more than twice the complexity before it even
 started to be written.

 I researched a bit on VM's and distributed systems, and there are some
 very interesting things happening. Harvard developed RockSalt[1], that
 is a formal code verifier written in 80 lines to guarantee that code
 is safe to be executed. The verifier itself have been put to formal
 verification and up to the time of the publishing of the link below,
 no breaches had been found.

 One huge disadvantage of running native code would be portability. You
 would need to cross compile and test on several plataforms to be able
 to ship software. It's highly flexible though. Google NaCl[2] follows
 this path, but its security problems were one of the motivations
 behind RockSalt.  One big advantage is the near-native speeds: they
 claim about only 5% of overhead when compared to native.

 NaCl is currently only implemented in Chrome; Mozilla doesn't want
 anything to do with it. They have asm.js, that is another way to run
 C/C++ compiled in the browser. But asm.js is 2x slower than native
 code.

 If we are talking about rebooting the web, then why point out these
 things that run from the browser? Because once such an alternative
 proves to be better than traditional web developing, it would be a
 matter of implementing the corresponding technology outside the
 browser and ditch all that garbage. With good planning a migration
 would be possible.

 Portability is a big issue, since today web browsers allow for media
 and apps distribution to a lot of different plataforms. Any solution
 that is worse than that have a lot less chances to win.

 Then there is the InfernoOS[3], which runs on the Dis virtual machine.
 There is a 50% slowdown when compared to native code, what is a lot
 better than asm.js. It is a work originated on Bell Labs, with a lot
 of high-quality man-hours behind it, and it has been ported to a lot
 of systems and architectures. In the days of Internet Explorer 4.0, it
 was even able to run as a browser plugin. And by the way, it uses 9P
 as its protocol to access local and remote resources.

 I've also found a couple of posts[4][5] talking about this with some more 
 links.

 Maybe porting Inferno to run from inside modern browsers is the way to
 start the revolution?

 References:
 [1]http://news.harvard.edu/gazette/story/2012/07/nacl-to-give-way-to-rocksalt/
 [2]https://en.wikipedia.org/wiki/Google_Native_Client
 [3]http://en.wikipedia.org/wiki/Inferno_(operating_system)
 [4]http://alexdanilo.com/?p=20
 [5]http://alexdanilo.com/?p=24

 Well, I can't say that to the grandma who wants to see her grandsons
 pictures on the Internet.

 No, but you can install a trusted graphics viewer program.

 That's the current software distribution model, with all its problems.
 That's not what we want.

Re: [dev] surf rewrite for WebKit2GTK

[Louis Santillan]

duktape is a great find and appears quite complete.  But still seems
quite large.  There's also Tiny-JS [0] (2k-ish LOC), 42Tiny-JS [1] (a
forked, enhanced, more complete version), and Espruinio [2] (same
original author as Tiny-JS, more complete but focused on Arduino
applications).

[0] https://code.google.com/p/tiny-js/
[1] https://code.google.com/p/42tiny-js/
[2] https://github.com/espruino/Espruino


On Sun, Oct 26, 2014 at 11:23 AM, Anthony J. Bentley anth...@cathet.us wrote:
 F Hssn writes:
 On Sun, Oct 26, 2014 at 12:34 AM, Andrew Hills ahi...@ednos.net wrote:
  On 10/25/14 13:41, F Hssn wrote:
 
  Following suckless's minimal philosophy, I'd be interested to find out
  ... snip ...
  latest webkit.
 
 
  Do you really want to write your own Javascript engine?
 

 Well, I hadn't thought of that but now that you mentioned, I
 downloaded v8 and spidermonkey sources, 0.5 vs 1.2 million (both
 mostly C++). Then in v8 I noticed it has directories for architectures
 like arm arm64 mips mips64 ia32. I removed those directories and left
 only x87 and x64 and ended up with 333k, with 223k lines of C++ source
 files.

 To answer your question, I guess it comes down to how much time I have
 (as always) which is, not much. But I would definitely like some
 suckless cleanup in this direction, just like in other directions.

 Duktape isn't perfect but it's at least within the realm of sanity:
 http://duktape.org/

 --
 Anthony J. Bentley

Re: [dev] unit testing

[Louis Santillan]

 I extracted kazuho's TAP code from his picogc repo [0] (example [1]).
Not 3 lines but it can be run and integrate with any TAP parser [2].

 [0] https://github.com/kazuho/picogc/blob/master/t/test.h
 [1] https://github.com/kazuho/picogc/blob/master/t/stack.cpp
 [2] http://en.wikipedia.org/wiki/Test_Anything_Protocol#List_of_TAP_parsers

On Thu, Jul 31, 2014 at 8:43 AM, Louis Santillan lpsan...@gmail.com wrote:
 I extracted kazuho's TAP code from his picogc repo [0] (example [1]). Not 3
 lines but it can be run and integrate with any TAP parser [2].

 [0] https://github.com/kazuho/picogc/blob/master/t/test.h
 [1] https://github.com/kazuho/picogc/blob/master/t/stack.cpp
 [2] http://en.wikipedia.org/wiki/Test_Anything_Protocol#List_of_TAP_parsers

Re: [dev] Introducing the imagefile-format

[Louis Santillan]

I know you're going for portability, but pulling in arpa/inet.h
doesn't seem so suckless.

The selection of bzip as the compression algorithm seems like a
compromise.  suckless flate[0], lzham[1], miniz[2], lz4/lz4hc[3],
minilzo[4], fastlz[5] maybe deserve some consideration?  flate, miniz,
lz4, miniz, minilzo, fastlz are at least much cheaper on CPU cycles
than bzip2, especially on decompression, while also having lower
SLOCs.  When dealing with images, how fast you can go from file to
buffer/display usually matters most.

[0] http://git.suckless.org/flate/tree/
[1] https://code.google.com/p/lzham/
[2] https://code.google.com/p/miniz/
[3] https://code.google.com/p/lz4/
[4] http://oldhome.schmorp.de/marc/liblzf.html
[5] https://code.google.com/p/fastlz/

Re: [dev] Top Posting (was: Backspace (was: st stutter and freeze ...))

[Louis Santillan]

When someone invents a monitor that supports displaying content that
is below the fold, first, I'll stop top posting.

Re: [dev] Suckless remote shell?

[Louis Santillan]

All we ever needed was 17 syscalls http://wiki.osdev.org/Porting_Newlib.

On Mon, Nov 4, 2013 at 9:41 AM, Andreas Krennmair a...@synflood.at wrote:
 * Alexander Huemer alexander.hue...@xx.vu [2013-11-04 15:30]:

 The only interface to the kernels the suckless.org software runs on is
 in C, the same is true for the standard librar{y,ies}. Software written
 in any other language is an indirection.


 The system call interfaces on typical suckless operating systems are
 language-agnostic. Go's syscall package doesn't wrap any C libraries, so
 there's no indirection involved.

 Andreas

Re: [dev] Suckless remote shell?

[Louis Santillan]

I wasn't suggesting anybody use newlib.  Rather, I was suggesting that
all the interface a C, or Go, or Java, or ASM program ever needs
between it and the POSIX OS is contained in 17 syscalls.  That's
about as minimal, or suckless as you can get.  The fact that the
newlib folks identified that fact is inconsequential.

On Mon, Nov 4, 2013 at 10:40 PM, koneu kone...@googlemail.com wrote:
 Louis Santillan wrote:
 All we ever needed was 17 syscalls http://wiki.osdev.org/Porting_Newlib.

 I would rather implement a syscall for each C library function than use
 newlib. - This would also make static binaries much smaller. :P

Re: [dev] [sbase] Command list

[Louis Santillan]

Late to the party, but in response to Truls email request on
10/18/2013, there's some less sucky lossless compression/decompression
code at https://code.google.com/p/miniz/ (Zip/deflate  zlib
compatible, small, fast) and https://code.google.com/p/lzham/
(nearly LZMA compression with much faster decompression, Windows only
for the time being :/).

-Louis