Re: [dev] surf recompile
On Sat, 09 Oct 2010 09:44:31 +0400, Ramil Farkhshatov wrote: Mitchell Church wrote: 1. Download package from AUR. It consists of PKGBUILD and config.def.h 2. Edit config.def.h 3. Run makepkg -g >> PKGBUILD to update config.def.h checksum. 4. Run makepkg to build package. Yep, that's the way it was supposed to be done. Next time surf is updated I will replace config.def.h by config.h to prevent confusion. If you have an idea about how I could make this package better don't hesitate to tell me. -- Pierre 'catwell' Chapuis
Re: [dev] surf recompile
Thank you. I had been trying to work through the instructions in the read me and doing a make clean install. This worked fine when I took the time to actually clone the mercurial repository and work through mercurial. For some reason I couldn't get this working with the AUR package. I think it may have been because I was never truly copying the correct directory from /tmp. On Sat, Oct 9, 2010 at 1:13 PM, Pierre Chapuis wrote: > On Sat, 09 Oct 2010 09:44:31 +0400, Ramil Farkhshatov > wrote: > >> Mitchell Church wrote: >> > > 1. Download package from AUR. It consists of PKGBUILD and config.def.h >> 2. Edit config.def.h >> 3. Run makepkg -g >> PKGBUILD to update config.def.h checksum. >> 4. Run makepkg to build package. >> > > Yep, that's the way it was supposed to be done. > > Next time surf is updated I will replace config.def.h by config.h to > prevent confusion. > > If you have an idea about how I could make this package better don't > hesitate to tell me. > > -- > Pierre 'catwell' Chapuis > >
[dev] static bionic libc ...
Dear list As far as I have understood (http://suckless.org/project_ideas) and idea has been to use bionic as static libc in the Sta.li distribution. However, it seems like this libc is relatively closely attached to the Android SDK/NDK (http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html ,DGentry reply, 4th comment) and I doubt that the Android devs are interested in patches not needed specifically for Android in their tree. I suppose this means that a fork/spoon/spork of bionic would have to be made with patches that enables it to be a general-purpose static libc. If this is indeed what you suckless gurus have been planning, I got a suggested name for this branch with some obscure litterary references (which I will explain below). suggested name: "fReemade libc" The name links the "6 million dollar man" reference of bionic to the Remade in the steampunk/dark fantasy Bas-Lag (http://en.wikipedia.org/wiki/Bas-Lag) novels of China Miéville (http://en.wikipedia.org/wiki/China_Mi%C3%A9ville). The Remade are the product of a punishment where criminals are fused to mechanical (or animal) parts, which in essence is a life-long sentence to slavery. Some revolutionary Remade call themselves fReemade. I thought it was a pretty cool link with several nice interpretations - libc getting "freed" from its now limited purpose, builders of statically linked binaries getting "freed" from the (AFAIK) unresolved legal issues of LGPL when licence conflicts may occur. PS sorry if this came out as a "brainfart" DS
Re: [dev] static bionic libc ...
Because the most important thing about a libc is the name...
Re: [dev] static bionic libc ...
no ofcourse not :) I just got this association in my head and thought it was so cool so I wanted to share it with someone (hence the "sorry if this came out as a brainfart" post scriptum) 2010/10/9 Adrian : > Because the most important thing about a libc is the name... > >
Re: [dev] static bionic libc ...
Metasploit also distributes a copy of bionic with some patches in order to compile multistage shellcodes without libc dependencies. I would love to have a fork of bionic in the suckless repo with mk or makefiles.. I always find anoying the android.mk ..unless we do a replacement to use android.mk without the sdk, just using the common unix system tools On 09/10/2010, at 20:34, Jens Staal wrote: > Dear list > > As far as I have understood (http://suckless.org/project_ideas) and > idea has been to use bionic as static libc in the Sta.li distribution. > However, it seems like this libc is relatively closely attached to the > Android SDK/NDK > (http://codingrelic.geekhold.com/2008/11/six-million-dollar-libc.html > ,DGentry reply, 4th comment) and I doubt that the Android devs are > interested in patches not needed specifically for Android in their > tree. > I suppose this means that a fork/spoon/spork of bionic would have to > be made with patches that enables it to be a general-purpose static > libc. > > If this is indeed what you suckless gurus have been planning, I got a > suggested name for this branch with some obscure litterary references > (which I will explain below). > > suggested name: "fReemade libc" > > The name links the "6 million dollar man" reference of bionic to the > Remade in the steampunk/dark fantasy Bas-Lag > (http://en.wikipedia.org/wiki/Bas-Lag) novels of China Miéville > (http://en.wikipedia.org/wiki/China_Mi%C3%A9ville). The Remade are the > product of a punishment where criminals are fused to mechanical (or > animal) parts, which in essence is a life-long sentence to slavery. > Some revolutionary Remade call themselves fReemade. > > I thought it was a pretty cool link with several nice interpretations > - libc getting "freed" from its now limited purpose, builders of > statically linked binaries getting "freed" from the (AFAIK) unresolved > legal issues of LGPL when licence conflicts may occur. > > > PS sorry if this came out as a "brainfart" DS >
[dev] sta.li progress
I've been interested in sta.li for a while but luck has been against me. surf leaks memory or something at maximum speed when I visit the elevenislouder link on the sta.li website, and hg hangs trying to clone hg.suckless.org/stali-toolchain. Furthermore, the hg repository hasn't been touched in 7 months. sta.li is getting unfortunately vapourous. My fantasy idea of sta.li is simplified archlinux with everything static, 9base>BSD>GNU and no /usr. I happen to like udev hotplugging and such so I'm not so keen on getting rid of all that. So moving towards that ideal, my first step would be some good documentation or tools for gettign ABS to build static with bionic or uClibc or whatever, and then a statically linked pacman repository. But that's only for the hacked archlinux form of sta.li. To do anything with sta.li, we need a static toolchain and good documentation on using it in other systems. So, to my knowledge, that involves a decent libc, and probably the ld wrapper from project ideas. Anything else? Is the ld wrapper as simple as it sounds? Is it just just sneaking foo.a out the back door when asked to build foo.so and then sneaking foo.a in the back door when asked to link with foo.so? This is only needed with retarded build scripts that explicitly check for .so output right? Someone more skilled than I (possibly me after reading some docs) could write a script to do that pretty easily I think. The libc seems to be mostly a legal and political issue. Aside from that stuff, what is it that bionic (or whatever) does not do that it needs to? Or is it just a matter of figuring out and documenting? tl;dr: What is on the critical path of sta.li that isn't being done, and how can I help?
Re: [dev] surf recompile
Thanks. I have gotten this issue worked out now. Is it possible to do a persistant modkey in Surf? Functionally I guess it would be the equivalent of an "insert" mode. You hit the modkey once then you can use the typical j,k, g etc. to browse, then if you need to type text you hit the mod again to go into standard mode. Plenty of other browsers have something like this, but I have no idea how difficult it would be to implement. On Sat, Oct 9, 2010 at 7:14 AM, MItchell Church wrote: > Thank you. I had been trying to work through the instructions in the read > me and doing a make clean install. This worked fine when I took the time to > actually clone the mercurial repository and work through mercurial. For > some reason I couldn't get this working with the AUR package. I think it > may have been because I was never truly copying the correct directory from > /tmp. > > > On Sat, Oct 9, 2010 at 1:13 PM, Pierre Chapuis wrote: > >> On Sat, 09 Oct 2010 09:44:31 +0400, Ramil Farkhshatov >> wrote: >> >>> Mitchell Church wrote: >>> >> >> 1. Download package from AUR. It consists of PKGBUILD and config.def.h >>> 2. Edit config.def.h >>> 3. Run makepkg -g >> PKGBUILD to update config.def.h checksum. >>> 4. Run makepkg to build package. >>> >> >> Yep, that's the way it was supposed to be done. >> >> Next time surf is updated I will replace config.def.h by config.h to >> prevent confusion. >> >> If you have an idea about how I could make this package better don't >> hesitate to tell me. >> >> -- >> Pierre 'catwell' Chapuis >> >> >
[dev] [st] xclipboard support patch
hi st users,
here is a patch to support xclipboard st.
the code was extracted and adapted from x11.c of qemacs.
please try and if there is something to change, Iet me know.
pd: Aurélien, thanks for accepting my previous patch.
pd2: sorry my bad english.
saludos
-f
# HG changeset patch
# User fl
# Date 1286656688 10800
# Node ID 3be141f80d5ac30dd786dafc3769964c62d2e887
# Parent 96c41df08c947e720ad46ca4adadd5f4e59a0108
xclipboard support
diff -r 96c41df08c94 -r 3be141f80d5a st.c
--- a/st.c Tue Sep 21 16:04:13 2010 +0200
+++ b/st.c Sat Oct 09 17:38:08 2010 -0300
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#if defined(__linux)
@@ -199,6 +200,8 @@
static void brelease(XEvent *);
static void bpress(XEvent *);
static void bmotion(XEvent *);
+static void selsend(XEvent *);
+static void selclear(XEvent *);
static void (*handler[LASTEvent])(XEvent *) = {
@@ -212,6 +215,8 @@
[MotionNotify] = bmotion,
[ButtonPress] = bpress,
[ButtonRelease] = brelease,
+ [SelectionRequest] = selsend,
+ [SelectionClear] = selclear,
};
/* Globals */
@@ -277,15 +282,119 @@
return str;
}
-/* TODO: use X11 clipboard */
+/* use X11 clipboard */
static void selcopy(char *str) {
+ static Atom xa_clipboard = None;
+
free(sel.clip);
sel.clip = str;
+
+ /* own selection from now */
+ XSetSelectionOwner(xw.dis, XA_PRIMARY, xw.win, CurrentTime);
+
+ /* Ctrl-V request support */
+ if (xa_clipboard == None) /* avoid Xmu */
+ xa_clipboard = XInternAtom(xw.dis, "CLIPBOARD", False);
+ XSetSelectionOwner(xw.dis, xa_clipboard, xw.win, CurrentTime);
+}
+
+static Bool seltest(Display *dpy, XEvent *ev, char *arg) {
+ return (ev->type == SelectionNotify);
}
static void selpaste() {
- if(sel.clip)
+ Window w;
+ Atom prop;
+ unsigned long nread, bytes_after, nitems;
+ unsigned char *data;
+ Atom actual_type;
+ int actual_fmt;
+ XEvent xev;
+
+ w = XGetSelectionOwner(xw.dis, XA_PRIMARY);
+ if (w == None)
+ return;
+ /* st is the owner, directly write sel.clip */
+ if (w == xw.win && sel.clip) {
ttywrite(sel.clip, strlen(sel.clip));
+ return;
+ }
+
+ /* use X11 selection (Will be pasted when receiving
+ SelectionNotify event) */
+ prop = XInternAtom(xw.dis, "VT_SELECTION", False);
+ XConvertSelection(xw.dis, XA_PRIMARY, XA_STRING,
+ prop, xw.win, CurrentTime);
+
+ /* XXX: add timeout too if the target application
+ is not well educated */
+ XIfEvent(xw.dis, &xev, seltest, NULL);
+
+ w = xev.xselection.requestor;
+ prop = xev.xselection.property;
+
+ nread = 0;
+ for(;;) {
+ if ((XGetWindowProperty(xw.dis, w, prop, nread/4, 4096,
+ True, AnyPropertyType, &actual_type, &actual_fmt,
+ &nitems, &bytes_after, &data) != Success)
+ || (actual_type != XA_STRING)) {
+ XFree (data);
+ break;
+ }
+
+ ttywrite((char*) data, nitems);
+
+ nread += nitems;
+ XFree (data);
+ }
+}
+
+/* send selection to requestor */
+static void selsend(XEvent *xev)
+{
+ static Atom xa_targets = None;
+ XSelectionRequestEvent *rq = (XSelectionRequestEvent *) xev;
+ XEvent ev;
+
+ if (xa_targets == None)
+ xa_targets = XInternAtom (xw.dis, "TARGETS", False);
+
+ ev.xselection.type = SelectionNotify;
+ ev.xselection.property = None;
+ ev.xselection.display = rq->display;
+ ev.xselection.requestor = rq->requestor;
+ ev.xselection.selection = rq->selection;
+ ev.xselection.target= rq->target;
+ ev.xselection.time = rq->time;
+
+ if (rq->target == xa_targets) {
+ unsigned int target_list[2];
+
+ /* indicate which are supported types */
+ target_list[0] = xa_targets;
+ target_list[1] = XA_STRING;
+
+ XChangeProperty (xw.dis, rq->requestor, rq->property,
+ xa_targets, 8 * sizeof(target_list[0]), PropModeReplace,
+ (unsigned char *) target_list,
+ sizeof(target_list) / sizeof(target_list[0]));
+ } else if (rq->target == XA_STRING) {
+ /* get selection buffer */
+
+ if (!sel.clip)
+ return;
+
+ XChangeProperty (xw.dis, rq->requestor, rq->property,
+ XA_STRING, 8, PropModeReplace,
+ (unsigned char *)sel.clip, strlen(sel.clip));
+ }
+ ev.xselection.property = rq->property;
+ XSendEvent (xw.dis, rq->requestor, False, 0, &ev);
+}
+
+static void selclear(XEvent *e) {
+ /* TODO */
}
/* TODO: doubleclick to select word */
Re: [dev] surf recompile
> Is it possible to do a persistant modkey in Surf? Functionally I guess it > would be the equivalent of an "insert" mode. You hit the modkey once then > you can use the typical j,k, g etc. to browse, then if you need to type text > you hit the mod again to go into standard mode. Plenty of other browsers > have something like this, but I have no idea how difficult it would be to > implement. http://seanwhitton.com/doc/geek/code/ Check the surf insertmode diff on that page. It's not mine, but I asked Sean and did mean to upload it to suckless.org, but never got round to bringing it up to date. Good luck :) Rob.
Re: [dev] surf recompile
Oh thanks a bunch! I also have one other question, I apologize for the newbie questions for compiling this application. I've boned up on mercurial and now I can rebuild with changes to config.h working as expected, but I still don't know how to add in scripts. For example, the instructions for the link hint script from nibble say to deploy to script.js (Which I assume is the script.js in my .surf folder). I've tried this every way I know how with no success. Where is this script supposed to go for surf to recognize it and include it in the make install? On Sat, Oct 9, 2010 at 5:18 PM, Rob wrote: > > Is it possible to do a persistant modkey in Surf? Functionally I guess > it > > would be the equivalent of an "insert" mode. You hit the modkey once > then > > you can use the typical j,k, g etc. to browse, then if you need to type > text > > you hit the mod again to go into standard mode. Plenty of other browsers > > have something like this, but I have no idea how difficult it would be to > > implement. > > http://seanwhitton.com/doc/geek/code/ > > Check the surf insertmode diff on that page. It's not mine, but I > asked Sean and did mean to upload it to suckless.org, but never got > round to bringing it up to date. Good luck :) > > Rob. > >
[dev] polipo with surf
Has anyone experienced a speed increase using polipo caching proxy in conjunction with surf? I mean, the browser is pretty fast already, but polipo config is simple enough. To make it talk to surf do I merely do a #define http_proxy in config.h? Thanks. Also, I'm still trying to figure out how to deploy script.js. So far I have had no luck implementing link hinting. -- Mitchell
Re: [dev] polipo with surf
On slow connections i noticed a small improvement. I don't remember exactly what i had to to in order for it to work. It was discussex on the list before hough.
[dev] [sic][patch] fixes and questions.
Hello! some fixes for sic attached. story below. sic was saying "error: cannot resolve hostname : Success" so I went to the source. The Success was because the code was written assuming the failure would set errno, but it didn't. I fixed it to print out the right error message, but make wouldn't recompile it; util.c wasn't a build dependency. I fixed the makefile, which was an awful experience, rebuilt, got the actual error which was "Servname not supported for ai_socktype". DuckDuckGo said that was because etc/services didn't have the port name thingy in it. The port was "ircd", which I could find no references to, so I changed it to irc, which was at least in /etc/services. sic now gets past that error, but spits out "error: cannot connect to host '%s'\n". The reason for that is over my head right now. So, is "ircd" something that should be in my /etc/services, or is it a typo? Is "irc" not the right port? Can someone who knows more help me figure out why it's still failing? Anyways, I attched the diff, not including the ircd->irc part, which I'm unsure of. somefix.diff Description: Binary data
Re: [dev] [sic][patch] fixes and questions.
Ok, it works if I make the port 6667, which is also not in my /etc/services. Should port just be 6667 instead of mucking around with symbolic port resolution? - Original Message - From: Wolf Tivy Date: Saturday, October 9, 2010 9:27 pm Subject: [dev] [sic][patch] fixes and questions. To: dev@suckless.org > Hello! > some fixes for sic attached. story below. > > sic was saying "error: cannot resolve hostname host>: Success" so I went to the source. > The Success was because the code was written assuming the > failure would set errno, but it didn't. > I fixed it to print out the right error message, but make > wouldn't recompile it; util.c wasn't a build > dependency. I fixed the makefile, which was an awful experience, > rebuilt, got the actual error > which was "Servname not supported for ai_socktype". DuckDuckGo > said that was because etc/services > didn't have the port name thingy in it. The port was "ircd", > which I could find no references to, so I changed > it to irc, which was at least in /etc/services. sic now gets > past that error, but spits out > "error: cannot connect to host '%s'\n". The reason for that is > over my head right now. > So, is "ircd" something that should be in my /etc/services, or > is it a typo? Is "irc" not the right port? > Can someone who knows more help me figure out why it's still failing? > > Anyways, I attched the diff, not including the ircd->irc part, > which I'm unsure of. >
Re: [dev] [sic][patch] fixes and questions.
On Sat, 09 Oct 2010 21:35:55 -0700 Wolf Tivy wrote: > Ok, it works if I make the port 6667, which is also not in my /etc/services. > Should port just be 6667 instead of mucking around with symbolic port > resolution? Yes. Robert Ransom signature.asc Description: PGP signature
