On Sat, Apr 04, 2020 at 03:19:13PM +, sylvain.bertr...@gmail.com wrote:
> For such basic command line, I should have connected to the xserver unix
> socket
> and should have sent directly the request.
Done (no xcb lib) then fixed. Same location on the web.
regards,
--
Sylvain
OMG!
Replying to myself: I use the client libxcb, which has inapropriate and
disgusting python code generators not to mention the horrible gnu autotools.
For such basic command line, I should have connected to the xserver unix socket
and should have sent directly the request.
This tool is not
Hi,
I was p*ssed off by this kludge which is xset (including SDK, deps, deps SDKS)
being the "only way" to turn off/on the global x11 key autorepeat (xserver
command
line option does not work, and xorg keyboard driver option does not work).
I wrote a minimal tool to do so, using xcb, some
On Fri, Mar 27, 2020 at 09:46:29PM +0100, Laslo Hunhold wrote:
> thanks for your feedback! I'm glad you like it. This is still at
> version "0", so if you have any suggestions for the API that might come
> to mind, let me know.
Huho!
How about making it "work" with "One Compilation Unit"
On Fri, Mar 27, 2020 at 10:24:52PM +0100, Laslo Hunhold wrote:
> ... This will cover 99.5% of all cases...
What do you mean? They managed to add in grapheme cluster definition some weird
edge cases up to 0.5%??
About string comparison: if I recall well, after utf-8 normalization (n11n),
strings
On Fri, Mar 27, 2020 at 08:00:58PM +, Tait Hoyem wrote:
> I would also like to avoid Warnock's dilemma.
+1
On this very mailing list we already had some exchange of thoughts about the
unicode grapheme cluster.
One question which was stuck into my head after this exchange was: how many of
For many projects, you can use the "One Compilation Unit" way: one root source
file
for one end result (shared lib/module/exe/etc).
The source tree is static and code selection happens with the C preprocessor.
--
Sylvain
Hi,
Out of the blue: I recently did switch from the "compiled" version of
youtube-dl to the use of it's raw code straight from the git repository,
because it felt starting significantly faster.
(nobody should have to use youtube-dl to get the video/dash url)
--
Sylvain
Hi,
As some may already know I am sueing the french administration which recently
(a couple of years) broke the support of no js web browsers.
The follow up would be to deal with this issue at the EU administration level
and the local W3C representatives.
I am currently trying to get a lawyer
Hi,
Coded the first iteration of a lil suckless-ish terminal audio file player
based on ffmpeg and alsa. Ofc, it's taylored for my needs. Might be of use to
some in suckless community.
It's here: https://repo.or.cz/nyanmp
--
Sylvain
On Wed, Jan 01, 2020 at 11:03:21PM +, sylvain.bertr...@gmail.com wrote:
> anyone?
I did investigate the issue with xprop:
something is clearing dota2 _NET_WM_STATE(ATOM) to an empty value after tabbing
out and back.
mplayer is fine with _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN.
Anyone?
Hi,
When I run dota2, the game, in "desktop friendly fullscreen" when I alt-tab out
and back the borders are drawn again and I have to re-enable the "desktop
friendly fullscreen" in dota2.
fullscreen is ok with mplayer though.
anyone?
--
Sylvain
On Fri, Dec 20, 2019 at 08:47:18AM +0100, Laslo Hunhold wrote:
> ... Slock does not have pam implemented ...
REALLY?!!! How is this even possible? pam is amazing! pam is beautiful!
pam makes coffee!
--
Sylvain
On Wed, Dec 18, 2019 at 06:23:03PM +0600, Enan Ajmain wrote:
> ...
> ... /etc/pam.d folder ...
> ...
pam? paaam? PAAM?? Really?
--
Sylvain
On Tue, Dec 10, 2019 at 04:09:24PM +, sylvain.bertr...@gmail.com wrote:
> Then now it is sure, something is slightly wrong somewhere.
I started to update my "font rendering" related components and while updating
fontconfig, I did trash their build system for my own and got a closer look at
Just tested with a vte based terminal with noto mono regular, no rendering pb.
Then now it is sure, something is slightly wrong somewhere.
--
Sylvain
On Fri, Dec 06, 2019 at 08:01:41PM +0200, anigger@national.shitposting.agency
wrote:
> but i use liberation mono.
I gave a shot at liberation mono and noto mono. Both have still issues at
various scales. The best rendering seems from liberation mono, my version of
noto is quite old though.
I am
On Fri, Dec 06, 2019 at 10:55:27AM -0800, Eric Pruitt wrote:
> I've had this same problem since I upgraded to Debian 10. I believe this
> is due to changes in character bounding box sizes because you can fix
> this by adjusting cwscale and chscale. On my systems, I only have
> vertical gaps, and
On Thu, Dec 05, 2019 at 11:28:30AM -0800, Varun Iyer wrote:
> You might be looking for something like the boxdraw patch:
> http://st.suckless.org/patches/boxdraw/, which performs custom rendering
> of box-drawing characters for gapless alignment.
This patch is limited to some unicode blocks. And
Hi,
I know I am walking on eggs: it seems st monospace font rendering with freetype
(I use dejavu mono) has some vertical and/or horizontal gaps (whatever the
rendering size).
To illustrate, with lynx web browser:
https://en.wikipedia.org/wiki/Box-drawing_character#Examples
I don't know what
On Tue, Sep 10, 2019 at 11:07:02PM +0200, Mattias Andrée wrote:
> I mean that if you always use same libc you only have to read it once,
> but if every problem have its own you have to read all of them. I do
> not think it changes it sucklessness. I just wasn't sure whether the
> reason was to
On Tue, Sep 10, 2019 at 06:48:17PM +0200, Mattias Andrée wrote:
> What is the point of doing your own mini-libc within the
> program? Aren't you just making it less portable and
> adding more code to read?
More code to read? Have you read the code of a standard libc? Not to mention
the SDK deps?
Hi,
For those who might be interested:
I did write a lean/suckless-ish sendmail like program:
https://rocketgit.com/user/sylware/syncsm
It is meant for devs/advanced sysadmins/very advanced users dealing themselves
with their "email server". I am currently using it (not on _this_ email address
As foreseen, json is kind of a no brainer.
I did write my own parser following like an idiot the specs.
The only trick was to be carefull that the root "element" is not a
normal "element".
It's callbacks based, like the xml parser from hijo.
json almost deserves a promotion to suckless format.
Hi,
Try to follow roughly the coding guideline from the linux kernel.
lower case, no typedefs, sized types (u8, u32, s32...) and cast in case of the
use of an external API, use of goto for "very sequential code error
management", etc.
I do even remove keywords from the already way too rich
On Wed, Jun 05, 2019 at 03:05:21PM +0200, Mattias Andrée wrote:
> Hi!
>
> What do you need from the library? If I recall correctly,
> jsonc is good enough, and have all the functionality you
> will need. If you only need to be able to parse into
> struct:s, writing a small parser is simple
On Wed, Jun 05, 2019 at 03:12:11PM +0200, Antenore Gatta wrote:
> - [0] https://github.com/vurtun/nuklear
Looks great... till you don't go support of global unicode scripts and
non pre-combined glyphs (pre-combined glyphs are deprecated in unicode)
How do you want to create a reasonable suckless
Hi,
After xml, json.
Do you know of a light json parser lib? Or json seeming being very simple,
better write a parser directly?
I have libjq from the jq command line, but this is quite a beast and don't think
it fits anymore in the suckless frame.
--
Sylvain
On Wed, May 22, 2019 at 03:19:40PM -0400, LM wrote:
> ...
If you code your own toolkit, you can decide to handle only a few "unicode
scripts". You may add a few limitations on top, and it can become way simpler
to code. This is what I did with the drop-in replacement of harfbuzz: only
basic
On Tue, May 21, 2019 at 08:27:48PM +0200, Daniel Cegiełka wrote:
> https://releases.linaro.org/archive/13.05/components/toolchain/gcc-linaro/4.7/
It was based on 4.7.3 and included the arm64/aarch64 branch. There is gcc 4.7.4
and it seems the aarch64 branch is more recent.
--
Sylvain
On Tue, May 21, 2019 at 09:27:19AM +0200, Daniel Cegiełka wrote:
> wt., 21 maj 2019 o 08:14 Michael Forney napisał(a):
> >
> > On 2019-05-20, sylvain.bertr...@gmail.com
> > wrote:
> > > Sadly, gcc-4.7 does not have an aarch64 backend and it's a pain to
> > > configure
> > > without breaking
On Mon, May 20, 2019 at 11:12:04PM -0700, Michael Forney wrote:
> Yes, I tested building gcc-9.1 with gcc-4.7.4 built by my compiler. I
> have not tried gcc-8.
It's very good news (actually less worse news than usual from the gcc world).
> At least gcc tracks the autotools-generated files in the
On Mon, May 20, 2019 at 02:55:17PM -0400, LM wrote:
> Another thing I'd want is at least minimal internationalization support
> (enough to be able to handle display and input of characters in the UTF-8
> character set).
Hi,
The only really tough thing with a GUI toolkit (C or anything else) is
On Sun, May 19, 2019 at 08:41:38PM -0700, Michael Forney wrote:
> Hi all,
>
> I know there are a number of small C compilers out there in various
> states of completion, but recently I've been working on another to add
> to the mix:
>
> https://git.sr.ht/~mcf/cc
>
> It is a C11 compiler based
On Tue, Apr 02, 2019 at 05:44:35AM +0200, Markus Wichmann wrote:
> I was being quite serious. Not everything posted on April 1st is a joke.
> I eventually got fed up with harmful.cat-v.org, because all it listed
> was derision, but no actual justification. Just like you.
In a suckless context,
> What a strange reply. Clearly *some* abstractions are good, otherwise
> we'd all be writing assembly. *How many* abstractions exactly is a
> matter of contention and personal taste. But as soon as someone
> slightly disagrees with you on a fairly minor point you resort to
> insults and "bruh
On Mon, Apr 01, 2019 at 07:34:20PM +0200, Markus Wichmann wrote:
> you aren't exactly a beacon of sunshine either. You like to make
> normative claims all over the place, but when asked to defend them, you
> only have names to call people. Maybe C++ is genuinely as horrible as
> you say. I have
God! I barely did notice we were the first of April... and I was surprised to
see ideas
so much remote from suckless stated here.
Got me guys. I fell for it.
doh!
--
Sylvain
On Sun, Mar 31, 2019 at 10:45:04PM -0700, Louis Santillan wrote:
> 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
On Wed, Mar 27, 2019 at 01:19:23PM -0700, Evan Gates wrote:
> On Wed, Mar 27, 2019 at 12:40 PM wrote:
> >
> > On Wed, Mar 27, 2019 at 07:43:04AM -0700, Evan Gates wrote:
> > Style and the amount of actually used syntax is different.
>
> I'd disagree. Once you choose a language, any choices
On Wed, Mar 27, 2019 at 07:43:04AM -0700, Evan Gates wrote:
> On Tue, Mar 26, 2019 at 11:21 AM wrote:
> > C has already a syntax way too rich and flexible. Most of the
> > linux coding guidelines is nice.
>
> There is also a style page[0] at suckless. But again style is subjective
> and the
On Tue, Mar 26, 2019 at 08:56:07PM +0100, Kurt Van Dijck wrote:
> I agree with most of your arguments
>
> > * use sized types: u8 u16 i64 float32 etc... you can use the C
> > preprocessor to fix that, but in some case, as a good tradeof (for
> > instance in
> > "object oriented C code"), add
On Tue, Mar 26, 2019 at 08:37:18PM +0100, Quentin Rameau wrote:
> > * do not use enum (hard rule)
> > * do not use typedef (hard rule)
> > * use sized types: u8 u16 i64 float32 etc... you can use the C
> > preprocessor to fix that, but in some case, as a good tradeof (for
> > instance in
> >
On Sun, Mar 24, 2019 at 10:28:35AM +0100, Thuban wrote:
> Hi,
> I want to learn C. I mean, sane C.
> What i read before was based on big IDE such as codeblocks. So, I don't
> know how to write Makefiles from scratch. (just an example).
> As an example, I found gobyexample [1] great. But it's go.
>
On Mon, Mar 25, 2019 at 10:08:28AM +0200, ab wrote:
> Expect a thousand conflicting opinions. If you're truly interested in
> programming, your best bet is to look at as many ideas as possible then
> working on your ability to sort the bullshit out.
"opinions" is the right term: subjective
Hi,
For a 2D toolkit with _global scope_, the only really hard part is proper
unicode text rendering.
Since there is no suckless grade of such rendering engine, then there is zero
chance to get a suckless _globally scoped_ toolkit.
The one and only open source component dealing with this issue
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
Hi,
I am coding a little/simple custom language parser, and I was wondering if there
are "suckless" grade alternatives to flex and bison, anyone? But wait...
That said and as of today, I still don't agree with myself on the usefullness
of lex/yacc in the first place. For instance, I am puzzled
On Tue, Feb 05, 2019 at 05:01:57AM -0500, Martin Tournoij wrote:
> as soon as you start doing more than printing raw strings.
Not even raw strings, but raw "lines" (\n added by echo).
My 3c.
--
Sylvain
On Mon, Feb 04, 2019 at 08:03:56PM +0100, Laslo Hunhold wrote:
> echo -n -e "GET / HTTP/1.1\r\nHost: localhost\r\n\r\n" | \
"My 2c": I would prefer shell "printf" than "echo -n -e"
--
Sylvain
On Sun, Feb 03, 2019 at 09:36:22AM +0100, Markus Wichmann wrote:
> At work, we're using libxml2. Since we are also using static linking,
> this has caused our firmware package to go from 20MB to 60MB unzipped.
> So I hope this helps you find a good package, by showing you where it
> isn't.
DOM
On Sat, Feb 02, 2019 at 07:31:24PM +0100, Silvan Jegen wrote:
> https://sillymon.ch/posts/slcon3.html
Thx!
Based on you results, I guess I'll give a shot at ezxml and yxml. Stream("sax")
or DOM("XPath"), don't know which one is easier to use in my case, yet.
I did notice some "XML entities" in
On Sat, Feb 02, 2019 at 01:20:16PM -0500, Sean MacLennan wrote:
> Json? Not sure what you need the xml parser for... but does it have to
> be xml?
Unfortunately, the source file is utf-8 xml.
--
Sylvain
Hi,
I am looking at xml parsers.
I am about to go expat, but I am wondering if there are some interesting
alternatives I did miss?
--
Sylvain
On Sat, Feb 02, 2019 at 07:46:37AM -0500, Greg Reagle wrote:
> I completely agree with these criticisms of C.
I don't like C.
Its syntax is way too rich already.
C is by far the most reasonable "compromise", namely, which "suckless".
--
Sylvain
Hi,
As some of you may know already, mesa, the gl/vulkan open source project did
drop the garbage which are the perl based gnu autotools for another piece of
garbage, python based meson. A few years ago, I was a fan boy of python, omfg I
do regret that, a f... lot.
As a user of my own custom
The thing I really don't understand, is this mailing list attracting some
random group of guys, at regular time intervals, almost totally missing the
point of "suckless", and though, pretending to get it while bringing on the
table _abominations_ like c++/go/whatever. Namely software perfectly
On Thu, Jan 31, 2019 at 11:57:24AM +0300, Alexander Krotov wrote:
> https://learnbchs.org/
clang/llvm LOL (this is one of the worst piles of c++ cr*p out there, a near
perfect factory of digital hate).
sqllite LOL (better think of using this 10 times over before actually using it)
For the web,
Hi,
Guys, why bothering with an obvious troll fed on google go propaganda???
come on...
--
Sylvain
Those guys are amazing. How much more toxic can they be?? I am really
suspicious of their "sponsorship" with the linux fondation. I don't think they
did grant a exFAT/FAT64 free patent use for all linux users... (event though on
most digital cameras, the 'official' file system of SDCards is
A big warning: a "standard" is not anymore sufficient. Look at the microsoft
xml document format at ISO.
It means the corporations which have an interest at making file formats
complex in order to kill any light software implementation alternative _will go
through standard bodies_. Look at what
On Tue, Jan 01, 2019 at 04:37:39PM +, fao_ wrote:
> On 2018-12-30 9:27 pm, stephen Turner wrote:
> mk(1) is nice and I use it for a lot of my personal projects.
...
> There's a Go rewrite here with some fixes. I haven't used it but those
mk on small projects? Go???
Are we still on
One is enough. As it should have been for loop constructs.
--
Sylvain
Hi,
My _OPINION_ on those tradeoffs, compilation speed/optimization/speed of
execution/execution context, where "usually" I draw my red lines:
Use of makefiles: the main rational of makefiles is to re/compile/re/link only
what is needed to generate the final products and that in order to
On Wed, Dec 26, 2018 at 09:39:29AM -0600, Cág wrote:
> Would systemd be bug-free, it would still suck. It's not only the language
> or bugs. PulseAudio is C, too ^_^
I send you back to one of my previous email why saying this is an intellectual
falacy. Let's reverse this falacy: jack is pure cr*p
On Thu, Dec 27, 2018 at 12:56:29AM +1300, Martin Tournoij wrote:
> ... AFAIK all compilers accept // these days ...
Preprocessor. I guess having 2 ways to define comments is not significant,
then better stick to one and the historical one.
--
Sylvain
On Thu, Dec 27, 2018 at 12:51:08AM +1300, Martin Tournoij wrote:
> On Wed, Dec 26, 2018, at 13:23, Sylvain Bertrand wrote:
> > Since llvm is pure c++ madness and gcc is still far from being one:
> > gnu gcc sucks less than clang/llvm. yes, GNU gcc sucks less than BSD
>
???
clang/llvm is a c++ abomination: a massive pile of c++ cr*p. If you
dislike the GNU make, wait to read the c++ code of cmake, the build
system of clang/llvm, not to mention ninja (something in the horrible
python3 or python2). I am into llvm code right now, and I feel like
working in an
On Sat, Dec 22, 2018 at 11:26:19AM +0100, Jan Bessai wrote:
> You might add that keeping things small is crucial for the described way
> of operating. Otherwise things are impossible to understand for casual
> contributors. Suckless embodies this as a core value. In your analogy
> you can DIY fix
On Fri, Oct 19, 2018 at 02:45:58PM +0200, David Demelier wrote:
> Unfortunately, I remember having terminus not rendering some kind of unicode
> characters not even emojis. I think it was some drawing characters.
If those "characters" are actually using "combined" unicode rendering, namely
using
On Sat, Sep 29, 2018 at 03:46:36PM +0200, Laslo Hunhold wrote:
> On Sat, 29 Sep 2018 12:59:15 +
> sylvain.bertr...@gmail.com wrote:
>
> Dear Sylvain,
>
> > mmmh... for the reason I stated before, the fonts files will probably
> > be more and more NFD normalization only (lighter font files,
On Fri, Sep 28, 2018 at 08:27:30PM +0200, Laslo Hunhold wrote:
> On Fri, 28 Sep 2018 13:38:03 +
> No, not even that. We only need normalization really if we want to do
> "perceptual" string comparisons, which is generally questionable for
> UNIX tools.
mmmh... for the reason I stated before,
On Fri, Sep 28, 2018 at 11:50:11AM +0200, Laslo Hunhold wrote:
> On Fri, 28 Sep 2018 02:05:20 +
> sylvain.bertr...@gmail.com wrote:
> ...
>> Well, there is something about stream safe unicode application.
>> Basically, it is a buffer of 128 bytes (32 unicode points) with a
>> continuation
On Thu, Sep 27, 2018 at 10:06:25PM +0200, Laslo Hunhold wrote:
> ...
> The function bound() just operates on relatively small LUTs and is
> pretty efficient. If we implement a font drawing library in some way,
> we will have to think about how we do this special handling right.
> Extended
Hi again,
I did dive a bit deeper in latest unicode, and it's even worst of what I
thought.
To deal with real unicode input/output and to split it in "extended graphem
clusters" (an unicode "char"), you need a finite state machine (I guess that's
what Lalso was referering to). And it's the same
On Wed, Sep 26, 2018 at 10:01:48AM +0200, Laslo Hunhold wrote:
> The vast majority of fonts uses the "native" OTF/TTF format anyway and
> will in the future, because anything else would be a waste of resources
> both on the font-developer-side and the rendering-part.
This is where I am not that
On Wed, Sep 26, 2018 at 01:06:52AM +0200, Laslo Hunhold wrote:
> On Tue, 25 Sep 2018 21:25:12 +
> sylvain.bertr...@gmail.com wrote:
> > - a full xml smile/svg vector renderer (like librsvg/expat for
> > the svg part)
>
> No, forget about SVG fonts. Nobody sane would think about
On Tue, Sep 25, 2018 at 04:28:22PM -0700, AR Garbe wrote:
> This is something I was considering, however it looks like the water
> of the babie's bathtub is poisoned with freetype2/fc bacteria. I don't
> wanna introduce abstractions that might be premature, hence I suggest
> to fully revert back
Hi again,
I did refresh my knowledge on unicode/font stuff, and yes, st will be screwed:
An unicode string has 4 canonical normalizations. But only one (NFD) seems to
be futur proof regarding what features will be supported by font files
(opentype(microsoft tm)/open font format).
Ofc, this is
On Tue, Sep 25, 2018 at 08:17:51PM +0600, Eon S. Jeon wrote:
> I use all of CJK and am not the only one who use non-Latin language in
> terminal. In the past, I too assumed I would use only English on terminal,
> but I cannot control what other people send to me. It is really stupid if I
> have to
On Mon, Sep 24, 2018 at 05:44:40PM +0200, Hadrien Lacour wrote:
> Of course, the range:font mapping is more granular, but I find it a little bit
> more complex to configure than this type of fallback.
It does as some asian fonts do contain some latin glyphs. You have to specify
the unicode range,
Hi,
It seems my previous message did not went through.
I was showing how mlterm reach this goal:
in a config file, in a table in the config header for st, a mapping
between style(bold/non-bold)/unicode range to a font name.
--
Sylvain
On Mon, Sep 24, 2018 at 09:35:11AM +0200, Hiltjo Posthuma wrote:
> > I don't think we should throw out support for a feature that more than a
> > billion
> > people on the planet rely on. That doesn't mean that we can't rethink how we
> > go about supporting that feature though.
I remember the
On Sun, Sep 23, 2018 at 09:22:00AM -0700, AR Garbe wrote:
> On Sun, 23 Sep 2018 at 06:37, wrote:
> > st has a clean wayland fork? BTW, suckless wayland compositor, still too
> > early
> > to talk about it?
And has st a wayland backend or fork?
--
Sylvain
On Sun, Sep 23, 2018 at 01:49:01PM +0200, Hiltjo Posthuma wrote:
> For st there was a X11/terminal code split to support Wayland, automated
> testing of terminal emulator code. Now there are abstractions but it is not
> useful. Maybe it should be reverted also?
Hi,
st has a clean wayland fork?
Hi,
I did install the google noto fonts, did browse to a www site with heavy use of
utf-8
emojis with lynx and did crash.
The culprit was NotoColorEmoji.ttf.
Maybe st needs hardening in glyph display or google needs to remove
NotoColorEmoji.ttf from its distribution archive.
What is the bottom
Oh! I forgot to insist on the fact that I'm not against an _optional_ const
attribute, but with different semantics than the current const keyword.
--
Sylvain
On Fri, Oct 13, 2017 at 07:57:16PM -0400, Alex Pilon wrote:
> On Fri, Oct 13, 2017 at 10:29:41AM +, sylvain.bertr...@gmail.com wrote:
> > I would go #define and not direct "static const".
> >
> > Because I think "const" is part of the excess syntax of C and should be
> > optional (and treated
Hi,
I would go #define and not direct "static const".
Because I think "const" is part of the excess syntax of C and should be
optional (and treated as an optional variable attribute).
Then I would add simple macros than would, based on the compiler, enable the
attribute or not. It's a bit
On Fri, Sep 22, 2017 at 02:25:54PM +0200, Laslo Hunhold wrote:
> On Fri, 22 Sep 2017 06:00:51 +
> sylvain.bertr...@gmail.com wrote:
>
> Hey Sylvain,
>
> > go is not suckless.
> >
> > Should have written your PoC using simple C.
>
> what are you talking about? Go is an adequate language for
On Fri, Sep 22, 2017 at 10:35:26AM +0200, Kamil Cholewiński wrote:
> > go is not suckless.
> >
> > Should have written your PoC using simple C.
>
> Does C magically solve my design problem?
> At PoC stage, implementation language absolutely does not matter.
> I'd write it in PL/SQL if that solved
go is not suckless.
Should have written your PoC using simple C.
--
Sylvain
On Sun, Sep 03, 2017 at 12:56:24AM +0100, fao_ wrote:
> How do we know that *you* are you? You have never provided any fingerprint
> or signage to confirm it. For all we know you are the imposter.
>
> That said, it is troubling, I agree.
A good team of "security people" could steal your private
On Mon, Aug 28, 2017 at 11:31:38PM +0200, Stéphane Aulery wrote:
> As I mentioned in my first post, I will not want to write a piece of lower
> level or intermediate software with a scripting language, but one can still
> write a user software whose only dependency is the interpreter. The
>
On Mon, Aug 28, 2017 at 07:22:58PM +0200, Stéphane Aulery wrote:
> Le 28/08/2017 à 11:44, sylvain.bertr...@gmail.com a écrit :
> > On Mon, Aug 28, 2017 at 02:41:42AM +0200, Stéphane Aulery wrote:
> > > Le 27/08/2017 à 19:29, sylvain.bertr...@gmail.com a écrit :
> > > > On Sun, Aug 27, 2017 at
On Mon, Aug 28, 2017 at 02:41:42AM +0200, Stéphane Aulery wrote:
> Le 27/08/2017 à 19:29, sylvain.bertr...@gmail.com a écrit :
> > On Sun, Aug 27, 2017 at 05:27:24PM +0200, Stéphane Aulery wrote:
> > > My idea is how to reconcile the implementation of programs and a kernel
> > > that is a
On Sun, Aug 27, 2017 at 05:27:24PM +0200, Stéphane Aulery wrote:
> My idea is how to reconcile the implementation of programs and a kernel
> that is a multiplexer like plan9 with a language and a sound compilation
> environment like that of Oberon.
Once you have a nice working kernel with a
On Sun, Aug 27, 2017 at 02:58:34PM +0200, Stéphane Aulery wrote:
> Go and Oberon are better than this crazy ecosystem.
> They solve the problem of compilation and object orientation.
go is quite worse than rust. go has mandatory garbage collection, and its
bootstrap compiler is gcc (now c++
On Sun, Aug 27, 2017 at 10:56:49AM +0200, Hadrien Lacour wrote:
> The point of using a compiled language is to avoid useless dependencies, even
> if performances also count.
> To be honest, it'd be more acceptable if it didn't rely on the most bloated
> shell ever (baring fish, maybe). POSIX sh
On Sat, Aug 12, 2017 at 11:15:11AM +0200, hiro wrote:
> is C++ worse than glibc? (i would weight also by how much you can avoid it...)
c++ with its libsdc++ is orders of magnitude worse than the glibc with a c
compiler.
It's like comparing lynx/links to chromium/firefox.
Thx for the troll btw,
1 - 100 of 268 matches
Mail list logo
