Re: [dev] Is Mercurial (hg) suckless?
Maybe there's some kind of ballmer-peek in weed ;) 2010/6/10 pancake panc...@youterm.com: What's wrong with the weed? :) My drugs made me write a version control system few years ago named 'pvc' you can have a look in hg.youterm.com as usual. The design is really simple and effective, but it stores full file with no patchsets. So it's a big big the repo.. I wrote it in perl and the code is pretty smart. It works as a cgi, standalone http server and cmdline tool. Sync is done via rsync. If somebody plays with it let me know. The design can be easily implemented in C. But the storage needs a rethink. On Jun 10, 2010, at 7:26 PM, Anselm R Garbe garb...@gmail.com wrote: On 10 June 2010 18:04, Moritz Wilhelmy c...@wzff.de wrote: Tom Lord did a fairly good job diagnosing some of the psychological aspects that drove the svn insanity: http://harmful.cat-v.org/software/svn/diagnosing By the way, is anyone here using tla? I used to, but being involved in some projects using git and hg (and svn for university, blergh, they always use deprecated technology for the sake of being deprecated) and never found anyone using arch in real development situations, which made me pretty much switch to git/hg since that's what many people already know and arch is rather hard to use compared to them. tla? You must be joking, latest release dates 2006, it's code is 150kSLOC (nearly 8 times Mercurial) -- most likely caused by the GNU factor (==smoking too much weed) and the interface is completely retarded (and always has been). -Anselm
Re: [dev] stderr: unnecessary?
2010/6/11 Matthew Bauer mjbaue...@gmail.com: Couldn't you just print your error to stdout? Yes, you could: 21 Now look for a real problem and stop trolling. -- - yiyus || JGL . 4l77.com
[dev] wmii FAQ
Hi, I'm updating the utterly aged wmii FAQ, and I'm hoping some of you can think of some frequently asked questions, or things that have caught you off guard, that I may miss. Thanks, -- Kris Maglione A program is portable to the extent that it can be easily moved to a new computing environment with much less effort than would be required to write it afresh. --W. Stan Brown
Re: [dev] wmii FAQ
I have these: - How to start wmii with one of the alternative wmiircs. - How to customize using the wmiirc_local variants of the wmiircs. - How to restart wmii in-place. Probably too much for the FAQ, but at least the latter two are not well documented for a beginner. On 06/11/2010 10:29 AM, Kris Maglione wrote: Hi, I'm updating the utterly aged wmii FAQ, and I'm hoping some of you can think of some frequently asked questions, or things that have caught you off guard, that I may miss. Thanks, -- Thomas Dahms
Re: [dev] wmii FAQ
On Fri, Jun 11, 2010 at 10:45:11AM +0200, Thomas Dahms wrote: I have these: - How to start wmii with one of the alternative wmiircs. - How to customize using the wmiirc_local variants of the wmiircs. - How to restart wmii in-place. Probably too much for the FAQ, but at least the latter two are not well documented for a beginner. Thanks. That's exactly the kind of thing I'm looking for. -- Kris Maglione Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. --Laurence J. Peter
Re: [dev] XDG directories
On Fri, Jun 11, 2010 at 10:33:51AM +0100, Connor Lane Smith wrote:
Hey,
On 11 June 2010 10:19, Kris Maglione maglion...@gmail.com wrote:
While on the one hand, I think that the people who wrote the XDG spec are
raving mad[1], on the other, I hate applications clogging up my home
directory with dot-files. I'm considering moving ~/.wmii to ~/.config/wmii.
I'd really prefer something of a non-dot-dir flavor, but since there's no
such standard, there's really no point. Does anyone have any arguments, or
even any half decent rants, either way?
I completely support this (dotfiles anger me). If you move
$HOME/.wmii to ${XDG_CONFIG_HOME:-$HOME/.config}/wmii, as per the
XDG spec, then anyone can set the config dir to whatever they want
(such as ~/lib) and be dotfile-free. The path looks pretty ugly with
all its environs but it's the closest we have to a standard.
As a sidenote I was wondering whether we should do this with dmenu_cache.
Except, of course, that you need to use $XDG_CACHE_HOME. And I'd
have to do the same for wimenu's program cache, which I don't
like. I may just do away with it since I finally gave up trying
to generate it portably in shell and switched to C.
--
Kris Maglione
Microsoft is not the answer. Microsoft is the question. NO is the
answer.
--Eric Naggum
Re: [dev] [9base] rc can't find .
9base is a hg build, built 3 days ago, it's the newest version. I know werc has it's own list, but I feel the problem isn't werc. Also, Kris suggested running ./werc.rc, this resulted in this: $ rc ; ./werc.rc rc: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed. 18192: signal: sys: abort SIGABRT is Signal 6, so I assume this might be the problem. However google pointed me to this thread http://sourceware.org/ml/libc-help/2010-05/msg00029.html On Fri, 2010-06-11 at 01:57 +0200, Uriel wrote: werc is not meant to be called from the command line (unless you setup some kind of fake cgi environment for it). I have no clue what the problem might be, but if it worked and now it doesn't, you must have changed something. What version of 9base are you using? Also, werc has its own mailing list: http://groups.google.com/group/werc9 uriel On Fri, Jun 11, 2010 at 12:52 AM, Jan Winkelmann k...@unstable.nl wrote: Hi, I was running a werc+lighty+9base setup happily for a couple of days. Suddenly it started throwing 500-errors and lighty log said that rc died with signal 6. I tried running the werc.rc manually, but he throws a rather strange error: $ pwd /srv/http/wiki/bin $ rc -x werc.rc . /opt/plan9/etc/rcmain werc.rc flag p finit flag i flag l . werc.rc werc.rc: rc: .: can't open: No such file or directory To me it looks like he can't find the . command as soon as he is inside the werc.rc, however he still knows it in interactive shell: ; . . rc: Usage: . [-i] file [arg ...] I already tried removing the custom werc.rc and replacing it by the original, but that didn't help either. I don't really know what to look for at this point, especially because I don't really know a lot about plan9. So, any help would be appreciated. Thanks in advance, Jan
Re: [dev] [9base] rc can't find .
9base is a hg build, built 3 days ago, it's the newest version. I know werc has it's own list, but I feel the problem isn't werc. Also, Kris Maglione suggested running ./werc.rc, this resulted in this: $ rc ; ./werc.rc rc: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed. 18192: signal: sys: abort SIGABRT is Signal 6, so I assume this might be the problem. However google pointed me to this thread: http://sourceware.org/ml/libc-help/2010-05/msg00029.html Looks like this is some weird GCC/glibc/binutils error (correct me if I'm wrong). So probably I'll just have to downgrade or wait for them to fix it. Thanks for trying to help me anyway, Jan On Fri, 2010-06-11 at 01:57 +0200, Uriel wrote: werc is not meant to be called from the command line (unless you setup some kind of fake cgi environment for it). I have no clue what the problem might be, but if it worked and now it doesn't, you must have changed something. What version of 9base are you using? Also, werc has its own mailing list: http://groups.google.com/group/werc9 uriel On Fri, Jun 11, 2010 at 12:52 AM, Jan Winkelmann k...@unstable.nl wrote: Hi, I was running a werc+lighty+9base setup happily for a couple of days. Suddenly it started throwing 500-errors and lighty log said that rc died with signal 6. I tried running the werc.rc manually, but he throws a rather strange error: $ pwd /srv/http/wiki/bin $ rc -x werc.rc . /opt/plan9/etc/rcmain werc.rc flag p finit flag i flag l . werc.rc werc.rc: rc: .: can't open: No such file or directory To me it looks like he can't find the . command as soon as he is inside the werc.rc, however he still knows it in interactive shell: ; . . rc: Usage: . [-i] file [arg ...] I already tried removing the custom werc.rc and replacing it by the original, but that didn't help either. I don't really know what to look for at this point, especially because I don't really know a lot about plan9. So, any help would be appreciated. Thanks in advance, Jan
Re: [dev] XDG directories
I'd prefer if old ~/.wmii would still serve as an override for the XDG-stuff if it exists. I don't want to move ~/.wmii around on the donzens of machines I have it installed.
Re: [dev] [OT] glibc (was: [9base] rc can't find .)
Do we have feature-complete alternatives to GNU libc? eglibc is not an option, since it's based solely on the point that Drepper is an asshole. From what I heard, uClibc is incomplete, as is klibc and dietlibc.. What else do we have? Android libc? How many programs depend on glibc?
Re: [dev] [9base] rc can't find .
On Fri, 2010-06-11 at 06:48 -0400, Kris Maglione wrote: On Fri, Jun 11, 2010 at 12:43:55PM +0200, Jan Winkelmann wrote: 9base is a hg build, built 3 days ago, it's the newest version. I know werc has it's own list, but I feel the problem isn't werc. Also, Kris Maglione suggested running ./werc.rc, this resulted in this: $ rc ; ./werc.rc rc: ../sysdeps/unix/sysv/linux/getpagesize.c:32: __getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed. 18192: signal: sys: abort SIGABRT is Signal 6, so I assume this might be the problem. However google pointed me to this thread: http://sourceware.org/ml/libc-help/2010-05/msg00029.html Looks like this is some weird GCC/glibc/binutils error (correct me if I'm wrong). You assume right. glibc 2.12 broke static linking for apps that use NSS. It broke wmiir, too. Just disable static linking and you'll be fine. Downgrading won't help, at any rate. Alright, I'll try that. And thanks to all for ignoring that embarrassing doublepost :/
Re: [dev] Is Mercurial (hg) suckless?
On 10/06/10 pancake said: The design is really simple and effective, but it stores full file with no patchsets. So it's a big big the repo.. Note, so does Git. IT just uses zlib to compress the files, and then builds on that with the ability to pack files with small diffs from one another into a single file. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpEshagkZLRs.pgp Description: PGP signature
Re: [dev] [OT] glibc (was: [9base] rc can't find .)
On Fri, Jun 11, 2010 at 01:02:02PM +0200, Moritz Wilhelmy wrote: Do we have feature-complete alternatives to GNU libc? eglibc is not an option, since it's based solely on the point that Drepper is an asshole. Drepper is an asshole. That's as good a reason as any. From what I heard, uClibc is incomplete, as is klibc and dietlibc.. What else do we have? Android libc? How many programs depend on glibc? We don't need one. 9base needs the bare minimals of system libc support. dietlibc works fine. For the rest of the system, well, there are linux systems built solely on dietlibc, but a lot of programs are indeed tightly tied to glibc. I have enough trouble building some programs on BSD. It would be nice, though, if someone would port one of the BSD libcs to linux. -- Kris Maglione A smart terminal is not a smartass terminal, but rather a terminal you can educate. -- Rob Pike
Re: [dev] XDG directories
On Fri, Jun 11, 2010 at 12:57:55PM +0200, c...@wzff.de wrote: I'd prefer if old ~/.wmii would still serve as an override for the XDG-stuff if it exists. I don't want to move ~/.wmii around on the donzens of machines I have it installed. Ok, I like that idea. -- Kris Maglione The camel has evolved to be relatively self-sufficient. On the other hand, the camel has not evolved to smell good. Neither has Perl. --Larry Wall
Re: [dev] [OT] glibc
I would love to have such lib usable for more than one kernel (w32, bsd, osx, linux..) this is theorically the big benefit of glibc.. but it is certainly something i would love to have.. NetBSD have a good Libc implementation, but it is not suckless.. I would certainly like to see something like a libc from scratch taking code from bionic and netbsd implementing the functions we need in order to run the software we use. This code coverage can be easily done with some hooks in the PLT table, so we can reduce the number of C functions needed. I would prefer to have a smart and small C library that follows POSIX, but does not implements it completely. The kernel comunication must be done separatedly, so we can use this on linux, windows or plan9. On 06/11/10 13:02, Moritz Wilhelmy wrote: Do we have feature-complete alternatives to GNU libc? eglibc is not an option, since it's based solely on the point that Drepper is an asshole. From what I heard, uClibc is incomplete, as is klibc and dietlibc.. What else do we have? Android libc? How many programs depend on glibc?
Re: [dev] [OT] glibc (was: [9base] rc can't find .)
On Fri, Jun 11, 2010 at 1:02 PM, Moritz Wilhelmy c...@wzff.de wrote: Do we have feature-complete alternatives to GNU libc? eglibc is not an option, since it's based solely on the point that Drepper is an asshole. From what I heard, uClibc is incomplete, as is klibc and dietlibc.. What else do we have? Android libc? How many programs depend on glibc? One of my favorite things about Go is that it completely bypasses the system's libc, and its core libraries and runtime all make use of the system's syscalls directly. So, the answer to your question is: start writing all your code in Go ;) uriel P.S.: Other than that, no 'libc' is 'complete' as PoSix is an insane abomination, and the more complete a libc is, the more it sucks. The android libc is quite minimal and seems quite decent, uClibc is *huge* (hundreds of thousands of lines of code), dietlibc is smaller and cleaner, but more limited, I have not checked klibc, but given that Al Viro has been involved in that project, it is probably pretty good, but I think it is quite specialized (and probably not portable to non-lunix systems).
Re: [dev] [OT] glibc
On Fri, Jun 11, 2010 at 01:51:43PM +0200, pancake wrote: I would love to have such lib usable for more than one kernel (w32, bsd, osx, linux..) this is theorically the big benefit of glibc.. but it is certainly something i would love to have.. NetBSD have a good Libc implementation, but it is not suckless.. I would certainly like to see something like a libc from scratch taking code from bionic and netbsd implementing the functions we need in order to run the software we use. This code coverage can be easily done with some hooks in the PLT table, so we can reduce the number of C functions needed. I would prefer to have a smart and small C library that follows POSIX, but does not implements it completely. The kernel comunication must be done separatedly, so we can use this on linux, windows or plan9. The kernel communication is always done separately. Even the BSD libcs factor out kernel communication, and they're meant to run on only one kernel. I don't know about NetBSD, but most of FreeBSD and OpenBSD libcs are actually very nice. Plan 9's libc is, of course, much nicer. APE has one that's mostly nice too, for that matter. P.S. Your mail formatting is very broken. Perhaps you're mixing manual and automatic line breaking. I suppose that comes with using a Mozilla email client. -- Kris Maglione Simplicity is prerequisite for reliability. --Edsger W. Dijkstra
Re: [dev] XDG directories
On Fri, Jun 11, 2010 at 12:57 PM, c...@wzff.de wrote: I'd prefer if old ~/.wmii would still serve as an override for the XDG-stuff if it exists. I don't want to move ~/.wmii around on the donzens of machines I have it installed. So additional code clutter and functionality for backwards compatibility is fine if it saves a little one-time work for you.
Re: [dev] [OT] glibc
On 06/11/10 14:05, Kris Maglione wrote: On Fri, Jun 11, 2010 at 01:51:43PM +0200, pancake wrote: I would love to have such lib usable for more than one kernel (w32, bsd, osx, linux..) this is theorically the big benefit of glibc.. but it is certainly something i would love to have.. NetBSD have a good Libc implementation, but it is not suckless.. I would certainly like to see something like a libc from scratch taking code from bionic and netbsd implementing the functions we need in order to run the software we use. This code coverage can be easily done with some hooks in the PLT table, so we can reduce the number of C functions needed. I would prefer to have a smart and small C library that follows POSIX, but does not implements it completely. The kernel comunication must be done separatedly, so we can use this on linux, windows or plan9. The kernel communication is always done separately. Even the BSD libcs factor out kernel communication, and they're meant to run on only one kernel. I don't know about NetBSD, but most of FreeBSD and OpenBSD libcs are actually very nice. Plan 9's libc is, of course, much nicer. APE has one that's mostly nice too, for that matter. P.S. Your mail formatting is very broken. Perhaps you're mixing manual and automatic line breaking. I suppose that comes with using a Mozilla email client. Yeah, it is, but sending mails without line breaking or formatting is even worst. We should move this thread to Twitter.
Re: [dev] [OT] glibc
On Fri, Jun 11, 2010 at 02:09:13PM +0200, pancake wrote: We should move this thread to Twitter. I'd sooner throw away my computer than sign up for a Twitter account. -- Kris Maglione About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. --Edsger W. Dijkstra
Re: [dev] stderr: unnecessary?
Let's get rid of exit values too! Or maybe make 0 failure and non-zero values success, so it fits in with C++ booleans! -- # Kurt H Maier
[dev] Re: XDG directories
David Engster writes: Kris Maglione writes: While on the one hand, I think that the people who wrote the XDG spec are raving mad[1], on the other, I hate applications clogging up my home directory with dot-files. I'm considering moving ~/.wmii to ~/.config/wmii. I'm trying to understand which problem exactly is solved by this. I tried to read the XDG Base Directory Specification [1] but I admit I didn't get past Basics. How is fiddling with XDG_DATA_HOME, XDG_CONFIG_HOME, XDG_DATA_DIRS, XDG_CONFIG_DIRS and XDG_CACHE_HOME better than a dotfile or dot-directory in your $HOME? OK, I've tried the next section. Can someone explain to me what XDG_DATA_HOME really is for? I know what the spec says (directory relative to which user specific data files should be stored), but then it doesn't make sense to me that its default is '~/.local/share'. Since XDG_DATA_DIRS default is '/usr/share:/usr/local/share', and data in XDG_DATA_HOME overrides those, it seems they want to mimic the share hierarchy locally? They somehow want to separate configuration from user data, but then they mix user data with application data? I don't get it. -David
Re: [dev] stderr: unnecessary?
I know you're trolling, but I already thought about why 0 indicates success. Point is, it actually makes sense because you usually have either success or failure, and in case of failure, you might need another indicator to return the nature of the failure.
Re: [dev] Re: XDG directories
On Fri, Jun 11, 2010 at 4:09 PM, David Engster d...@randomsample.de wrote: The problem is that data is even more spread than it was before, and often cannot be tracked anymore to the application which generated it. So if you're worried about applications littering your $HOME with dotfiles, you now have a littered .local/share and often do not even know if you can delete that stuff. I completely agree. It seems that they have taken what used to be a minor annoyance, and converted it into an incomprehensible kafkian nightmare that will haunt us for decades to come. Even if you really hate our lusers, implementing this 'standard' is a punishment that not even they deserve. uriel
Re: [dev] Re: XDG directories
On Fri, 11 Jun 2010 16:09:55 +0200 David Engster d...@randomsample.de wrote: Dieter Plaetinck writes: yes, both the app data and user data (can) end(s) up in $XDG_DATA_HOME I see that in my .local/share as well. It's a complete mess. So what they tried to do is to separate configuration settings from user data. But then they took a quick look at other systems (like OS X) and wanted the possibility to override/add application data (like fonts) in a local share hierarchy. I guess they also wanted you to be able to install software locally by using '--datadir=~/.local/share --sysconfdir=~/.config'. Now you got somehow everything, and every application will just do what it deems right, or only implements a subset of the spec, so that when you really want to profit from such a complicated setup, it probably won't work anyway. hmm. with application data i meant data generated by the application, which is somehow related to the user and how the user uses the application. i haven't seen data which would usually be in /usr/local (like binary executables) in ~/.local/, probably because i never installed anything in there? personally I don't mind the mixed nature of data in $XDG_DATA_HOME and as long as apps don't automatically update manually written files, it's all good for me. The problem is that data is even more spread than it was before, and often cannot be tracked anymore to the application which generated it. So if you're worried about applications littering your $HOME with dotfiles, you now have a littered .local/share and often do not even know if you can delete that stuff. -David I don't find my ~/.local/share problematic. there are only a handful subdirs which are not app-specific (mime, desktop-directories, applications, Trash, icons) and it's not a big mystery where they come from. Dieter
[dev] [OT] twitter
On 11/06/10 Kris Maglione said: I'd sooner throw away my computer than sign up for a Twitter account. I have one but I admit it was mostly out of curiousity. I feel like an idiot saying tweet. Just fix email, at least it's decentralized and universal. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein signature.asc Description: Digital signature
[dev] Re: XDG directories
Dieter Plaetinck writes: On Fri, 11 Jun 2010 16:09:55 +0200 David Engster d...@randomsample.de wrote: Dieter Plaetinck writes: yes, both the app data and user data (can) end(s) up in $XDG_DATA_HOME I see that in my .local/share as well. It's a complete mess. So what they tried to do is to separate configuration settings from user data. But then they took a quick look at other systems (like OS X) and wanted the possibility to override/add application data (like fonts) in a local share hierarchy. I guess they also wanted you to be able to install software locally by using '--datadir=~/.local/share --sysconfdir=~/.config'. Now you got somehow everything, and every application will just do what it deems right, or only implements a subset of the spec, so that when you really want to profit from such a complicated setup, it probably won't work anyway. hmm. with application data i meant data generated by the application, which is somehow related to the user and how the user uses the application. I'm not sure that's the intent. How should an application write user-specific data into /usr/share after installation? It seems they wanted the possibility to add data which can be used by applications, for example fonts, which you could just put in .local/share/fonts and which would be merged with the ones in /usr/share and /usr/local/share. Or MIME types, locales, etc. But this type of data is either written by the application at installation (and then it shouldn't be user-specific), or provided by the user. i haven't seen data which would usually be in /usr/local (like binary executables) in ~/.local/, probably because i never installed anything in there? Well yes, they explicitly denote .local/share as the default data directory. I don't know for sure what '.local' is then, maybe that's somewhere else in the spec. It's obvious that it corresponds to /usr/local, so that you can install software in your $HOME with --prefix=~/.local. The problem is that data is even more spread than it was before, and often cannot be tracked anymore to the application which generated it. So if you're worried about applications littering your $HOME with dotfiles, you now have a littered .local/share and often do not even know if you can delete that stuff. I don't find my ~/.local/share problematic. there are only a handful subdirs which are not app-specific (mime, desktop-directories, applications, Trash, icons) and it's not a big mystery where they come from. Well, I see more stuff, I think it's from XaraLX which I dared to install one time, but I'm not sure. That home directory is pretty old... and otherwise, I don't use any applications which adhere to XDG. I agree that it would be good to have all the configuration files in one place. I think BeOS had this figured out pretty well, but maybe that's just nostalgia talking. In any case, the XDG specs somehow combine local software installation with configuration settings, user and application data, and it just doesn't make much sense to me. Of course, one can simply stick to the subset of 'putting configuration in XDG_CONFIG_HOME' and just forget about the data stuff. -David
Re: [dev] [OT] twitter
I have find in twitter (identica and others..aka microblogging) a very interesting way of comunication. The protocol is simple, the messaging is simple, is fast to read (because you cannot post large stuff) and can be used in a very simple way. It's true that twitter is full of morons, but you can also find smart people and decent information if you use it correctly. The point is that it is centralized, but IMHO doing it in a decentralized (distributed crypto hashmaps) it can result on a 75% of my mail usage. Also 'private' accounts or mailings can be created on the fly, so no need for special services (like in mail) to implement this, etc.. So it's simple and powerful. I think on it as a mix between mail and chat. allowing to keep timelines to track your time, find async answers to questions, get news (rss replacement), locate people (geotwitting) and more.. And all this shit just implemented on top of a very stupid idea. The problem with mail is that it has been disgracied by spammers, comunication protocols has been filled with retarded auth methods and hacks to make it work on broken clients like outlook, etc.. and all this shit needs to be rethinked. Certainly I would prefer to use a twitter-like protocol if it was text-based (no xml), distributed. There's people using twitter to get notifications from servers and other stuff, so it is a simple idea with many uses. I like it. But it's up the everybody to think whatever they can think about it ;) --pancake On 06/11/10 17:07, Michael P. Soulier wrote: On 11/06/10 Kris Maglione said: I'd sooner throw away my computer than sign up for a Twitter account. I have one but I admit it was mostly out of curiousity. I feel like an idiot saying tweet. Just fix email, at least it's decentralized and universal. Mike
Re: [dev] stderr: unnecessary?
On 06/11/10 15:21, Moritz Wilhelmy wrote: I know you're trolling, but I already thought about why 0 indicates success. Point is, it actually makes sense because you usually have either success or failure, and in case of failure, you might need another indicator to return the nature of the failure. mixing data and errors in the same value is the source of many the programming errors and security bugs. this is why NULL exists, or -1 is used. In UNIX those 'exceptions' are used in a very smart way, but for coherence, it's good that a single app, or system follows a single rules to propagate data and errors. In GObject, exceptions, or errors are passed as reference in an argument, so the return value can be used without restrictions: for example: unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError **err); (yeah, thats a silly example, but it allows you to make reads bigger than 31 bits without having to check for the return value) In other situations it is good to handle errors in this way, but thinking on some restrictions allows you to mix error values and data in the same pipe. --pancake
Re: [dev] wmii FAQ
How to add stuff in a the bar? How to update the executable list (Modkey-p)? How to add a custom keybinding? Btw, the guide to wmii html link is dead.
Re: [dev] stderr: unnecessary?
On Fri, Jun 11, 2010 at 06:19:18PM +0200, pancake wrote: On 06/11/10 15:21, Moritz Wilhelmy wrote: unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError **err); (yeah, thats a silly example, but it allows you to make reads bigger than 31 bits without having to check for the return value) In other situations it is good to handle errors in this way, but thinking on some restrictions allows you to mix error values and data in the same pipe. ((131)-1) / (130) ≅ 2GB. I'm not seeing a major problem here. At any rate, the GError arguments is more about a disdain for errno than anything else. It's the same reason that Go, Limbo, and Common Lisp support multiple return values. -- Kris Maglione The first symptom of love in a young man is shyness; the first symptom in a woman, it's boldness. --Victor Hugo
Re: [dev] wmii FAQ
On Fri, Jun 11, 2010 at 06:25:14PM +0200, Aurélien Aptel wrote: Btw, the guide to wmii html link is dead. Hm? Where's this? -- Kris Maglione Every one is a moon, and has a dark side which he never shows to anybody. --Mark Twain
Re: [dev] wmii FAQ
On Fri, Jun 11, 2010 at 6:37 PM, Kris Maglione maglion...@gmail.com wrote: Hm? Where's this? http://wmii.suckless.org/guide All the links on that page are dead.
Re: [dev] wmii FAQ
On Fri, Jun 11, 2010 at 06:40:30PM +0200, Aurélien Aptel wrote: On Fri, Jun 11, 2010 at 6:37 PM, Kris Maglione maglion...@gmail.com wrote: Hm? Where's this? http://wmii.suckless.org/guide All the links on that page are dead. Interesting. They must have been broken during a site move. I think I'll just delete them. They're only there for archival purposes. That guide is grotesquely out of date. The link to the current guide at the top of that page works, though. -- Kris Maglione Advertising may be described as the science of arresting human intelligence long enough to get money from it.
Re: [dev] Re: XDG directories
I don't put my files in $HOME. Of course because of the dot-files annoyance. The spec somehow reminds me of the windows registry :D
Re: [dev] stderr: unnecessary?
Kris, Kris, Kris... So no one in the world ever reads files bigger than 2GB? That's a silly notion. You can't design an API based on what you think a programmer is _most likely_ to need, without consideration to other scenarios. At least not if you want it to be scalable enough to be relevant in a few years. The UNIX people understand that, and that's why UNIX-like operating systems are still in use after decades. As for the OP: People have given a few good reasons why stderr is useful, and that's why it's around. Couldn't have said it better myself. On 6/11/10, Kris Maglione maglion...@gmail.com wrote: On Fri, Jun 11, 2010 at 06:19:18PM +0200, pancake wrote: On 06/11/10 15:21, Moritz Wilhelmy wrote: unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError **err); (yeah, thats a silly example, but it allows you to make reads bigger than 31 bits without having to check for the return value) In other situations it is good to handle errors in this way, but thinking on some restrictions allows you to mix error values and data in the same pipe. ((131)-1) / (130) ≅ 2GB. I'm not seeing a major problem here. At any rate, the GError arguments is more about a disdain for errno than anything else. It's the same reason that Go, Limbo, and Common Lisp support multiple return values. -- Kris Maglione The first symptom of love in a young man is shyness; the first symptom in a woman, it's boldness. --Victor Hugo
Re: [dev] stderr: unnecessary?
Not really. Actually NOBODY reads files bigger than 2GB in a SINGLE syscall. Such operation would lock the process for a long and eat so many resorces from the app (it should malloc 2GB.. Or use mmap which is a kernel wrap for tis in a cached way over.. But certainly mmaping more than 2GB can be problematic..mostly because of architecture (x86) limits in mmu. So u will probably end up overwritting over mmaped stuff on the same virtual memory space of the app. this is why i said it was a silly example. Think before posting or blaming ;) - Original message - Kris, Kris, Kris... So no one in the world ever reads files bigger than 2GB? That's a silly notion. You can't design an API based on what you think a programmer is _most likely_ to need, without consideration to other scenarios. At least not if you want it to be scalable enough to be relevant in a few years. The UNIX people understand that, and that's why UNIX-like operating systems are still in use after decades. As for the OP: People have given a few good reasons why stderr is useful, and that's why it's around. Couldn't have said it better myself. On 6/11/10, Kris Maglione maglion...@gmail.com wrote: On Fri, Jun 11, 2010 at 06:19:18PM +0200, pancake wrote: On 06/11/10 15:21, Moritz Wilhelmy wrote: unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError **err); (yeah, thats a silly example, but it allows you to make reads bigger than 31 bits without having to check for the return value) In other situations it is good to handle errors in this way, but thinking on some restrictions allows you to mix error values and data in the same pipe. ((131)-1) / (130) ≅ 2GB. I'm not seeing a major problem here. At any rate, the GError arguments is more about a disdain for errno than anything else. It's the same reason that Go, Limbo, and Common Lisp support multiple return values. -- Kris Maglione The first symptom of love in a young man is shyness; the first symptom in a woman, it's boldness. --Victor Hugo
Re: [dev] stderr: unnecessary?
On Fri, Jun 11, 2010 at 12:59:45PM -0400, Alex Puterbaugh wrote: Kris, Kris, Kris... So no one in the world ever reads files bigger than 2GB? That's a silly notion. You can't design an API based on what you think a programmer is _most likely_ to need, without consideration to other scenarios. At least not if you want it to be scalable enough to be relevant in a few years. The UNIX people understand that, and that's why UNIX-like operating systems are still in use after decades. As for the OP: People have given a few good reasons why stderr is useful, and that's why it's around. Couldn't have said it better myself. Of course people read *files* bigger than two GB. That's why file offsets are 64bit values. The size of a single *read* is limited to 2GB. This is not a major obstacle. Even if it were commonplace for a program to read that much data into memory at once (which it is most certainly not), it would not be a major issue to split it into multiple reads. -- Kris Maglione If the programmer can simulate a construct faster than a compiler can implement the construct itself, then the compiler writer has blown it badly. --Guy Steele
Re: [dev] stderr: unnecessary?
On 11 June 2010 17:19, pancake panc...@youterm.com wrote: In GObject, exceptions, or errors are passed as reference in an argument, so the return value can be used without restrictions: for example: unsigned int read(int fd, ref char *buf, unsigned int buf_len, GError **err); (yeah, thats a silly example, but it allows you to make reads bigger than 31 bits without having to check for the return value) In other situations it is good to handle errors in this way, but thinking on some restrictions allows you to mix error values and data in the same pipe. One nice thing about Plan 9 is its exits(char *msg) function, which lets you return a string at termination, which sort of serves the same purpose, except for programs rather than functions... cls
Re: [dev] [OT] twitter
On 11 June 2010 17:15, pancake panc...@youterm.com wrote: Certainly I would prefer to use a twitter-like protocol if it was text-based (no xml), distributed. Isn't that basically IRC?
Re: [dev] stderr: unnecessary?
On Fri, Jun 11, 2010 at 7:30 PM, pancake panc...@youterm.com wrote: Not really. Actually NOBODY reads files bigger than 2GB in a SINGLE syscall. Such operation would lock the process for a long and eat so many resorces from the app (it should malloc 2GB.. Or use mmap which is a kernel wrap for tis in a cached way over.. But certainly mmaping more than 2GB can be problematic..mostly because of architecture (x86) limits in mmu. So u will probably end up overwritting over mmaped stuff on the same virtual memory space of the app. this is why i said it was a silly example. Think before posting or blaming ;) Think before posting or blaming. 2GB might be silly now, much as 2MB was silly 20 years ago. I can't see why it would be extraordinarily silly to read in/map 2GB from a file 10 years from now. It takes 10 seconds at most *today*. And to limit your application because people still use a broken processor architecture sounds a bit windows-y I think..
Re: [dev] [OT] twitter
Irc is not persistent. Channels have restricted boundaries, so you can't relate messages between more than one channel. And irc needs more attention. Chat aims to be sincrunous, microblogging not. But yeah u could implement microblogging on top of this. another good thing of microblogging is that can be implemented on top of many random services. One of the best things of twitter is probably the use they do about the data. Your impression about it can be hardly different from using one or another client ( web is the worst one ). On Jun 11, 2010, at 9:02 PM, Connor Lane Smith c...@lubutu.com wrote: On 11 June 2010 17:15, pancake panc...@youterm.com wrote: Certainly I would prefer to use a twitter-like protocol if it was text-based (no xml), distributed. Isn't that basically IRC?
Re: [dev] [OT] twitter
2010/6/11 pancake panc...@youterm.com: Irc is not persistent. Channels have restricted boundaries, so you can't How do you have it be both persistent and distributed? -- Samuel Baldwin - logik.li
Re: [dev] [OT] twitter
2010/6/11 pmarin pacog...@gmail.com: p2p How is that persistent? Everyone shunts around the logs? -- Samuel Baldwin - logik.li
Re: [dev] [OT] twitter
torrent has a hash for chunks, so you could be sure that no one touched anything and you get exact copy of what torrent maker had. On Sat, Jun 12, 2010 at 03:16, Samuel Baldwin recursive.for...@gmail.com wrote: 2010/6/11 pmarin pacog...@gmail.com: p2p How is that persistent? Everyone shunts around the logs? -- Samuel Baldwin - logik.li
Re: [dev] stderr: unnecessary?
On 11 June 2010 21:15, Anders Andersson pipat...@gmail.com wrote: Think before posting or blaming. 2GB might be silly now, much as 2MB was silly 20 years ago. I can't see why it would be extraordinarily silly to read in/map 2GB from a file 10 years from now. It takes 10 seconds at most *today*. And to limit your application because people still use a broken processor architecture sounds a bit windows-y I think.. The posix spec states that the nbyte argument is of type size_t, which could be extended to 64 bit, making 2GB well within reach. cls
[dev] World Cup
Just saying... -- Kris Maglione Beware of the real world. A speaker's appeal to it is always an invitation not to challenge his tacit assumptions. --Edsger W. Dijkstra
Re: [dev] stderr: unnecessary?
On 12 June 2010 02:42, Kris Maglione maglion...@gmail.com wrote: Which is, of course, entirely relevant. This is a non-issue. It's not a practical limitation. It's already possible to read as much of a file into memory as your memory will hold. The only limitation is that if you want more than 2GB, you need to make multiple calls. My point was that that is false. cls
Re: [dev] stderr: unnecessary?
On Sat, Jun 12, 2010 at 03:03:27AM +0100, Connor Lane Smith wrote: My point was that that is false. not only is it false, but a few months ago we were running an application (with nsz) where on one computer about 10 processes mmapped a 3.5GB file all at once, perfectly happily. (They were 64 bit computers of course.) the same thing also worked with just 2GB of physical ram (although it was a bit of a strain, in production systems we used 8GB). Mate
