Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
I' On 3/6/10, Noah Birnel wrote: > On Fri, Mar 05, 2010 at 02:59:17PM +, Nick wrote: >> On Fri, Mar 05, 2010 at 06:46:37AM -0800, Noah Birnel wrote: >> > On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: >> > > >> > > http://code.google.com/p/equanime >> > >> > Not Found >> > The requested URL /p/equanim/ was not found on this server. >> > >> > Typo? Or is it gone? >> >> On your part. Note the final 'e'. > > Oops. > > -- kv, - Bjartur
Re: [dev] GSoC 2010
I like this one too :) On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: > On 4 March 2010 22:15, Uriel wrote: > > Here is an idea the Google folks might like: Port sta.li (and p9p?) to > > use Android's libc. AFAIK there is no real linux distro that uses the > > Android libc, and this would be a project that might be useful for > > everyone. > > Good idea. I add it. > > Cheers, > Anselm >
Re: [dev] GSoC 2010
On 8 March 2010 15:57, Gregor Best wrote: > On Mon, Mar 08, 2010 at 03:44:28PM +, Anselm R Garbe wrote: >> [...] >> Sure, but according to the spec: >> >> "The strlen() function shall compute the number of bytes in the string >> to which s points, not including the terminating null byte." >> >> strlen() should not count multi-char characters as 1 but rather return >> number of bytes. Do you disagree? >> [...] > > I never read the actual docs of that function (a few glances at the > manpage aside), and if it definitely says "count the number of bytes", > fine. But intuitively, I would've thought it gives the length of a > string, as in "how many letters appear on my screen if I printf() > this?". Well if so, then many C programs would completely fall over, because it is common to allocate buffers of the length returned by strlen(), and if that returns just number of UTF-8 glyphs we'll have buffer overflows in nearly any language except English presumably. The only part where UTF-8 might matter are sorting routines, but I wouldn't bother too much about it because in most case < or > on a per-byte basis will still lead to reasonable results, which is another reason for the beauty of UTF-8. And if you really want to use more improved sorting routines, I'd recommend Plan 9 Rune's (http://swtch.com/plan9port/man/man3/rune.html) on top of the plain handling. Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 8, 2010 at 3:57 PM, Gregor Best wrote: > I never read the actual docs of that function (a few glances at the > manpage aside), and if it definitely says "count the number of bytes", > fine. But intuitively, I would've thought it gives the length of a > string, as in "how many letters appear on my screen if I printf() > this?". Plan 9 has utflen() for that purpose. Also, how many characters appear depends on what encoding your terminal is using. strlen() is absolute, and is probably more useful in most contexts.
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 03:44:28PM +, Anselm R Garbe wrote: > [...] > Sure, but according to the spec: > > "The strlen() function shall compute the number of bytes in the string > to which s points, not including the terminating null byte." > > strlen() should not count multi-char characters as 1 but rather return > number of bytes. Do you disagree? > [...] I never read the actual docs of that function (a few glances at the manpage aside), and if it definitely says "count the number of bytes", fine. But intuitively, I would've thought it gives the length of a string, as in "how many letters appear on my screen if I printf() this?". -- GCS/IT/M d- s+:- a-- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- ?O M-- ?V PS++ PE- Y++ PGP+++ t+ 5 X+ R tv b+++ DI+++ D+++ G+ e h! r y+ Gregor Best pgpegLFWIw8d4.pgp Description: PGP signature
Re: [dev] GSoC 2010
On 8 March 2010 15:39, Gregor Best wrote: > On Mon, Mar 08, 2010 at 02:57:50PM +, Anselm R Garbe wrote: >> [...] >> Can't see why UTF-8 would require any specific handling at the libc level. >> [...] > > Aren't strlen() and friends part of libc? Sure, but according to the spec: "The strlen() function shall compute the number of bytes in the string to which s points, not including the terminating null byte." strlen() should not count multi-char characters as 1 but rather return number of bytes. Do you disagree? Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 02:57:50PM +, Anselm R Garbe wrote: > [...] > Can't see why UTF-8 would require any specific handling at the libc level. > [...] Aren't strlen() and friends part of libc? -- GCS/IT/M d- s+:- a-- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- ?O M-- ?V PS++ PE- Y++ PGP+++ t+ 5 X+ R tv b+++ DI+++ D+++ G+ e h! r y+ Gregor Best pgpMwOTSUF0aM.pgp Description: PGP signature
Re: [dev] GSoC 2010
On 8 March 2010 14:52, Jacob Todd wrote: > On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: >> Good idea. I add it. >> >> Cheers, >> Anselm >> > That was fast. Doesn't Android's libc not have utf8 support at the libc level? > I thought I read somewhere that it didn't. Is that not needed? Can't see why UTF-8 would require any specific handling at the libc level. Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: > Good idea. I add it. > > Cheers, > Anselm > That was fast. Doesn't Android's libc not have utf8 support at the libc level? I thought I read somewhere that it didn't. Is that not needed? -- I am a man who does not exist for others. pgpEFRNjTBhPc.pgp Description: PGP signature
Re: [dev] GSoC 2010
On 4 March 2010 22:15, Uriel wrote: > Here is an idea the Google folks might like: Port sta.li (and p9p?) to > use Android's libc. AFAIK there is no real linux distro that uses the > Android libc, and this would be a project that might be useful for > everyone. Good idea. I add it. Cheers, Anselm
Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
On Fri, Mar 05, 2010 at 02:59:17PM +, Nick wrote: > On Fri, Mar 05, 2010 at 06:46:37AM -0800, Noah Birnel wrote: > > On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: > > > > > > http://code.google.com/p/equanime > > > > Not Found > > The requested URL /p/equanim/ was not found on this server. > > > > Typo? Or is it gone? > > On your part. Note the final 'e'. Oops.
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 01:07:13PM +0100, pancake wrote: > Szabolcs Nagy wrote: > >window system > a friend of me, who is a enlightenment developer is writing a new > graphical system > to replace X windows, it is not suckless, but really minimal, well Interesting to see something like this from an enlightenment dev. >From previous mail exchanges with raster it always seemed as he was pretty happy with X (or probably he just knows too good that replacing it would be a huge undertaking). > >bug and issue tracker > >improve dmc (mail) > +1 +1 although I haven't really looked at dmc yet. I still think a lightweight libimap would be useful for various mail related things. Did anyone try out notmuch? http://keithp.com/blogs/notmuch/ > >ssl cert validation for surf > +1 > > There are several other issues in surf I would also like to see an elementary (which IMHO sucks much less than GTK) based gui for surf this should get easier as webkit-efl is integrated into upstream webkit. > >improve st (terminal) > +1 +1 Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Re: [dev] GSoC 2010
On Fri, Mar 05, 2010 at 12:47:12PM +0100, Uriel wrote: > Some people are supposedly working on an OpenBSD port, it is likely > that a port will be done long before GSoC actually starts. > > uriel Well, I do have a spare partition that I could throw Linux (stali?) or FreeBSD on, so it's not too big of an issue. I think that either of these projects would be a great fit for me. Josh
Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
On Fri, Mar 5, 2010 at 9:46 AM, Noah Birnel wrote: > On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: >> > sounds interesting >> > link/more info? >> > >> >> http://code.google.com/p/equanime > > Not Found > The requested URL /p/equanim/ was not found on this server. > > Typo? Or is it gone? The link is http://code.google.com/p/equanime not http://code.google.com/p/equanim -- # Kurt H Maier
Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
On Fri, Mar 05, 2010 at 06:46:37AM -0800, Noah Birnel wrote: > On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: > > > > http://code.google.com/p/equanime > > Not Found > The requested URL /p/equanim/ was not found on this server. > > Typo? Or is it gone? On your part. Note the final 'e'.
Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
On 5 March 2010 14:46, Noah Birnel wrote: > On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: >> > sounds interesting >> > link/more info? >> > >> >> http://code.google.com/p/equanime > > Not Found > The requested URL /p/equanim/ was not found on this server. > > Typo? Or is it gone? Works for me. Cheers, Anselm
Re: [Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
On Fri, Mar 05, 2010 at 01:18:51PM +0100, pancake wrote: > > sounds interesting > > link/more info? > > > > http://code.google.com/p/equanime Not Found The requested URL /p/equanim/ was not found on this server. Typo? Or is it gone? --Noah
[Fwd: Re: [Fwd: window system (Re: [dev] GSoC 2010)]]
--- Begin Message --- On Fri, Mar 5, 2010 at 12:46 PM, pancake wrote: > > > On 3/4/10, pancake wrote: >>> window system >>> >> a friend of me, who is a enlightenment developer is writing a new >> graphical system >> to replace X windows, it is not suckless, but really minimal, well >> designed and much >> more well done than the Xwindowing system (its not that hard to do it >> better :P) I >> can talk to him so maybe we can push this project. >> >> Its design supports multiple local/remote graphical devices, its >> everything done in >> userland, even framebuffer drivers for two ARM boards and SDL for normal >> testing. >> >> Actually is focusing on 2D, but will support XV and shaders for >> opengl-es at some point, >> he doesnt wants to fill the stack will the current shit of X11 where >> there are several >> layers to do the same shit. Another thing that could be implemented is a >> seamless X11 >> integration, so you can run X11 apps by grabbing the buffer of the >> window and rendering >> it into the graphical server. So it will not be 'that hard' to move from >> Xorg to it. > > sounds interesting > link/more info? > http://code.google.com/p/equanime > how will he handle the driver issue? The driver will be handled per OS through an abstraction layer. Right now the only one supported is Linux through the UIO: (userspace io driver) for interrupts and memory ranges; and the I2C userspace layer. > > > --- End Message ---
Re: [dev] GSoC 2010
On Fri, Mar 5, 2010 at 8:31 AM, pancake wrote: > Gogcc should work. Else you have Linux emulation. > > On Mar 5, 2010, at 12:36 AM, Josh Rickmar wrote: > >> On Thu, Mar 04, 2010 at 11:19:01PM +0100, Uriel wrote: >>> >>> I will note that one of the original goals for creating werc was to >>> help build a sane replacement for the kinds of things trac does, >>> including bug tracking. I would be happy to mentor any project that >>> works in that direction. >>> >>> uriel >> >> This seems like a project that I could do. I would like to do something >> like Goblin, but Go doesn't yet run on my OS (OpenBSD). Some people are supposedly working on an OpenBSD port, it is likely that a port will be done long before GSoC actually starts. uriel >> >> Josh >> > >
window system (Re: [dev] GSoC 2010)
On 3/4/10, pancake wrote: >> window system >> > a friend of me, who is a enlightenment developer is writing a new > graphical system > to replace X windows, it is not suckless, but really minimal, well > designed and much > more well done than the Xwindowing system (its not that hard to do it > better :P) I > can talk to him so maybe we can push this project. > > Its design supports multiple local/remote graphical devices, its > everything done in > userland, even framebuffer drivers for two ARM boards and SDL for normal > testing. > > Actually is focusing on 2D, but will support XV and shaders for > opengl-es at some point, > he doesnt wants to fill the stack will the current shit of X11 where > there are several > layers to do the same shit. Another thing that could be implemented is a > seamless X11 > integration, so you can run X11 apps by grabbing the buffer of the > window and rendering > it into the graphical server. So it will not be 'that hard' to move from > Xorg to it. sounds interesting link/more info? how will he handle the driver issue?
Re: [dev] GSoC 2010
Gogcc should work. Else you have Linux emulation. On Mar 5, 2010, at 12:36 AM, Josh Rickmar wrote: On Thu, Mar 04, 2010 at 11:19:01PM +0100, Uriel wrote: I will note that one of the original goals for creating werc was to help build a sane replacement for the kinds of things trac does, including bug tracking. I would be happy to mentor any project that works in that direction. uriel This seems like a project that I could do. I would like to do something like Goblin, but Go doesn't yet run on my OS (OpenBSD). Josh
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 11:19:01PM +0100, Uriel wrote: > I will note that one of the original goals for creating werc was to > help build a sane replacement for the kinds of things trac does, > including bug tracking. I would be happy to mentor any project that > works in that direction. > > uriel This seems like a project that I could do. I would like to do something like Goblin, but Go doesn't yet run on my OS (OpenBSD). Josh
Re: [dev] GSoC 2010
On Thu, Mar 4, 2010 at 12:40 PM, Szabolcs Nagy wrote: > let me summarise the ideas so far: > > stali > ld wrapper > window system > bug and issue tracker > improve dmc (mail) > widget tool kit > dwm in go > text indexing > ssl cert validation for surf > text editor > improve st (terminal) > port scanner > > if we need to focus the application in one area then these are not > very good i guess.. st and dmc are two projects that without doubt should be rewritten in Go. Window system, widget toolkit, text editor, and text indexing seem too general/unfocused/ambitious/limited. In my experience this kinds of GSoC projects are a bad idea and tend to produce useless mush (if they produce anything at all). Port scanner seems way too unrelated and unconnected to most of what suckless does (I'm not against it, but doesn't seem like a good idea if Google already thinks suckless is too much of a random bag of stuff). SSL validation for surf is plain stupid, why the hell is a whole project needed for that? Could just as well propose writing a replacement for OpenSSL (and yes, OpenSSL *sucks*, but if you think you can replace it you are an idiot). uriel
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 9:30 PM, Charlie Kester wrote: > On Wed 03 Mar 2010 at 11:17:14 PST Kurt H Maier wrote: >> >> On Wed, Mar 3, 2010 at 2:12 PM, Niki Yoshiuchi wrote: >>> >>> This is supposed to be a discussion on the Google Summer of Code, not a >>> nerd >>> fight about whether grep or awk is better, and how to manage files. Can >>> you >>> guys fork your discussion? >> >> you're right, but clearly the only way to decide whether a 'desktop >> text indexing system' qualifies as a gsoc project is a months-long >> mailing list flamewar > > "A suckless way to avoid months-long mailing list flamewars" sounds like > a good GSOC project. > > Oh wait, it's already been done. It's called "unsubscribe". No, it is called "killfile". uriel
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 7:30 PM, yy wrote: > 2010/3/3 Anders Andersson : >> On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: >>> Since Go was released I have been playing with it. Is there any >>> interest in the Go port of dwm? >> >> What would be the benefits of porting dwm to a new language? From my >> point of view, dwm is already functional and mature, porting it over >> to Go doesn't sound very constructive. >> >> // pipe >> >> > > I agree there are no inmediate benefits, but there is an incomplete > port in the repo (almost nothing) and I was asking if there was any > interest in finishing it. Anselm said, when Go was released, that he > was considering using Go for future suckless project. Although later > he decided he would wait until the language was more mature (which I > think was a right decission) I would consider porting dwm as a first > (experimental, if you want) step in that direction, not a final goal. > > Anyway, if there is no interest in the idea, that is perfectly fine, > and I won't arguee any more. There are many interesting projects. I > just thought I'd let it drop. > > @pancake: I would use xgb, which implements the X protocol, not C > bindings. In any way, I doubt you could notice the speed difference > between a Go and a C version of dwm (at least, not running it in > normal conditions; of course you could launch thousands of windows to > see which one is faster, but that would be even more stupid than > porting dwm to Go). > > @Anselm: I agree a MTA would be a good fit for Go. I would not apply > for that one, but it could be included in the ideas list. A werc port > would be interesting, I'd like to know uriel's opinion. As I said in #cat-v, I don't think it makes much sense, a great part of the essence of werc is that it is just a bunch of shell pipelines, and that makes customization and specialized one-off apps and other hacks really beautiful, because you can often do it by just adding an extra sed(1) or grep(1) call here or there. What I would like is to see rc and the rest of the p9p commands ported to Go, which is the goal of the Goblin project: http://repo.cat-v.org/goblin/ Some people have already started to do work on this (I'm a lazy asshole that has been distracted by other things, but I hope to get to it). Then werc could run directly on the Go toolset. uriel > -- > - yiyus || JGL . 4l77.com > >
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: > I'm still a student (PhD student, but that's fine for Google), so I > will probably apply to participate as a student. > > Since Go was released I have been playing with it. Is there any > interest in the Go port of dwm? This would probably include the > improvement of the xgb go package (which I don't know if it is fine, > since Google's projects like Go cannot take part in GSoC). Other part > of the project could be writing a widget toolkit, at least for the > status bar and, eventually, dmenu, but could include more widgets to > be a full toolkit (as Kurt suggested), or use the Go draw pkg (which > should be inproved too). I have some vague ideas about a layout > interface which could be shared between dwm and the widget toolkit. > I'm also interesting in porting dio to Go, if you think that would > make a nice project or could be included with the dwm port. Yes! I love all this ideas! > That said... I think what Google meant about lack of focus is that > writing software that sucks less is what everybody is trying, but not > a concrete objective. You could call dwm/dmenu/surf and the rest of > suckless projects part of a "desktop environment" (I know, I also hate > that name) or, even better, a "development environment" (the first one > not including an editor!). IOW, I think a goal clearer than "suckless > software" is needed. I completely agree. Suckless needs a cohesive goal, and creating the components of a simple, clean and elegant development environment that is true to the original Unix principles is a good such goal. uriel > > -- > - yiyus || JGL . 4l77.com > >
Re: [dev] GSoC 2010
I will note that one of the original goals for creating werc was to help build a sane replacement for the kinds of things trac does, including bug tracking. I would be happy to mentor any project that works in that direction. uriel On Wed, Mar 3, 2010 at 9:53 AM, Anselm R Garbe wrote: > Another idea that I'd like to push this year is the creation of a > suckless issue tracking/bug tracking system. All existing systems suck > and it is still a burden for projects and small businesses to track > bugs or customer issues in less sucking ways. The existing > alternatives are all a big desgrace, can't speak of those commercial > ones, but I guess they ain't any better than the floss ones. > > Approaches like trac do too many things, and hence fail at doing issue > tracking right. A friend pointed me to the debian bug tracking system > (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of > like parts of it. > > I think it is a strong requirement for a decent issue tracker to have > a decent mail integration, people don't want to use hairy web > interfaces and developers or customer relation staff doesn't wants to > use them either -- RT for instance is good in the mail integration, > but it does too many things and has a bad web interface that really > sucks. > > Kind regards, > Anselm > >
Re: [dev] GSoC 2010
On Thu, Mar 4, 2010 at 2:13 PM, anonymous wrote: > I really think sub-pixel antialiasing is a good topic for harmful.cat-v.org. I don't know enough about this to form a remotely useful opinion, much less rant about it. But contributions to harmful.cat-v.org are always welcome... uriel
Re: [dev] GSoC 2010
Here is an idea the Google folks might like: Port sta.li (and p9p?) to use Android's libc. AFAIK there is no real linux distro that uses the Android libc, and this would be a project that might be useful for everyone. uriel On Wed, Mar 3, 2010 at 9:41 AM, Anselm R Garbe wrote: > On 3 March 2010 08:22, Martin Kopta wrote: >> On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: >>> Hi there, >>> >>> GSoC 2010 has kicked of and is looking for mentoring organisations >>> next week, hence it's time now to get organised. >>> >>> Who is willing to mentor this time? >>> >>> What project ideas do you have apart from http://suckless.org/project_ideas? >> >> "Create stali stable release" > > Stali is definately a topic, forgot to mention this. The project idea > a colleague of mine at work came up with is creating wether a > completely new ld or ld wrapper at the least to collect all info when > a shared lib/executable is linked and using this info to create a > static library/executable instead, basically kind of a tee ld if you > like, where one result invisible to the caller is a static lib instead > of a dynamic one ;) This would enable building nearly everything > statically without the need of extra makefiles. I don't consider this > approach for the base system, since the value in it is all about > decent make files, but this might be a cool project for all other > stuff and would fit the GSoC scope quite well. > > Cheers, > Anselm > >
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 12:40:17PM +0100, Szabolcs Nagy wrote: > let me summarise the ideas so far: > > stali > ld wrapper > window system > bug and issue tracker > improve dmc (mail) > widget tool kit > dwm in go > text indexing > ssl cert validation for surf > text editor > improve st (terminal) > port scanner > > if we need to focus the application in one area then these are not > very good i guess.. > What about a usable interface for facebook? IIRC, there was some talk about this on this list a while back.
Re: [dev] GSoC 2010
Sub-pixel antialiasing - the vengeance of the color-blind ;)
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 01:51:12PM +0100, Mate Nagy wrote: > In non-uriel style, yes, font rendering is horribly complicated and an > entirely fucked up discipline, but I don't think a "real" widget set can > skip out on it. Bitmap fonts are fine for programming (and I even use it > for web browsing when it's dark and I switch the theme to > white-on-black), but often sub-pixel tuned ttf is just more comfortable > to read. I really think sub-pixel antialiasing is a good topic for harmful.cat-v.org.
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 12:57:31PM +, Anselm R Garbe wrote: > Well one design decision for the API I'm in favor with is not to > provide any font-related functionality in the first version and leave > font rendering up to the implementation. If someone writes an app he > shouldn't bother about the fonts/colors etc, he should concentrate on > the functionality -- this also enforces a consistent look among all > programs that might use dwk. I agree something like this would be fantastic for small suckless GUI projects (if that wasn't an oxymoron... but I'm not certain about this at all, either way) Mate
Re: [dev] GSoC 2010
On 4 March 2010 12:51, Mate Nagy wrote: > On Thu, Mar 04, 2010 at 01:44:04PM +0100, pancake wrote: > >> why do you need TTF? font rendering is a really complex stuff, in dwk > yes >> we were only planning to support monospaced fonts, calculate sizes > yes >> with changing size of fonts is really complex and cpu-intensive task and > yes >> i dont think it matters to the user. > no, sorry > > In non-uriel style, yes, font rendering is horribly complicated and an > entirely fucked up discipline, but I don't think a "real" widget set can > skip out on it. Bitmap fonts are fine for programming (and I even use it > for web browsing when it's dark and I switch the theme to > white-on-black), but often sub-pixel tuned ttf is just more comfortable > to read. > > Actually I wrote a similar widget set that I use in frtplot > (frtplot.port70.net), straight C and everything, and.. it only does > bitmap font rendering (no Unicode though). But I wouldn't want to use it > for software that isn't exclusively for programmers.. Well one design decision for the API I'm in favor with is not to provide any font-related functionality in the first version and leave font rendering up to the implementation. If someone writes an app he shouldn't bother about the fonts/colors etc, he should concentrate on the functionality -- this also enforces a consistent look among all programs that might use dwk. Cheers, Anselm
Re: [dev] GSoC 2010
On 4 March 2010 12:48, Connor Lane Smith wrote: > On 4 March 2010 11:40, Szabolcs Nagy wrote: >> if we need to focus the application in one area then these are not >> very good i guess.. > > A lot of them have a theme, though. Gnome's GSoC theme is basically > their desktop environment, which is fairly broad itself. If Suckless > focus on a development environment (similar, but not so crufty), > suggested projects include; > > OS: stali > WS: dws > WM: godwm > Toolkit: dwk > Web: surf ssl certs > Mail: dmc > Editor: samterm? > Term: st > Search? > > There may be others (bugs and goblins?), but that's quite a cohesive > collection really. The only issue Google could bring up is that > Suckless is fairly small, and that it may be too broad for its size. > I'm not sure that can be avoided though. Apparently that was no reason last year according to them. Well and they accepted smaller projects in the past... Cheers, Anselm
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 01:44:04PM +0100, pancake wrote: > why do you need TTF? font rendering is a really complex stuff, in dwk yes > we were only planning to support monospaced fonts, calculate sizes yes > with changing size of fonts is really complex and cpu-intensive task and yes > i dont think it matters to the user. no, sorry In non-uriel style, yes, font rendering is horribly complicated and an entirely fucked up discipline, but I don't think a "real" widget set can skip out on it. Bitmap fonts are fine for programming (and I even use it for web browsing when it's dark and I switch the theme to white-on-black), but often sub-pixel tuned ttf is just more comfortable to read. Actually I wrote a similar widget set that I use in frtplot (frtplot.port70.net), straight C and everything, and.. it only does bitmap font rendering (no Unicode though). But I wouldn't want to use it for software that isn't exclusively for programmers.. Mate
Re: [dev] GSoC 2010
On 4 March 2010 11:40, Szabolcs Nagy wrote: > if we need to focus the application in one area then these are not > very good i guess.. A lot of them have a theme, though. Gnome's GSoC theme is basically their desktop environment, which is fairly broad itself. If Suckless focus on a development environment (similar, but not so crufty), suggested projects include; OS: stali WS: dws WM: godwm Toolkit: dwk Web: surf ssl certs Mail: dmc Editor: samterm? Term: st Search? There may be others (bugs and goblins?), but that's quite a cohesive collection really. The only issue Google could bring up is that Suckless is fairly small, and that it may be too broad for its size. I'm not sure that can be avoided though. On Thu, Mar 4, 2010 at 12:07 PM, pancake wrote: > > text editor > this depends on the widget toolkit and its a quite difficult task. This is true, unless it uses curses. cls
Re: [dev] GSoC 2010
On 4 March 2010 12:14, Frederic DUBOIS wrote: >>> widget tool kit >>> >> >> Anselm and me were discussing about the widget toolkit, the code name of the >> project >> is "dwk" Dynamic Widget Kit. which is atm just a README with few random >> ideas. >> >> http://hg.youterm.com/dwk > > Something like GraphApp? (http://www.enchantia.com/software/graphapp/) Hmm, something simpler than that ;) Cheers, Anselm
Re: [dev] GSoC 2010
2010/3/4 Mate Nagy : > On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote: > >> Something like GraphApp? (http://www.enchantia.com/software/graphapp/) > looks nice until you realize it doesn't support fonts (and they even > ideologized it for themselves in the FAQ) > It does. It is even easier and more convenient to use the system fonts than the portable fonts.
Re: [dev] GSoC 2010
Mate Nagy wrote: On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote: Something like GraphApp? (http://www.enchantia.com/software/graphapp/) looks nice until you realize it doesn't support fonts (and they even ideologized it for themselves in the FAQ) Mate why do you need TTF? font rendering is a really complex stuff, in dwk we were only planning to support monospaced fonts, calculate sizes with changing size of fonts is really complex and cpu-intensive task and i dont think it matters to the user. i dont want comic sans in my "desktop" --pancake
Re: [dev] GSoC 2010
On Thu, Mar 04, 2010 at 01:14:37PM +0100, Frederic DUBOIS wrote: > Something like GraphApp? (http://www.enchantia.com/software/graphapp/) looks nice until you realize it doesn't support fonts (and they even ideologized it for themselves in the FAQ) Mate
Re: [dev] GSoC 2010
>> widget tool kit >> > > Anselm and me were discussing about the widget toolkit, the code name of the > project > is "dwk" Dynamic Widget Kit. which is atm just a README with few random > ideas. > > http://hg.youterm.com/dwk Something like GraphApp? (http://www.enchantia.com/software/graphapp/)
Re: [dev] GSoC 2010
Szabolcs Nagy wrote: let me summarise the ideas so far: stali ld wrapper I didnt understood the concept at all. can somebody explain it better? window system a friend of me, who is a enlightenment developer is writing a new graphical system to replace X windows, it is not suckless, but really minimal, well designed and much more well done than the Xwindowing system (its not that hard to do it better :P) I can talk to him so maybe we can push this project. Its design supports multiple local/remote graphical devices, its everything done in userland, even framebuffer drivers for two ARM boards and SDL for normal testing. Actually is focusing on 2D, but will support XV and shaders for opengl-es at some point, he doesnt wants to fill the stack will the current shit of X11 where there are several layers to do the same shit. Another thing that could be implemented is a seamless X11 integration, so you can run X11 apps by grabbing the buffer of the window and rendering it into the graphical server. So it will not be 'that hard' to move from Xorg to it. bug and issue tracker improve dmc (mail) +1 widget tool kit Anselm and me were discussing about the widget toolkit, the code name of the project is "dwk" Dynamic Widget Kit. which is atm just a README with few random ideas. We (arg and me) are currently quite busy, but we plan to start working on it before the end of this month (at least me). If any of you want to have a look on the current status of the project check the mercurial repo. Feel free to open a new thread and discuss ideas, proposals, etc, for it. http://hg.youterm.com/dwk dwm in go i dont see the point a part that the fun of doing it. text indexing ?? ssl cert validation for surf +1 There are several other issues in surf 1) infinite loops in some situations (redirects with closed socket instead of keepalive) 2) segmentation faults when using AJAX using local files instead of remote ones 3) multiple empty queries when returning NULL headers by the server 4) downloads not working at all (i still have issues with them) 5) context menu doesnt allows to copy url of a picture 6) no automatic history support to log all visited urls with dmenu autocompletion ... text editor this depends on the widget toolkit and its a quite difficult task. improve st (terminal) +1 port scanner the port scanner is already done, but needs some enhacements, like support for scanning multiples IPs without having to use shell loops. i always wanted something minimal for "nmap -sP 192.168.0.*" if we need to focus the application in one area then these are not very good i guess..
Re: [dev] GSoC 2010
On 4 March 2010 11:40, Szabolcs Nagy wrote: > let me summarise the ideas so far: > > stali > ld wrapper > window system > bug and issue tracker > improve dmc (mail) > widget tool kit > dwm in go > text indexing > ssl cert validation for surf > text editor > improve st (terminal) > port scanner > > if we need to focus the application in one area then these are not > very good i guess.. Uriel was proposing goblin in #cat-v, basically unix/plan9 userland written in Go. Cheers, Anselm
Re: [dev] GSoC 2010
let me summarise the ideas so far: stali ld wrapper window system bug and issue tracker improve dmc (mail) widget tool kit dwm in go text indexing ssl cert validation for surf text editor improve st (terminal) port scanner if we need to focus the application in one area then these are not very good i guess..
Re: [dev] GSoC 2010
I think this is a good project idea, and it would prove more than useful also im looking forward to the simple port scanner, these project ideas have caugth my attention. On Wed, Mar 03, 2010 at 03:41:12PM +0100, Nicolai Waniek wrote: > On 03/03/2010 02:46 PM, Peter John Hartman wrote: > > I agree about the issue trackers + the mail integration. A small > > suggestion: none of the issue/bug tracking systems do collaboration very > > well either. What I mean by "collaboration" is the capacity to pass a > > single document back and forth with several "notes" appended to it. a > > giant > > You might think on a distributed bug-tracking system similar to a list of > bug-reports inside a git system with the possibility to create new bugreports > "on the fly" when the mail-server receives a specific mail (you somehow have > to > define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). > There should be a 'central' (though not required) bug-tracking server for all > those coming with bugs on you project-website. there, the current bug list and > state is a available and an interface to add new bugs. then you could place > some sort of hooks into your bugtracker (bt) configuration: > bt/.config/new-> send mail to mail-adress with new bug > then you can manage bug-notification via mailing lists. For users that don't > want to use the website, you could listen on mails in a specific form/with a > specific header to pass it directly to bt parsing it. if the parsing fails, > automagically send a mail back to the composer with annotation where it > failed, > if successfull, send back a success-mail. > > usage could be like (in a distributed way): > $ cd bugs/projectname > bugs/projectname $ bt pull # pulls all new bugreports from server > 7 new bugreports > bugs/projectname $ >51 unresolved bugs > 123 pending bugs > > where 'pending' means that their state is in "needs check if the bugfix works > or not, waiting for approval" or something like that. > > If you want to make comments to a file, make them and afterwards a > bugs/projectname $ bt commit -m "some annotation" > bugs/projectname $ bt send # send new file to whole mailinglist > bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a > specific user > > would do the rest. > > something like that. Didn't think too carefully on it. >
Re: [dev] GSoC 2010
On Wed, 3 Mar 2010 16:27:34 -0500 Jacob Todd wrote: > I'd like to see dmc improved upon. In it's current state it can already send > mail with smtp, but there are also aspects of it that could be polished a bit > more, like being able to receive mail, pgp support, et cetera. well. in fact, the support for sending mails is done by msmtp, the current smtp implementation doesnt supports authentication and fails in many situations. It would be good to get a look on it. Maybe by relaying on a real smtp local server would be enought, or just by calling 'mail'. attachment management has been already implemented (attach, detach), in a unix way in 160LOC. by using stdin/stdout. there is some basic support to receive mail. for pop3 its ok, but in imap4 there are some issues. the most common usage atm is as a shell to query imap mail remotely. a better syncronization algorithm should be done to get faster syncs. as you see there are many fronts there :) pgp support would be interesting too. --pancake
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 07:16:22PM -0500, Jacob Todd wrote: > On Wed, Mar 03, 2010 at 07:01:48PM -0500, Josh Rickmar wrote: > > Should probably say that I'm also a student (studying Computer > > Engineering at the University of Michigan) that would be interested in > > doing something like this. I don't yet know what exact project I'd like > > to take, keep posting ideas. > > > Which U of M are you studying at? > > Another suggestion: more work on st. The one in Ann Arbor.
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 07:01:48PM -0500, Josh Rickmar wrote: > Should probably say that I'm also a student (studying Computer > Engineering at the University of Michigan) that would be interested in > doing something like this. I don't yet know what exact project I'd like > to take, keep posting ideas. > Which U of M are you studying at? Another suggestion: more work on st. -- I am a man who does not exist for others. pgpznl6RRBILm.pgp Description: PGP signature
Re: [dev] GSoC 2010
Should probably say that I'm also a student (studying Computer Engineering at the University of Michigan) that would be interested in doing something like this. I don't yet know what exact project I'd like to take, keep posting ideas.
Re: [dev] GSoC 2010
I'm an interested student as well; I'm a senior in Providence, Rhode Island, USA, doing a master's next year. -POLM
Re: [dev] GSoC 2010
Hi, yet another student here, of the second year British variety. I'd be interested in getting involved along the lines of a development environment with something like a suckless text editor, with decent mouse interaction a la Acme. Could be better to leave the terminal and use X11. Personally, I need to learn my way around Plan 9 a bit more too, so I'd love to write something Unix-native that's similar to one of their tools. Rob
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 09:47:08PM +, Connor Lane Smith wrote: > As an aside, where are the stali utils from? Not GNU, surely? It's using a OpenBSD userland if I recall.
Re: [dev] GSoC 2010
Hey all, I'm a first year student, and I'd be interested in helping out for GSoC. I like the idea of centring the projects on a "development environment", which doesn't seem too broad. I'm personally interested in writing a Unix-native samterm of some kind (I love sam, but not the Plan 9 samterm), but another project could be good too. I really like the idea of a suckless toolkit, but doubt I'd be cut out for that. As an aside, where are the stali utils from? Not GNU, surely? Thanks, cls
Re: [dev] GSoC 2010
I'd like to see dmc improved upon. In it's current state it can already send mail with smtp, but there are also aspects of it that could be polished a bit more, like being able to receive mail, pgp support, et cetera. More work on stali would be very nice, too. -- I am a man who does not exist for others. pgpJtql9E3Vz2.pgp Description: PGP signature
Re: [dev] GSoC 2010
On Wed 03 Mar 2010 at 11:17:14 PST Kurt H Maier wrote: On Wed, Mar 3, 2010 at 2:12 PM, Niki Yoshiuchi wrote: This is supposed to be a discussion on the Google Summer of Code, not a nerd fight about whether grep or awk is better, and how to manage files. Can you guys fork your discussion? you're right, but clearly the only way to decide whether a 'desktop text indexing system' qualifies as a gsoc project is a months-long mailing list flamewar "A suckless way to avoid months-long mailing list flamewars" sounds like a good GSOC project. Oh wait, it's already been done. It's called "unsubscribe".
Re: [dev] GSoC 2010
On 3/3/10, Antoni Grzymala wrote: > $ strings /tmp/grep | /tmp/grep -i network > Machine is not on the network > Name not unique on network > Network is down > Network is unreachable > Network dropped connection on reset > > and valuable Xenix support: > > Not a XENIX named type file > No XENIX semaphores available > > :) i guess these come from linked libc functions.. funny nevertheless
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 2:12 PM, Niki Yoshiuchi wrote: > This is supposed to be a discussion on the Google Summer of Code, not a nerd > fight about whether grep or awk is better, and how to manage files. Can you > guys fork your discussion? you're right, but clearly the only way to decide whether a 'desktop text indexing system' qualifies as a gsoc project is a months-long mailing list flamewar -- # Kurt H Maier
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 2:10 PM, Chris Palmer wrote: > Please tell us about your data organization scheme, such that you can find > anything you have -- email, PDFs, Postscript, music, text files, HTML files, > et c. -- in the same amount of time a Google, Google Desktop, Spotlight, or > Windows Search query takes. If you have never used any of those systems, > I'll tell you: the amount of time is about 1/10th of a second. you've misstated the problem. I almost never need to find information without having any clue where it is. if I need something from a PDF, it's probably with all my other PDFs. if I need something from email, it's probably in a maildir. with this powerful indexing system, I don't have to grep my whole hard drive to find granny's phone number. if it came in an email, then I can cd to maildir and grep -r. if it for some reason is in a pdf, well, grep works on binary data too! like some kind of miracle, this 'remembering where you put shit' technology is available for free, and it's cross-platform!1 > Having too much data? So rm is your search system? see above re: advanced 'not being a moron' techniques > I think you've had a few too many PCP-spiked Coors Lites. please explain your obsession with coors lite thanks -- # Kurt H Maier
Re: [dev] GSoC 2010
This is supposed to be a discussion on the Google Summer of Code, not a nerd fight about whether grep or awk is better, and how to manage files. Can you guys fork your discussion? On Wed, Mar 3, 2010 at 2:13 PM, Chris Palmer wrote: > Anders Andersson writes: > > > p...@airwaves:~$ size `which awk` > >textdata bss dec hex filename > > 3134831392 20584 335459 51e63 /usr/bin/awk > > Small price to pay for something that can basically do the job of almost > the > entire Unix userland. > > Also, yours is bloated (but still not too large given what it can do). > > 11:11 ~ ; size $(which awk) >textdata bss dec hex filename > 11871228804640 126232 1ed18 /usr/bin/awk > > >
Re: [dev] GSoC 2010
Anders Andersson writes: > p...@airwaves:~$ size `which awk` >textdata bss dec hex filename > 3134831392 20584 335459 51e63 /usr/bin/awk Small price to pay for something that can basically do the job of almost the entire Unix userland. Also, yours is bloated (but still not too large given what it can do). 11:11 ~ ; size $(which awk) textdata bss dec hex filename 11871228804640 126232 1ed18 /usr/bin/awk
Re: [dev] GSoC 2010
Kurt H Maier writes: > it's not my fault you're bad at organizing your data Please tell us about your data organization scheme, such that you can find anything you have -- email, PDFs, Postscript, music, text files, HTML files, et c. -- in the same amount of time a Google, Google Desktop, Spotlight, or Windows Search query takes. If you have never used any of those systems, I'll tell you: the amount of time is about 1/10th of a second. > if you think you need a 'desktop text indexing system', chances are you > are doing something wrong Having too much data? So rm is your search system? > if you could actually write simple awk scripts you wouldn't need a > 'desktop text indexing system' I think you've had a few too many PCP-spiked Coors Lites.
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 8:05 PM, Chris Palmer wrote: > Anselm R Garbe writes: > >> Stali's grep is smaller than your bloated 78kb dynamic executable, see >> attached. It's 63kb actually and runs on all x86 linux platforms. > > An awk script equivalent to grep is at least one order of magnitude smaller, > and possibly two. p...@airwaves:~$ size `which awk` textdata bss dec hex filename 3134831392 20584 335459 51e63 /usr/bin/awk
Re: [dev] GSoC 2010
Anselm R Garbe dixit (2010-03-03, 18:55): > On 3 March 2010 18:33, Chris Palmer wrote: > > Kurt H Maier writes: > > > >> > We need a desktop text indexing system that sucks less. > >> > >> grep > > > > First of all, I had never heard of this program. It is so great! Wow! Thanks > > for the suggestion! In 45 minutes when my query has completed, I'll buy you > > a beer. I assume you prefer Coors Lite? > > > > Second, the newly-discovered grep program is horrible bloatware. 78KB on my > > system (the stali version will be larger due to static linking), when a > > simple awk script would suffice for the same purpose? Man, the people > > writing this new bleeding-edge software sure have no conception of the > > beauty of simplicity that reigned in the old days. > > Stali's grep is smaller than your bloated 78kb dynamic executable, see > attached. It's 63kb actually and runs on all x86 linux platforms. Cool, seems like it's got secret netcat functionality built in: $ strings /tmp/grep | /tmp/grep -i network Machine is not on the network Name not unique on network Network is down Network is unreachable Network dropped connection on reset and valuable Xenix support: Not a XENIX named type file No XENIX semaphores available :) -- [a]
Re: [dev] GSoC 2010
Anselm R Garbe writes: > Stali's grep is smaller than your bloated 78kb dynamic executable, see > attached. It's 63kb actually and runs on all x86 linux platforms. An awk script equivalent to grep is at least one order of magnitude smaller, and possibly two.
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 1:33 PM, Chris Palmer wrote: > Kurt H Maier writes: > >> > We need a desktop text indexing system that sucks less. >> >> grep > > First of all, I had never heard of this program. It is so great! Wow! Thanks > for the suggestion! In 45 minutes when my query has completed, I'll buy you > a beer. I assume you prefer Coors Lite? it's not my fault you're bad at organizing your data if you think you need a 'desktop text indexing system', chances are you are doing something wrong > Second, the newly-discovered grep program is horrible bloatware. 78KB on my > system (the stali version will be larger due to static linking), when a > simple awk script would suffice for the same purpose? Man, the people > writing this new bleeding-edge software sure have no conception of the > beauty of simplicity that reigned in the old days. if you could actually write simple awk scripts you wouldn't need a 'desktop text indexing system' -- # Kurt H Maier
Re: [dev] GSoC 2010
David Thiel writes: > > grep > > ...is not an example of an indexing system. That's a feature, not a bug. Hash tables are bloatware. If you can't do it with linear search, you shouldn't do it. Don't even get me started on red-black trees... > While such a system would be useful, I'm doubtful that a ``suckless'' one > could be made. It inherently involves lots of parsers for different file > type metadata, which either introduces lots of code or lots of > dependencies. Lots of small programs working together in a pipeline. Also, strings foo.mp3 | delete_junk_words | index ... would work for MP3s. These small programs need not be particularly complex. Obviously, the nastier PDFs will need some help and there's no avoiding that. But it would be worth it.
Re: [dev] GSoC 2010
Kurt H Maier writes: > > We need a desktop text indexing system that sucks less. > > grep First of all, I had never heard of this program. It is so great! Wow! Thanks for the suggestion! In 45 minutes when my query has completed, I'll buy you a beer. I assume you prefer Coors Lite? Second, the newly-discovered grep program is horrible bloatware. 78KB on my system (the stali version will be larger due to static linking), when a simple awk script would suffice for the same purpose? Man, the people writing this new bleeding-edge software sure have no conception of the beauty of simplicity that reigned in the old days.
Re: [dev] GSoC 2010
2010/3/3 Anders Andersson : > On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: >> Since Go was released I have been playing with it. Is there any >> interest in the Go port of dwm? > > What would be the benefits of porting dwm to a new language? From my > point of view, dwm is already functional and mature, porting it over > to Go doesn't sound very constructive. > > // pipe > > I agree there are no inmediate benefits, but there is an incomplete port in the repo (almost nothing) and I was asking if there was any interest in finishing it. Anselm said, when Go was released, that he was considering using Go for future suckless project. Although later he decided he would wait until the language was more mature (which I think was a right decission) I would consider porting dwm as a first (experimental, if you want) step in that direction, not a final goal. Anyway, if there is no interest in the idea, that is perfectly fine, and I won't arguee any more. There are many interesting projects. I just thought I'd let it drop. @pancake: I would use xgb, which implements the X protocol, not C bindings. In any way, I doubt you could notice the speed difference between a Go and a C version of dwm (at least, not running it in normal conditions; of course you could launch thousands of windows to see which one is faster, but that would be even more stupid than porting dwm to Go). @Anselm: I agree a MTA would be a good fit for Go. I would not apply for that one, but it could be included in the ideas list. A werc port would be interesting, I'd like to know uriel's opinion. -- - yiyus || JGL . 4l77.com
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > What project ideas do you have apart from http://suckless.org/project_ideas? SSH-model SSL certificate validation for surf.
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 01:11:00PM -0500, Kurt H Maier wrote: > On Wed, Mar 3, 2010 at 12:55 PM, Chris Palmer wrote: > > We need a desktop text indexing system that sucks less. > > grep ...is not an example of an indexing system. While such a system would be useful, I'm doubtful that a ``suckless'' one could be made. It inherently involves lots of parsers for different file type metadata, which either introduces lots of code or lots of dependencies.
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 12:55 PM, Chris Palmer wrote: > We need a desktop text indexing system that sucks less. grep -- # Kurt H Maier
Re: [dev] GSoC 2010
pancake writes: > >We need a desktop text indexing system that sucks less. > > desktop sucks by definition. You are very helpful. How about "We need a text indexing system for personal data stored locally on small computers that sucks less."
Re: [dev] GSoC 2010
On 03/03/2010 06:28 PM, Anders Andersson wrote: > What would be the benefits of porting dwm to a new language? From my > point of view, dwm is already functional and mature, porting it over > to Go doesn't sound very constructive. And porting it is a real pain, at the moment. For example, you don't have bindings to xlib. It is possible via cgo to create bindings, but it's not that straightforward to use them. If the decision is made to take xgb (the xcb port for Go), one will notice that xgb is a rather premature state. Some time ago I tried out small apps with xcb (to get familiar with it) in C, and one of them was to simply port dwm's most basic functionality to xcb. About 4 weeks ago I tried to port this to Go and xgb, which resulted in me changing the xgb part because somehow the xgb developers lost track and sense what xgb is. For example, instead of having an error handler facility, xgb prints out the error and even worse - in some cases you don't have the possibilty to get the error at all or even don't get a status that an error occured, the only thing that happens is that an error message is written to stdout... That said, when thinking about porting dwm to something like go and despite that I don't really like xcb, a stable/working/sane/suckless xgb would be a decent way to go as with Go's easy multithreading, the asynchronity would reach another level. nw
Re: [dev] GSoC 2010
Chris Palmer wrote: We need a desktop text indexing system that sucks less. desktop sucks by definition.
Re: [dev] GSoC 2010
On 3 March 2010 16:38, yy wrote: > I'm still a student (PhD student, but that's fine for Google), so I > will probably apply to participate as a student. > > Since Go was released I have been playing with it. Is there any > interest in the Go port of dwm? This would probably include the > improvement of the xgb go package (which I don't know if it is fine, > since Google's projects like Go cannot take part in GSoC). Other part > of the project could be writing a widget toolkit, at least for the > status bar and, eventually, dmenu, but could include more widgets to > be a full toolkit (as Kurt suggested), or use the Go draw pkg (which > should be inproved too). I have some vague ideas about a layout > interface which could be shared between dwm and the widget toolkit. > I'm also interesting in porting dio to Go, if you think that would > make a nice project or could be included with the dwm port. > > That said... I think what Google meant about lack of focus is that > writing software that sucks less is what everybody is trying, but not > a concrete objective. You could call dwm/dmenu/surf and the rest of > suckless projects part of a "desktop environment" (I know, I also hate > that name) or, even better, a "development environment" (the first one > not including an editor!). IOW, I think a goal clearer than "suckless > software" is needed. I'd say Go sounds like an interesting lang for a decent MTA and issue tracker, perhaps even considering the idea to implement werc in Go ;) Cheers, Anselm
Re: [dev] GSoC 2010
We need a desktop text indexing system that sucks less.
Re: [dev] GSoC 2010
EDUCATIONAL PURPOSES ONLY. dwm in go takes not much sense from my point of view. It will make code slower, afaik C bindings are not as clean as writnig C directly and there's no interesting feature from Go to be used in dwm code. Anders Andersson wrote: On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: Since Go was released I have been playing with it. Is there any interest in the Go port of dwm? What would be the benefits of porting dwm to a new language? From my point of view, dwm is already functional and mature, porting it over to Go doesn't sound very constructive. // pipe
Re: [dev] GSoC 2010
On Wed, Mar 3, 2010 at 5:38 PM, yy wrote: > Since Go was released I have been playing with it. Is there any > interest in the Go port of dwm? What would be the benefits of porting dwm to a new language? From my point of view, dwm is already functional and mature, porting it over to Go doesn't sound very constructive. // pipe
Re: [dev] GSoC 2010
I'm still a student (PhD student, but that's fine for Google), so I will probably apply to participate as a student. Since Go was released I have been playing with it. Is there any interest in the Go port of dwm? This would probably include the improvement of the xgb go package (which I don't know if it is fine, since Google's projects like Go cannot take part in GSoC). Other part of the project could be writing a widget toolkit, at least for the status bar and, eventually, dmenu, but could include more widgets to be a full toolkit (as Kurt suggested), or use the Go draw pkg (which should be inproved too). I have some vague ideas about a layout interface which could be shared between dwm and the widget toolkit. I'm also interesting in porting dio to Go, if you think that would make a nice project or could be included with the dwm port. That said... I think what Google meant about lack of focus is that writing software that sucks less is what everybody is trying, but not a concrete objective. You could call dwm/dmenu/surf and the rest of suckless projects part of a "desktop environment" (I know, I also hate that name) or, even better, a "development environment" (the first one not including an editor!). IOW, I think a goal clearer than "suckless software" is needed. -- - yiyus || JGL . 4l77.com
Re: [dev] GSoC 2010
Anselm, I saw where you had some base ideas for a widget toolkit. I think that'd be a great GSoC project. I also support the bug tracking software idea, but a non-retarded toolkit would make my day. -- # Kurt H Maier
Re: [dev] GSoC 2010
On 03/03/2010 02:46 PM, Peter John Hartman wrote: > I agree about the issue trackers + the mail integration. A small > suggestion: none of the issue/bug tracking systems do collaboration very > well either. What I mean by "collaboration" is the capacity to pass a > single document back and forth with several "notes" appended to it. a > giant You might think on a distributed bug-tracking system similar to a list of bug-reports inside a git system with the possibility to create new bugreports "on the fly" when the mail-server receives a specific mail (you somehow have to define a standar like "SHORT, FROM, DESCRIPTION, STEPS" and so on). There should be a 'central' (though not required) bug-tracking server for all those coming with bugs on you project-website. there, the current bug list and state is a available and an interface to add new bugs. then you could place some sort of hooks into your bugtracker (bt) configuration: bt/.config/new -> send mail to mail-adress with new bug then you can manage bug-notification via mailing lists. For users that don't want to use the website, you could listen on mails in a specific form/with a specific header to pass it directly to bt parsing it. if the parsing fails, automagically send a mail back to the composer with annotation where it failed, if successfull, send back a success-mail. usage could be like (in a distributed way): $ cd bugs/projectname bugs/projectname $ bt pull # pulls all new bugreports from server 7 new bugreports bugs/projectname $ 51 unresolved bugs 123 pending bugs where 'pending' means that their state is in "needs check if the bugfix works or not, waiting for approval" or something like that. If you want to make comments to a file, make them and afterwards a bugs/projectname $ bt commit -m "some annotation" bugs/projectname $ bt send # send new file to whole mailinglist bugs/projectname $ bt send some.u...@host.tld # send your changeset just to a specific user would do the rest. something like that. Didn't think too carefully on it.
Re: [dev] GSoC 2010
I agree about the issue trackers + the mail integration. A small suggestion: none of the issue/bug tracking systems do collaboration very well either. What I mean by "collaboration" is the capacity to pass a single document back and forth with several "notes" appended to it. a giant "comments" list isn't very good (no inline comments) and forums are dumb. Peter -- sic dicit magister P. http://individual.utoronto.ca/peterjh/ On Wed, 3 Mar 2010, Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
Hi folks, I found some interesting issue-/bug tracking system last week. Even its written in Python the idea is cool. Bugs Everywhere (http://bugseverywhere.org/) uses the underlying scm (aka git, hg, bzr) to store its data on. It has also a mail-frontend like the debian BTS (didnt tried it, just read it). Maybee its such a solution you want to have for suckless bugtracking. If it jet sucks less is another question. -Chris On Wed, Mar 03, 2010 at 08:53:50AM +, Anselm R Garbe wrote: > Another idea that I'd like to push this year is the creation of a > suckless issue tracking/bug tracking system. All existing systems suck > and it is still a burden for projects and small businesses to track > bugs or customer issues in less sucking ways. The existing > alternatives are all a big desgrace, can't speak of those commercial > ones, but I guess they ain't any better than the floss ones. > > Approaches like trac do too many things, and hence fail at doing issue > tracking right. A friend pointed me to the debian bug tracking system > (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of > like parts of it. > > I think it is a strong requirement for a decent issue tracker to have > a decent mail integration, people don't want to use hairy web > interfaces and developers or customer relation staff doesn't wants to > use them either -- RT for instance is good in the mail integration, > but it does too many things and has a bad web interface that really > sucks. > > Kind regards, > Anselm signature.asc Description: Digital signature
Re: [dev] GSoC 2010
On 3 March 2010 10:09, pancake wrote: > About the distro I think it requires so many stuff on it, so at this moment > I think is more important to push partial projects before working on stali. These are the current main drivers of stali (or my take on it): a) having a decent toolchain and build system for embedded development (which is lacking big time in most of such projects like maemo and friends), the real value are the mkfile's here that ignore the configure hell completely. b) to prove that static linking produces slimmer systems that run faster, use less memory and are more secure -- contrary to all those pseudo-arguments the dynamic linking fan boys came up with. Cheers, Anselm
Re: [dev] GSoC 2010
About the mail part of the bug tracker.. why not push 'dmc'? and fix the imap protocol, implement the SMTP part and write a frontend. This can sound like not so much work..but it does from the side that it is actually not usable application, and it needs some love. I think that a decent minimal mail solution is mandatory for most of us.. So.. is anyone going to work on it? :) --pancake Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
+1 Current bugtrackers sucks. The linker proposal, looks interesting, but i dont get the idea at all, i would do it if i get bored somewhile..but i can't trick google to say that i'm a student. Is your idea to create a static bin from a shared one? There's a program called 'staticify' or something like this that does it. Do somebody checked 'bug'? a simple todo/bugtracker for commandline? http://vicerveza.homeunix.net/~viric/soft/bug/ Another topic I would like to open is about 'suckless games'. Recently I have discovered 'jvgs' and 'ledboy' which bring me some fun and think about minimalistic games with fun inside, originality and clean code. The problem here for example..is that jvgs is c++ with stupid dependencies like lua or cmake, ledboy is just hardware, most of games are bloated, filled with silly graphics and big media stuff, but lacking any kind of simplicity and clean code on it. http://jvgs.sourceforge.net/ http://hackaday.com/2009/12/08/ledboy-super-pixel-brothers/ Sure, there are bsdgames, and few years ago I wrote 'pag' a platform arcade game in text mode..but the code I wrote 10 years ago sucks.. http://hg.youterm.com/pag About the distro I think it requires so many stuff on it, so at this moment I think is more important to push partial projects before working on stali. --pancake Anselm R Garbe wrote: Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
Another idea that I'd like to push this year is the creation of a suckless issue tracking/bug tracking system. All existing systems suck and it is still a burden for projects and small businesses to track bugs or customer issues in less sucking ways. The existing alternatives are all a big desgrace, can't speak of those commercial ones, but I guess they ain't any better than the floss ones. Approaches like trac do too many things, and hence fail at doing issue tracking right. A friend pointed me to the debian bug tracking system (http://www.debian.org/Bugs/server-refcard) and I must admit I kind of like parts of it. I think it is a strong requirement for a decent issue tracker to have a decent mail integration, people don't want to use hairy web interfaces and developers or customer relation staff doesn't wants to use them either -- RT for instance is good in the mail integration, but it does too many things and has a bad web interface that really sucks. Kind regards, Anselm
Re: [dev] GSoC 2010
I would love to see a suckless windowing system. I know that it is a point on the project page. But that is something I see as a important thing for me. But I'm also not sure if that is something which can be done during the GSoC. I think the approch of Stali is intresting but since I'm a BSD guy it doesn't intrest me so much. On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > Hi there, > > GSoC 2010 has kicked of and is looking for mentoring organisations > next week, hence it's time now to get organised. > > Who is willing to mentor this time? > > What project ideas do you have apart from http://suckless.org/project_ideas? > > Note, to be successful this time, we need to focus on a bunch of > similar projects according to Google's feedback of last year. They > basically argued that our proposals were too diverse. > > I'd say let's have a deadline until Saturday for these discussions and > in order to have enough time to create a successful application on > Monday. I also got the impression that early applications are checked > more carefully by the Google guys as late applications (afaik our > application was neither early or late last time) -- but this time I > want to press the submit button as early as possible. > > Cheers, > Anselm >
Re: [dev] GSoC 2010
On 3 March 2010 08:22, Martin Kopta wrote: > On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: >> Hi there, >> >> GSoC 2010 has kicked of and is looking for mentoring organisations >> next week, hence it's time now to get organised. >> >> Who is willing to mentor this time? >> >> What project ideas do you have apart from http://suckless.org/project_ideas? > > "Create stali stable release" Stali is definately a topic, forgot to mention this. The project idea a colleague of mine at work came up with is creating wether a completely new ld or ld wrapper at the least to collect all info when a shared lib/executable is linked and using this info to create a static library/executable instead, basically kind of a tee ld if you like, where one result invisible to the caller is a static lib instead of a dynamic one ;) This would enable building nearly everything statically without the need of extra makefiles. I don't consider this approach for the base system, since the value in it is all about decent make files, but this might be a cool project for all other stuff and would fit the GSoC scope quite well. Cheers, Anselm
Re: [dev] GSoC 2010
On Wed, Mar 03, 2010 at 08:07:19AM +, Anselm R Garbe wrote: > Hi there, > > GSoC 2010 has kicked of and is looking for mentoring organisations > next week, hence it's time now to get organised. > > Who is willing to mentor this time? > > What project ideas do you have apart from http://suckless.org/project_ideas? "Create stali stable release" ~dum8d0g
[dev] GSoC 2010
Hi there, GSoC 2010 has kicked of and is looking for mentoring organisations next week, hence it's time now to get organised. Who is willing to mentor this time? What project ideas do you have apart from http://suckless.org/project_ideas? Note, to be successful this time, we need to focus on a bunch of similar projects according to Google's feedback of last year. They basically argued that our proposals were too diverse. I'd say let's have a deadline until Saturday for these discussions and in order to have enough time to create a successful application on Monday. I also got the impression that early applications are checked more carefully by the Google guys as late applications (afaik our application was neither early or late last time) -- but this time I want to press the submit button as early as possible. Cheers, Anselm
Re: [dev] gsoc 2010
Hi Markus, 2010/1/25 markus schnalke : > Are there plans to apply for Google Summer of Code, this year? Yes. We will apply again. This time we need to focus the scope a bit more, the feedback from Google regarding last application was basically that they didn't see a strong focus into a particular direction of our project ideas, so we need to do some cleaning and achieve some hygiene ;) Cheers, Anselm
Re: [dev] gsoc 2010
I sure hope so. uriel On Mon, Jan 25, 2010 at 6:26 PM, markus schnalke wrote: > Are there plans to apply for Google Summer of Code, this year? > > I ask because I want to apply as student. > > > meillo > >
[dev] gsoc 2010
Are there plans to apply for Google Summer of Code, this year? I ask because I want to apply as student. meillo
