Re: [dev] Is Mercurial (hg) suckless?
Maybe there's some kind of ballmer-peek in weed ;) 2010/6/10 pancake : > 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 wrote: > >> On 10 June 2010 18:04, Moritz Wilhelmy 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 : > Couldn't you just print your error to stdout? Yes, you could: 2>&1 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
[dev] XDG directories
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? Shall I have to indulge in a cold shower and a strong purgative afterwards? I do expect that I'll feel more than a little sick. [1] As if the XDG spec isn't already verging on batty, the XDG menu spec is certifiably insane. The Desktop people used to base their menus on simple, sensible .desktop files and a directory hierarchy, which wasn't so bad. But in their ever quicker race to the pinacle of inscrutable complexity, XDG menus are now XML based and the spec is a full 30 pages long. [2] % ls -d .* | wc -l 311 -- Kris Maglione For the time being, programming is a consumer job, assembly line coding is the norm, and what little exciting stuff is being performed is not going to make it compared to the mass-marketed crap sold by those who think they can surf on the previous half-century's worth of inventions forever. --Eric Naggum
Re: [dev] XDG directories
Hey,
On 11 June 2010 10:19, Kris Maglione 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.
cls
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 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] XDG directories
On Fri, 11 Jun 2010 10:33:51 +0100
Connor Lane Smith wrote:
> Hey,
>
> On 11 June 2010 10:19, Kris Maglione 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.
>
> cls
>
+1 for following the xdg basedir spec.
i recommend it to everyone. yes, also dmenu_cache could be moved to
${XDG_CACHE_HOME:-$HOME/.cache}/dmenu
Dieter
[dev] Re: XDG directories
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? -David [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
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 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 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 .
On 11 June 2010 11:43, 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). > > So probably I'll just have to downgrade or wait for them to fix it. > > Thanks for trying to help me anyway, Would you mind trying p9p as a test to see if the behavior is the same? Thanks, Anselm
Re: [dev] [9base] rc can't find .
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. -- Kris Maglione I just hate to be pushed around by some fucking machine. --Ken Thompson
Re: [dev] [9base] rc can't find .
On 11 June 2010 11:43, Anselm R Garbe wrote: > Would you mind trying p9p as a test to see if the behavior is the same? Ignore what I asked. I realize now that you use that crappy GNU libc... ;) --Anselm
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 "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 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, 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 03:17:18PM +0200, David Engster wrote:
David Engster writes:
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.
Like I said, the spec is verging on batty as is. I still haven't
figured that out myself, and that's after searching the
directories on my computer and seeing what other apps've done.
My best guess on the matter is that .config should be more for
user-editable things, and .local/share for — other local crap, I
guess. Current apps don't really seem to discriminate.
--
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
On Fri, 11 Jun 2010 09:29:41 -0400
Kris Maglione wrote:
> On Fri, Jun 11, 2010 at 03:17:18PM +0200, David Engster wrote:
> >David Engster writes:
> >> 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.
>
> Like I said, the spec is verging on batty as is. I still haven't
> figured that out myself, and that's after searching the
> directories on my computer and seeing what other apps've done.
> My best guess on the matter is that .config should be more for
> user-editable things, and .local/share for — other local crap, I
> guess. Current apps don't really seem to discriminate.
>
yes, both the app data and user data (can) end(s) up in $XDG_DATA_HOME
to make matters worse, many apps automatically write stuff into
$XDG_CONFIG_HOME (mostly state information like window size, last
opened files, ..), often even in the same file where the user edits his
settings. very irritating when you put that file under version control.
I've proposed them already quite a few times to at least add a
recommendation to the spec to put automatically generated data (like
application state) in a separate file, but they wouldn't listen...
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.
Dieter
[dev] [surf] download fix patch
Hello,
I made a patch for surf that makes it behave like a typical browser when
handling downloads. The patch file is attached.
--
Jason Blakeley
diff -r 2924043aead9 surf.c
--- a/surf.cThu Jun 03 16:02:09 2010 -0400
+++ b/surf.cFri Jun 11 08:38:33 2010 -0400
@@ -187,14 +187,18 @@
gboolean
decidedownload(WebKitWebView *v, WebKitWebFrame *f, WebKitNetworkRequest *r,
gchar *m, WebKitWebPolicyDecision *p, Client *c) {
- if(!webkit_web_view_can_show_mime_type(v, m)) {
- webkit_web_policy_decision_ignore(p);
- webkit_web_view_load_html_string(c->view,
- "Can't display content.",
- webkit_network_request_get_uri(r));
- return TRUE;
- }
- return FALSE;
+ (void) f;
+(void) r;
+(void) c;
+
+if (webkit_web_view_can_show_mime_type (v, m))
+{
+webkit_web_policy_decision_use (p);
+return TRUE;
+}
+
+webkit_web_policy_decision_download (p);
+return TRUE;
}
gboolean
[dev] Re: XDG directories
Dieter Plaetinck writes:
> On Fri, 11 Jun 2010 09:29:41 -0400
> Kris Maglione wrote:
>
>> On Fri, Jun 11, 2010 at 03:17:18PM +0200, David Engster wrote:
>> >David Engster writes:
>> >> 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.
>>
>> Like I said, the spec is verging on batty as is. I still haven't
>> figured that out myself, and that's after searching the
>> directories on my computer and seeing what other apps've done.
>> My best guess on the matter is that .config should be more for
>> user-editable things, and .local/share for — other local crap, I
>> guess. Current apps don't really seem to discriminate.
>>
>
> 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.
> 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
Re: [dev] Re: XDG directories
On Fri, Jun 11, 2010 at 4:09 PM, David Engster 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 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 "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 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. ((1<<31)-1) / (1<<30) ≅ 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 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 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 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. > > ((1<<31)-1) / (1<<30) ≅ 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 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. > > > > ((1<<31)-1) / (1<<30) ≅ 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 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 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 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 wrote: On 11 June 2010 17:15, pancake 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 : > 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
> How do you have it be both persistent and distributed? p2p pmarin.
Re: [dev] [OT] twitter
2010/6/11 pmarin : > 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 wrote: > 2010/6/11 pmarin : >> 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 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
Re: [dev] stderr: unnecessary?
On Sat, Jun 12, 2010 at 02:15:07AM +0100, Connor Lane Smith wrote: On 11 June 2010 21:15, Anders Andersson 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. 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. Which is made even more irrelevant by the fact that reads generally need to occur in a loop anyway to deal with incomplete and interrupted reads, hence utility functions like readn. -- Kris Maglione Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build and test, it introduces security challenges and it causes end-user and administrator frustration. --Ray Ozzie
[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 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
Re: [dev] stderr: unnecessary?
On Sat, Jun 12, 2010 at 03:03:27AM +0100, Connor Lane Smith wrote: On 12 June 2010 02:42, Kris Maglione 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. Your point was nothing. The size of size_t and ssize_t are irrelevant when you're talking about a function that isn't guaranteed or expected to return any specific amount of data on a specific call. If you want to read any amount of data, you have to call read repeatedly, with values less than SSIZE_MAX, until you've read what you want or read returns 0 bytes or error. It doesn't matter whether you want to read 5B or 5TB, whether ssize_t is a 32 bit or 128 bit value. The point is that the size of ssize_t hasn't even any practical bearing on the situation. -- Kris Maglione Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little. --Bertrand Meyer
Re: [dev] stderr: unnecessary?
On 12 June 2010 06:59, Kris Maglione wrote: > The size of size_t and ssize_t are irrelevant when > you're talking about a function that isn't guaranteed or expected to return > any specific amount of data on a specific call. Let me run that by you again: On 12 June 2010 02:42, Kris Maglione wrote: > The only limitation is that if you want > more than 2GB, you need to make multiple calls. No you don't. cls
Re: [dev] stderr: unnecessary?
On Sat, Jun 12, 2010 at 07:05:34AM +0100, Connor Lane Smith wrote: On 12 June 2010 06:59, Kris Maglione wrote: The size of size_t and ssize_t are irrelevant when you're talking about a function that isn't guaranteed or expected to return any specific amount of data on a specific call. Let me run that by you again: On 12 June 2010 02:42, Kris Maglione wrote: The only limitation is that if you want more than 2GB, you need to make multiple calls. No you don't. Are we talking about in some hypothetical world where all computers are 64 bit or all C libraries define ssize_t to be a 64 bit int, or are we talking about practical reality, where most computers are still 32 bit and nearly all C libraries define size_t as the size of a machine word (and are highly unlikely to ever do different)? -- Kris Maglione It is a miracle that curiosity survives formal education. --Albert Einstein
Re: [dev] stderr: unnecessary?
On 12 June 2010 07:16, Kris Maglione wrote: > Are we talking about in some hypothetical world where all computers are 64 > bit or all C libraries define ssize_t to be a 64 bit int, or are we talking > about practical reality, where most computers are still 32 bit and nearly > all C libraries define size_t as the size of a machine word (and are highly > unlikely to ever do different)? Well, my original message was in response to: On 11 June 2010 21:15, Anders Andersson wrote: > 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. Do you honestly believe in 10 years most computers will remain 32 bit, with a maximum of 4GB of memory? Do you not think libraries may evolve? Well, okay I guess - it must still shock you that Unix is no longer 18 bit! cls
