[dev] [9base] bionic port
Greetings fellow hackers, I checked out the project ideas page[1] today and wondered if bionic was still a desirable choice for porting 9base or if other libraries like musl or dietlibc might be a better choice here, given the fact bionic is mainly targeted at ARM (for instance, FORTIFY_SOURCE only works on this arch and with GCC only). Could it be that bionic has been chosen as the lowest common denominator to still be able to use it as one standard library also in regard to C++ on sta.li? Please let me know so I can start with the work! Cheers FRIGN [1]: http://suckless.org/project_ideas -- FRIGN
Re: [dev] [9base] bionic port
On Fri, Dec 20, 2013 at 10:40:27AM +0100, FRIGN wrote: > Greetings fellow hackers, > > I checked out the project ideas page[1] today and wondered if bionic > was still a desirable choice for porting 9base or if other libraries > like musl or dietlibc might be a better choice here, given the fact > bionic is mainly targeted at ARM (for instance, FORTIFY_SOURCE only > works on this arch and with GCC only). > > Could it be that bionic has been chosen as the lowest common > denominator to still be able to use it as one standard library also in > regard to C++ on sta.li? Personally, I'd go with musl. What is your plan at the moment?
Re: [dev] [9base] bionic port
On 20 December 2013 10:40, FRIGN wrote: > Greetings fellow hackers, > > I checked out the project ideas page[1] today and wondered if bionic > was still a desirable choice for porting 9base or if other libraries > like musl or dietlibc might be a better choice here, given the fact > bionic is mainly targeted at ARM (for instance, FORTIFY_SOURCE only > works on this arch and with GCC only). > > Could it be that bionic has been chosen as the lowest common > denominator to still be able to use it as one standard library also in > regard to C++ on sta.li? > > Please let me know so I can start with the work! musl is the way to go. Cheers, Anselm
Re: [dev] [9base] bionic port
On Fri, 20 Dec 2013 12:52:52 +0100 Anselm R Garbe wrote: > > musl is the way to go. > On Fri, 20 Dec 2013 11:51:20 + sin wrote: > > Personally, I'd go with musl. What is your plan at the moment? > Thanks for the quick response! I planned on going for musl, too. It seems to be the best option, especially because we're planning to link stuff statically anyway. Thus, there's no need to look out for a standard library which also supports C++. To avoid confusion in the future, we should think about updating the wiki accordingly. Cheers FRIGN -- FRIGN
Re: [dev] [9base] bionic port
On Fri, Dec 20, 2013 at 11:05:00AM +0100, FRIGN wrote: > On Fri, 20 Dec 2013 11:51:20 + > sin wrote: > > > > Personally, I'd go with musl. What is your plan at the moment? > > > > I planned on going for musl, too. It seems to be the best option, > especially because we're planning to link stuff statically anyway. > Thus, there's no need to look out for a standard library which also > supports C++. > To avoid confusion in the future, we should think about updating the > wiki accordingly. Are you planning on porting 9base only for the moment or are you thinking of doing general sta.li work? A build system for sta.li would be awesome to have.
[dev] Optimizing C compiler & c++ compiler/runtime
Is there any remaining good c++ compiler/runtime which can boostrap using a C compiler/minimal runtime? Since its 4.8 version, gcc cannot bootstrap with a C compiler/minimal runtime, it needs a c++ compiler and runtime. Making gcc 4.7 series the last "clean" gcc. I heard about openwatcom (but it seems the license is kind of fishy). Since, it's near impossible to re-write/unroll all the "mandatory" c++ components in C quickly (harfbuzz, gecko/webkit...), what to do? Any suggestions? There is also the question of finding a new C99 optimizing compiler written properly in C of course. tinycc is interesting. It would require just a few basic optimization passes to make it a reasonable alternative to gcc. There is also the openwatcom compiler. Anything else? regards, -- Sylvain
Re: [dev] [9base] bionic port
On Fri, 20 Dec 2013 12:06:03 + sin wrote: > > Are you planning on porting 9base only for the moment or are you thinking > of doing general sta.li work? A build system for sta.li would be awesome > to have. > I am following the development of stali very actively, however having trouble finding the time to actually work on some things. Looking at the build system, I really think it would be beneficial to somehow be able to build on existing infrastructure (like Gentoo ebuilds). The problem here is that Gentoo is mostly dynamically linked and portage is not a suckless software (rather a python hell). I like the idea of doing everything in a clean chrooted environment, but there definitely has to be more dialogue on how to actually do it. What do you think should be the basic concept of it? Cheers FRIGN -- FRIGN
[dev] [st][patch] externalpipe()
Hi all,
Attached is a patch which gives st the ability to spit out its current
screen text to another program. This can be added under shortcuts in
config.h, e.g.:
static Shortcut shortcuts[] = {
...
{ MODKEY, 'u', externalpipe, { .s = "xurls | dmenu -l 10 | xargs open"
} },
};
Where xurls[1] is a script that pulls out urls from the text, then I can
pick one in dmenu and open[2] it in a browser.
If this doesn't qualify as core-st I'll happily stick it on the patches
page. Feedback welcome.
Rob
1: https://raw.github.com/bobrippling/perlbin/master/xurls
2: https://github.com/bobrippling/openFrom 7982a2d238925028b45d5143db470e408b97469a Mon Sep 17 00:00:00 2001
From: Rob Pilling
Date: Fri, 20 Dec 2013 12:40:55 +
Subject: [PATCH] Add externalpipe() for piping out screen text
---
st.c | 74 --
1 file changed, 68 insertions(+), 6 deletions(-)
diff --git a/st.c b/st.c
index 4fb3311..adef257 100644
--- a/st.c
+++ b/st.c
@@ -299,6 +299,7 @@ typedef union {
unsigned int ui;
float f;
const void *v;
+ const char *s;
} Arg;
typedef struct {
@@ -313,6 +314,7 @@ static void clippaste(const Arg *);
static void numlock(const Arg *);
static void selpaste(const Arg *);
static void xzoom(const Arg *);
+static void externalpipe(const Arg *);
/* Config.h for applying patches and the configuration. */
#include "config.h"
@@ -1204,15 +1206,22 @@ execsh(void) {
void
sigchld(int a) {
int stat = 0;
+ pid_t r;
- if(waitpid(pid, &stat, 0) < 0)
- die("Waiting for pid %hd failed: %s\n", pid, SERRNO);
+ r = wait(&stat);
+ if(r < 0)
+ die("wait(): %s\n", SERRNO);
- if(WIFEXITED(stat)) {
- exit(WEXITSTATUS(stat));
- } else {
- exit(EXIT_FAILURE);
+ if(r == pid){
+ /* _the_ sub porcess */
+ if(WIFEXITED(stat)) {
+ exit(WEXITSTATUS(stat));
+ } else {
+ exit(EXIT_FAILURE);
+ }
}
+
+ /* something else we've forked out */
}
void
@@ -2928,6 +2937,59 @@ xzoom(const Arg *arg) {
}
void
+externalpipe(const Arg *arg)
+{
+ int to[2]; /* 0 = read, 1 = write */
+ pid_t child;
+ int y, x;
+ void (*oldsigpipe)(int);
+
+ if(pipe(to) == -1)
+ return;
+
+ /* sigchld() handles this */
+ switch((child = fork())){
+ case -1:
+ close(to[0]), close(to[1]);
+ return;
+ case 0:
+ /* child */
+ close(to[1]);
+ dup2(to[0], STDIN_FILENO); /* 0<&to */
+ close(to[0]);
+ execvp(
+ "sh",
+ (char *const []){
+ "/bin/sh",
+ "-c",
+ (char *)arg->s,
+ 0
+ });
+ exit(127);
+ }
+
+ /* parent */
+ close(to[0]);
+ /* ignore sigpipe for now, in case child exits early */
+ oldsigpipe = signal(SIGPIPE, SIG_IGN);
+
+ for(y = 0; y < term.row; y++){
+ for(x = 0; x < term.col; x++){
+ if(write(to[1], term.line[y][x].c, 1) == -1)
+goto done;
+ }
+ if(write(to[1], "\n", 1) == -1)
+ break;
+ }
+
+done:
+ close(to[1]);
+
+ /* restore */
+ signal(SIGPIPE, oldsigpipe);
+}
+
+void
xinit(void) {
XGCValues gcvalues;
Cursor cursor;
--
1.7.10.4
Re: [dev] [9base] bionic port
On Fri, Dec 20, 2013 at 12:53:11PM +0100, FRIGN wrote: > On Fri, 20 Dec 2013 12:06:03 + > sin wrote: > > > > Are you planning on porting 9base only for the moment or are you thinking > > of doing general sta.li work? A build system for sta.li would be awesome > > to have. > > > > Looking at the build system, I really think it would be beneficial to > somehow be able to build on existing infrastructure (like Gentoo > ebuilds). The problem here is that Gentoo is mostly dynamically linked > and portage is not a suckless software (rather a python hell). > > I like the idea of doing everything in a clean chrooted environment, > but there definitely has to be more dialogue on how to actually do it. > > What do you think should be the basic concept of it? Personally I'd go with something similar to what sabotage has. I have not used gentoo in years and I have no idea what their build system looks like these days. I have a very simple build system for my distro which I use mainly for testing things out at http://git.2f30.org/morpheus/tree/ This design does not scale, however, sabotage's build system might be a good place to start.
Re: [dev] [st][patch] externalpipe()
Greetings.
On Fri, 20 Dec 2013 15:27:24 +0100 Rob wrote:
> Hi all,
>
> Attached is a patch which gives st the ability to spit out its current
> screen text to another program. This can be added under shortcuts in
> config.h, e.g.:
>
>
> static Shortcut shortcuts[] = {
> ...
> { MODKEY, 'u', externalpipe, { .s = "xurls | dmenu -l 10 | xargs open"
> } },
> };
>
> Where xurls[1] is a script that pulls out urls from the text, then I can
> pick one in dmenu and open[2] it in a browser.
>
> If this doesn't qualify as core-st I'll happily stick it on the patches
> page. Feedback welcome.
Please provide it as a patch on the wiki. I have something similar, but
for the selected text (where double‐click selection is handy) so the
clipboard text is sent to a similar »open« application. This is a bit
more universal in the X11 environment.
Sincerely,
Christoph Lohmann
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, Dec 20, 2013 at 5:49 AM, Sylvain BERTRAND wrote: > There is also the question of finding a new C99 optimizing > compiler written properly in C of course. > > tinycc is interesting. It would require just a few basic > optimization passes to make it a reasonable alternative to gcc. > > There is also the openwatcom compiler. > > Anything else? I’ve been curious about libfirm and cparser but haven't looked at them closely yet. “Firm is a C-library that provides a graph-based intermediate representation, optimizations, and assembly code generation suitable for use in compilers.” http://pp.info.uni-karlsruhe.de/firm/ “cparser is a library containing a parser, lexer and semantic analysis for the ISO C99 language. It should be used as a compiler frontend, a base for source-source transformation, or source-checker tools.” http://sourceforge.net/projects/cparser/ -- Anthony J. Bentley
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, 20 Dec 2013 13:49:43 +0100 Sylvain BERTRAND wrote: > Is there any remaining good c++ compiler/runtime which can > boostrap using a C compiler/minimal runtime? > > Since, it's near impossible to re-write/unroll all the > "mandatory" c++ components in C quickly (harfbuzz, > gecko/webkit...), what to do? Any suggestions? Not that I'm aware of, beside I'm not sure what benefits this would bring? You're fine with C++ in one place, but not the other? > There is also the question of finding a new C99 optimizing > compiler written properly in C of course. > > Anything else? This is valid question on other hand e.g. base OpenBSD is C++ free for some time AFAIK (after the removal of groff). Idea of minimal set of tools, capable of rebuilding itself is attractive. On one hand, you can use pretty old GCC and most of C codebase will compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more than six years old). C is stable - you will more likely see changes in standard C library, than compiler/language itself. GCC v4.7.x should work just fine for some years to come. C++ is different kind of beast. More and more software requires C++11 features and this means very recent version of compilers, especially since C++ standard libraries are developed inside the same projects (GCC/libstdc++, Clang/libc++). Sticking to GCC v4.7.x isn't an option here as far I can tell. The last problem: C99-capable compiler isn't enough to get usable system based on Linux. Clang which was designed as GCC drop-in replacement chokes on Linux kernel (some patches are needed), because it heavily uses GCC extensions and specific features (some undocumented/undefined). PCC/TCC aren't actively developed, I'm not sure about the status of firm/CParser. Still those alternative C compilers are just good enough for specific programs and not larger set of packages. -- Paul Onyschuk
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Tcc is actively maintained. Just check the mailing list or the git repo. > On 20 Dec 2013, at 16:35, Paul Onyschuk wrote: > > On Fri, 20 Dec 2013 13:49:43 +0100 > Sylvain BERTRAND wrote: > >> Is there any remaining good c++ compiler/runtime which can >> boostrap using a C compiler/minimal runtime? >> >> Since, it's near impossible to re-write/unroll all the >> "mandatory" c++ components in C quickly (harfbuzz, >> gecko/webkit...), what to do? Any suggestions? > > Not that I'm aware of, beside I'm not sure what benefits this would > bring? You're fine with C++ in one place, but not the other? > >> There is also the question of finding a new C99 optimizing >> compiler written properly in C of course. >> >> Anything else? > > This is valid question on other hand e.g. base OpenBSD is C++ free for > some time AFAIK (after the removal of groff). Idea of minimal set of > tools, capable of rebuilding itself is attractive. > > On one hand, you can use pretty old GCC and most of C codebase will > compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more > than six years old). C is stable - you will more likely see changes in > standard C library, than compiler/language itself. GCC v4.7.x should > work just fine for some years to come. > > C++ is different kind of beast. More and more software requires C++11 > features and this means very recent version of compilers, especially > since C++ standard libraries are developed inside the same projects > (GCC/libstdc++, Clang/libc++). Sticking to GCC v4.7.x isn't an option > here as far I can tell. > > The last problem: C99-capable compiler isn't enough to get usable > system based on Linux. Clang which was designed as GCC drop-in > replacement chokes on Linux kernel (some patches are needed), because > it heavily uses GCC extensions and specific features (some > undocumented/undefined). > > PCC/TCC aren't actively developed, I'm not sure about the status of > firm/CParser. Still those alternative C compilers are just good > enough for specific programs and not larger set of packages. > > -- > Paul Onyschuk >
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, Dec 20, 2013 at 04:35:36PM +0100, Paul Onyschuk wrote: > On Fri, 20 Dec 2013 13:49:43 +0100 > Sylvain BERTRAND wrote: > > > Is there any remaining good c++ compiler/runtime which can > > boostrap using a C compiler/minimal runtime? > > > > Since, it's near impossible to re-write/unroll all the > > "mandatory" c++ components in C quickly (harfbuzz, > > gecko/webkit...), what to do? Any suggestions? > > Not that I'm aware of, beside I'm not sure what benefits this would > bring? You're fine with C++ in one place, but not the other? Actually, the only c++ components which bother me are "modern" javascript-enabled www renderers and harfbuzz (but I coded a C _partial_ port). netsurf is far from being usable on www sites where javascript is mandatory. > > There is also the question of finding a new C99 optimizing > > compiler written properly in C of course. > > > > Anything else? > > This is valid question on other hand e.g. base OpenBSD is C++ free for > some time AFAIK (after the removal of groff). Idea of minimal set of > tools, capable of rebuilding itself is attractive. Oh! What openbsd uses for its man page terminal renderer? I'm stuck with the buggy heirloom tools. > On one hand, you can use pretty old GCC and most of C codebase will > compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more > than six years old). C is stable - you will more likely see changes in > standard C library, than compiler/language itself. GCC v4.7.x should > work just fine for some years to come. ARM64 is on its way, which will require a backport in gcc 4.7.x. > C++ is different kind of beast. More and more software requires C++11 > features and this means very recent version of compilers, especially > since C++ standard libraries are developed inside the same projects > (GCC/libstdc++, Clang/libc++). Sticking to GCC v4.7.x isn't an option > here as far I can tell. Yes... c++ is a fast moving target. Since its implementation cost is just insane, coding from scratch a C implementation seems unreasonnable. We will have to chain compile gccs to reach a c++11 compiler and runtime. Basically, this is laughing right at the face of the entire planet. > The last problem: C99-capable compiler isn't enough to get usable > system based on Linux. Clang which was designed as GCC drop-in > replacement chokes on Linux kernel (some patches are needed), because > it heavily uses GCC extensions and specific features (some > undocumented/undefined). That's very bad. Linux kernel devs have not accepted patches to allow compilation with alternative C compilers??
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Anthony J. Bentley wrote: > I’ve been curious about libfirm and cparser but haven't looked at them > closely yet. I did work a bit with cparser/libfirm and found the following: * It took about 2 times longer to compile than gcc * There was no x64 support yet * It is not developed very actively, although the developers are responsive * Some Programms had to be patched to be „libfirm-friendly“ and compilable * Sometimes a lot of (in my understanding of the respective source) wrong warnings popped up In conclusion I would say it is not yet stable enough for production use, but worth a look into, if you're interested in compilers. --Markus
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, Dec 20, 2013 at 08:22:03AM -0700, Anthony J. Bentley wrote: > On Fri, Dec 20, 2013 at 5:49 AM, Sylvain BERTRAND wrote: > > There is also the question of finding a new C99 optimizing > > compiler written properly in C of course. > > > > tinycc is interesting. It would require just a few basic > > optimization passes to make it a reasonable alternative to gcc. > > > > There is also the openwatcom compiler. > > > > Anything else? > > I’ve been curious about libfirm and cparser but haven't looked at them > closely yet. > > “Firm is a C-library that provides a graph-based intermediate > representation, optimizations, and assembly code generation suitable > for use in compilers.” > > http://pp.info.uni-karlsruhe.de/firm/ If it has basic semantic optimization passes, it is quite interesting. > “cparser is a library containing a parser, lexer and semantic analysis > for the ISO C99 language. It should be used as a compiler frontend, a > base for source-source transformation, or source-checker tools.” > > http://sourceforge.net/projects/cparser/ That would require to code the optimization passes.
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Sylvain BERTRAND wrote: > Since its 4.8 version, gcc cannot bootstrap with a C > compiler/minimal runtime, it needs a c++ compiler and runtime. > Making gcc 4.7 series the last "clean" gcc. I think it is amusing that you think that gcc 4.7 is clean and good, because it is written in C. From my understanding it is an incredibly complex piece of software, and I think that it is quite possible that using some C++ will cause the GCC code base to suck less (please note I haven't specified any magnitude of sucking less, or an absolute position on the suck scale).
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On 20/12/2013, Sylvain BERTRAND wrote: > That's very bad. Linux kernel devs have not accepted patches to > allow compilation with alternative C compilers?? Well, Linus is no gcc fan [1], so they might, if a ready alternative were available. [1] https://lkml.org/lkml/2006/11/28/206
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, Dec 20, 2013 at 11:36:17AM -0500, Bobby Powers wrote: > Sylvain BERTRAND wrote: > > Since its 4.8 version, gcc cannot bootstrap with a C > > compiler/minimal runtime, it needs a c++ compiler and runtime. > > Making gcc 4.7 series the last "clean" gcc. > > I think it is amusing that you think that gcc 4.7 is clean and good, > because it is written in C. From my understanding it is an incredibly > complex piece of software, and I think that it is quite possible that > using some C++ will cause the GCC code base to suck less (please note > I haven't specified any magnitude of sucking less, or an absolute > position on the suck scale). "clean" = C bootstrap-able. My personal opinion on c++ is: not a sane language/runtime. My opinion an C: not perfect, but the best compromise.
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, 20 Dec 2013 17:31:26 +0100 Sylvain BERTRAND wrote: > > Oh! What openbsd uses for its man page terminal renderer? I'm > stuck with the buggy heirloom tools. > Mandoc aka mdocml [1]. > > ARM64 is on its way, which will require a backport in gcc 4.7.x. > We will see how it turns out. If AArch64 gets same treatment as ARM devices, I don't see myself using it: handful of outdated binary blobs just to get it half-working (no one cares about stability of ABI for kernel modules). > > That's very bad. Linux kernel devs have not accepted patches to > allow compilation with alternative C compilers?? > You can watch this presentation [2] or check LLVMLinux project directly [3]. It touches the topic in some way. [1] http://mdocml.bsd.lv/ [2] http://www.youtube.com/watch?v=oGr4KghvxqU [3] http://llvm.linuxfoundation.org/index.php/Main_Page -- Paul Onyschuk
Re: [dev] Optimizing C compiler & c++ compiler/runtime
(Wondering about the topic, no idea why one would want to use C++ anyway… but… *shrug*) Sylvain BERTRAND dixit: >> This is valid question on other hand e.g. base OpenBSD is C++ free for >> some time AFAIK (after the removal of groff). Idea of minimal set of Same for MirBSD (removal of GNU groff in 2004 or so). >> tools, capable of rebuilding itself is attractive. > >Oh! What openbsd uses for its man page terminal renderer? I'm >stuck with the buggy heirloom tools. Oh, they’re buggy? Damn. I had hoped for a ditroff implementation eventually. I’m using the AT&T nroff from 4.4BSD-Alpha in MirBSD, which are a full *roff implementation. The tbl cannot handle enough text diversions to format terminfo(5), but, with some tweaks, and lots of fixes to the UCB macropackages, everything else works pretty well. The code is far from suckless though: typical for its age, “let’s read everything into static buffers and hope for the best”, “int is a pointer”, no function prototypes, you name it. It builds with GCC 3.4.6 -O1 but not -Os or -O2. Fixes welcome (src/usr.bin/oldroff/ in CVS). I did use this on Interix (SFU 3.5), too. Note this is nroff/troff, i.e. console and line printers only, and troff is for that typesetter, only. (But the output, console, converted to HTML with my script for the MirBSD manpages, and even natively on an Epson FX-80 dot-matrix printer, is decent.) And it’s much slower than GNU groff on the same hardware (e.g. SPARCstation 5/170) on the same manual pages (especially -mdoc). I’ve got a tape archive from the original ditroff, which I cannot use because of legal issues (someone in the USA probably can take it as Public Domain). I did contact the ditroff author, but he could not help me, nor could Lucent. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, Dec 20, 2013 at 06:12:45PM +0100, Paul Onyschuk wrote: > On Fri, 20 Dec 2013 17:31:26 +0100 > Sylvain BERTRAND wrote: > > > > > Oh! What openbsd uses for its man page terminal renderer? I'm > > stuck with the buggy heirloom tools. > > > > Mandoc aka mdocml [1]. Thanks. I'll see how it compares to heirloom. > > > > ARM64 is on its way, which will require a backport in gcc 4.7.x. > > > > We will see how it turns out. If AArch64 gets same treatment as ARM > devices, I don't see myself using it: handful of outdated binary blobs > just to get it half-working (no one cares about stability of ABI for > kernel modules). Do you mean that the GNU GPL is useless at opening even some blobs required to make ARM platforms work properly? > > > > That's very bad. Linux kernel devs have not accepted patches to > > allow compilation with alternative C compilers?? > > > > You can watch this presentation [2] or check LLVMLinux project > directly [3]. It touches the topic in some way. Sadly, llvm is not C-bootstrap-able which makes it a definitive nono.
Re: [dev] Optimizing C compiler & c++ compiler/runtime
On Fri, 20 Dec 2013 17:26:42 + (UTC) Thorsten Glaser wrote: > > Oh, they’re buggy? Damn. I had hoped for a ditroff > implementation eventually. > Here [1] you can find links/references to every existing *roff implementation. Still that doesn't leave many options. Troff from Plan9 is interesting, yet it doesn't support -mdoc macros (those can be copied from Heirloom or from older version of Groff - macros itself are BSD licenses AFAIK, just macros from newer version expect a support for arbitrary number of macro arguments). There is even port to Linux [2] (didn't check it). [1] http://manpages.bsd.lv/history.html [2] http://repo.or.cz/w/troff.git -- Paul Onyschuk
[dev][announce] Optimizing C compiler & c++ compiler/runtime
Paul Onyschuk wrote: On Fri, 20 Dec 2013 13:49:43 +0100 Sylvain BERTRAND wrote: There is also the question of finding a new C99 optimizing compiler written properly in C of course. Anything else? On one hand, you can use pretty old GCC and most of C codebase will compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more than six years old). C is stable - you will more likely see changes in standard C library, than compiler/language itself. GCC v4.7.x should work just fine for some years to come. The last problem: C99-capable compiler isn't enough to get usable system based on Linux. Clang which was designed as GCC drop-in replacement chokes on Linux kernel (some patches are needed), because it heavily uses GCC extensions and specific features (some undocumented/undefined). PCC/TCC aren't actively developed, I'm not sure about the status of firm/CParser. Still those alternative C compilers are just good enough for specific programs and not larger set of packages. I suppose if you can get a stable version of GCC, like you say, the platform ABIs aren't going to change, but I can see certain things from C11 coming into libraries, such as atomics. Of course glibc (should) support all the way back to C89. Not sure if musl is C99 and above or not. pcc is pretty much dead but there's active development on tcc, both bug-fixes and work on the ARM ABI code. However I find bugs can easily sneak in due to its very small test suite and somewhat hard to understand / strongly coupled code. Still, speed-wise it goes like a stabbed rat. I've been working on a C compiler in my spare time and recently finished floating point support (minus long doubles). My aim has been to have a simple and easy to understand code base and little bloat, while supporting common extensions, such as emitting the middle term in ?: expressions, __asm__, __typeof__ and so on. The code generation beats tcc's and can usually match or beat gcc and clang's -O0 level in plenty of cases, which I find to be a good balance for now. There's plenty of room for improvement in the backend. The main features left before I can proclaim C99 support are passing and returning structs/unions by value, and VLAs *shudder*. It targets primarily x86_64 and can target x86 (experimental/32-bit) but 32-bit support for 'long long' and x87 floating point stack support are lacking (which is the same reason why long double isn't supported on x86_64 yet). There's also a MIPS backend but this hasn't been tested and is out of date. Alongside this, I'm now at a stage where I can work on getting it to bootstrap. I'm currently held back by a bug in the preprocessor when handling glibc/Debian's unistd.h and it also looks like I'll need to support GNU's transparent union extension too. If anyone's interested. It's hosted here [1] and I'm all ears to critiques and feedback. Thanks, Rob 1: https://github.com/bobrippling/ucc-c-compiler
Re: [dev] Optimizing C compiler & c++ compiler/runtime
Paul Onyschuk dixit: >(those can be copied from Heirloom or from older version of Groff - Or my version from AT&T nroff, which got bugfixes in the else-part of GNU groff specifics. I’ve got them in CVS as src/share/tmac/ (not /usr/lib/ but /usr/share/ as per the standard modern-BSD filesystem hierarchy). >macros itself are BSD licenses AFAIK, just macros from newer version >expect a support for arbitrary number of macro arguments). There is Yeah, you don’t get that with AT&T nroff either. And the amount of NetBSD® manpages where I had to fix things like \*[Lt] into \*(Lt is amazing. >[1] http://manpages.bsd.lv/history.html Hm, so this is the 1972 one. Maybe I should write what I did to the mdocml people to get added to that list. Thanks for the pointer! bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
On Fri, 20 Dec 2013 18:06:07 + (GMT) Rob wrote: > > I suppose if you can get a stable version of GCC, like you say, the > platform ABIs aren't going to change, but I can see certain things > from C11 coming into libraries, such as atomics. Of course glibc > (should) support all the way back to C89. Not sure if musl is C99 and > above or not. > Last time I compiled glibc by hand, kernel version (headers - as glibc use them) and binutils were more an issue compared to compiler. As for musl, dependencies are listed in INSTALL file [1], list of supported compilers is also available on wiki [2]. [1] http://git.musl-libc.org/cgit/musl/tree/INSTALL [2] http://wiki.musl-libc.org/wiki/Supported_Platforms -- Paul Onyschuk
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Hello, I'm surprised no one has mentioned the Plan 9 C compiler. There seems to be a copy here: https://code.google.com/p/ken-cc/ , it is also built as part of the Go build process. And I'm sure it is available elsewhere. Is there something glaring I am missing? yours, Bobby
Re: [dev] [st][patch] externalpipe()
Hi Rob!
On Fri, Dec 20, 2013 at 01:56:15PM +, Rob wrote:
>
> Attached is a patch which gives st the ability to spit out its current
> screen text to another program. This can be added under shortcuts in
> config.h, e.g.:
>
>
> static Shortcut shortcuts[] = {
> ...
> { MODKEY, 'u', externalpipe, { .s = "xurls | dmenu -l 10 | xargs open"
> } },
> };
IMHO it makes sense here to use `xargs -r`, otherwise hitting escape in
dmenu results in calling `open` without argument, which does not make
much sense.
> Where xurls[1] is a script that pulls out urls from the text, then I
> can pick one in dmenu and open[2] it in a browser.
Very cool, thanks for writing this. I wanted to hack something
equivalent to [1] during 30C3, which I won't now because this is much
cooler :)
Re: [dev] [st][patch] externalpipe()
On Fri, Dec 20, 2013 at 08:21:34PM +0100, Alexander Huemer wrote:
> Hi Rob!
>
> On Fri, Dec 20, 2013 at 01:56:15PM +, Rob wrote:
> >
> > Attached is a patch which gives st the ability to spit out its current
> > screen text to another program. This can be added under shortcuts in
> > config.h, e.g.:
> >
> >
> > static Shortcut shortcuts[] = {
> > ...
> > { MODKEY, 'u', externalpipe, { .s = "xurls | dmenu -l 10 | xargs open"
> > } },
> > };
>
> IMHO it makes sense here to use `xargs -r`, otherwise hitting escape in
> dmenu results in calling `open` without argument, which does not make
> much sense.
>
> > Where xurls[1] is a script that pulls out urls from the text, then I
> > can pick one in dmenu and open[2] it in a browser.
>
> Very cool, thanks for writing this. I wanted to hack something
> equivalent to [1] during 30C3, which I won't now because this is much
> cooler :)
Sorry, [1] was missing.
Kind regards,
-Alex
[1] https://raw.github.com/muennich/urxvt-perls/master/url-select
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
Bobby Powers dixit: >I'm surprised no one has mentioned the Plan 9 C compiler. There seems Hm, does it support something other than ECOFF output now? The assembler part is also very foreign… I’ve also got one more: nwcc (Nils Weller’s C compiler). bye, //mirabilos -- In traditional syntax ' is ignored, but in c99 everything between two ' is handled as character constant. Therefore you cannot use ' in a preproces- sing file in c99 mode. -- Ragge No faith left in ISO C99, undefined behaviour, etc.
Re: [dev] [st][patch] externalpipe()
Alexander Huemer wrote: On Fri, Dec 20, 2013 at 08:21:34PM +0100, Alexander Huemer wrote: Hi Rob! On Fri, Dec 20, 2013 at 01:56:15PM +, Rob wrote: Attached is a patch which gives st the ability to spit out its current screen text to another program. IMHO it makes sense here to use `xargs -r`, otherwise hitting escape in dmenu results in calling `open` without argument, which does not make much sense. Ah! Didn't know about that, nice suggestion. Admittedly a GNU extension but it's very fitting. Where xurls[1] is a script that pulls out urls from the text, then I can pick one in dmenu and open[2] it in a browser. Very cool, thanks for writing this. I wanted to hack something equivalent to [1] during 30C3, which I won't now because this is much cooler :) Sorry, [1] was missing. Kind regards, -Alex [1] https://raw.github.com/muennich/urxvt-perls/master/url-select Yeah, based it off url-select, love that feature. urxvt takes 8 seconds or so to open on my laptop, so necessity is the mother of invention and all that. Anyway, glad you've found it useful, it's been pushed to the wiki with your modification now too. Rob
Re: [dev] Optimizing C compiler & c++ compiler/runtime
> “Firm is a C-library that provides a graph-based intermediate > representation, optimizations, and assembly code generation suitable > for use in compilers.” > I don't know if this is useful for this topic, but I have written a parser for C that can be used as the base for some project. Regards, -- Roberto E. Vargas Caballero
Re: [dev] [9base] bionic port
I want to mention my simple mk-based package building system [1]. It is not totally complete but builds packages fine both for my local system and for ARM-based embedded system. 1. https://github.com/gravicappa/spmk
Re: [dev] [st][patch] externalpipe()
Rob wrote: > Yeah, based it off url-select, love that feature. urxvt takes 8 seconds > or so to open on my laptop, so necessity is the mother of invention and > all that. Configure with --disable-everything and use urxvtd. Faster (and more stable) than st for me.
Re: [dev] [st][patch] externalpipe()
On Fri, Dec 20, 2013 at 08:05:15PM +, Rob wrote: > Anyway, glad you've found it useful, it's been pushed to the wiki with > your modification now too. Nice. Thanks. Kind regards, -Alex
Re: [dev] [st][patch] externalpipe()
On Fri, Dec 20, 2013 at 09:43:46PM +0100, koneu wrote: > Faster (and more stable) than st for me. Seems like a very good reason to improve st… Kind regards, -Alex
Re: [dev] [st][patch] externalpipe()
koneu wrote: Rob wrote: Yeah, based it off url-select, love that feature. urxvt takes 8 seconds or so to open on my laptop, so necessity is the mother of invention and all that. Configure with --disable-everything and use urxvtd. Faster (and more stable) than st for me. Wow, it is pretty snappy actually. Wonder how... Rob
Re: [dev] [st][patch] externalpipe()
Quoth Rob: > Attached is a patch which gives st the ability to spit out its current > screen text to another program. Cool, I made a (likely far less competent) patch doing the same thing 2.5 years ago. http://lists.suckless.org/dev/1108/9198.html So yes, I like the idea :)
[dev] strlcpy and strlcat
I just read this message by an OpenBSD developer on the prevalence of strlcpy in the OpenBSD ports tree: http://marc.info/?l=openbsd-tech&m=138733933417096&w=2 I'd like to know what the opinion here is of these functions. I've so far avoided them, but it seems like there's an argument to be made for their simplicity, though they're not POSIX standard. I've found myself wishing for an alternate universe where standard libc string handling was done with a (buf, bufsize) pair. No chance of that though.
Re: [dev][announce] Optimizing C compiler & c++ compiler/runtime
On 20/12/2013, Rob wrote: > https://github.com/bobrippling/ucc-c-compiler Why are you rewriting libc?
