Re: [dev] Re: Simple port scanner again (was: GSoC 2010)
On 8 March 2010 00:05, anonymous wrote: > On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote: >> No, there is a fairly clear consensus about the meaning of 'process', >> there is no such consensus regarding 'threads', so being explicit >> saying 'pthreads', or 'CSP threads' (as in 'libthread'), or >> 'goroutines' is the best. > > Difference between pthreads and libthread is the way threads communicate > (locks/mutexes vs channels) but 'thread' means the same. Both in pthreads > and in libthread threads are like processes that share the same address > space (everything except registers and stack). Can we please stop this useless discussion. We all know Uriel's opinion about pthreads and many of us agree that the pthread API sucks. Most of us will agree that not using the term "thread" is good when CSP-like concurrency is implicated. This doesn't change the fact however, that the conventional meaning of "thread" is well understood and that there is no real controversy in programming (pthreads, windows threads, Java threads, etc are all the same concept) about it, apart from Uriel's favor for CSP. Thanks, Anselm
Re: [dev] GSoC 2010
On 4 March 2010 22:15, Uriel wrote: > Here is an idea the Google folks might like: Port sta.li (and p9p?) to > use Android's libc. AFAIK there is no real linux distro that uses the > Android libc, and this would be a project that might be useful for > everyone. Good idea. I add it. Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: > Good idea. I add it. > > Cheers, > Anselm > That was fast. Doesn't Android's libc not have utf8 support at the libc level? I thought I read somewhere that it didn't. Is that not needed? -- I am a man who does not exist for others. pgpEFRNjTBhPc.pgp Description: PGP signature
Re: [dev] GSoC 2010
On 8 March 2010 14:52, Jacob Todd wrote: > On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: >> Good idea. I add it. >> >> Cheers, >> Anselm >> > That was fast. Doesn't Android's libc not have utf8 support at the libc level? > I thought I read somewhere that it didn't. Is that not needed? Can't see why UTF-8 would require any specific handling at the libc level. Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 02:57:50PM +, Anselm R Garbe wrote: > [...] > Can't see why UTF-8 would require any specific handling at the libc level. > [...] Aren't strlen() and friends part of libc? -- GCS/IT/M d- s+:- a-- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- ?O M-- ?V PS++ PE- Y++ PGP+++ t+ 5 X+ R tv b+++ DI+++ D+++ G+ e h! r y+ Gregor Best pgpMwOTSUF0aM.pgp Description: PGP signature
Re: [dev] GSoC 2010
On 8 March 2010 15:39, Gregor Best wrote: > On Mon, Mar 08, 2010 at 02:57:50PM +, Anselm R Garbe wrote: >> [...] >> Can't see why UTF-8 would require any specific handling at the libc level. >> [...] > > Aren't strlen() and friends part of libc? Sure, but according to the spec: "The strlen() function shall compute the number of bytes in the string to which s points, not including the terminating null byte." strlen() should not count multi-char characters as 1 but rather return number of bytes. Do you disagree? Cheers, Anselm
Re: [dev] GSoC 2010
On Mon, Mar 08, 2010 at 03:44:28PM +, Anselm R Garbe wrote: > [...] > Sure, but according to the spec: > > "The strlen() function shall compute the number of bytes in the string > to which s points, not including the terminating null byte." > > strlen() should not count multi-char characters as 1 but rather return > number of bytes. Do you disagree? > [...] I never read the actual docs of that function (a few glances at the manpage aside), and if it definitely says "count the number of bytes", fine. But intuitively, I would've thought it gives the length of a string, as in "how many letters appear on my screen if I printf() this?". -- GCS/IT/M d- s+:- a-- C++ UL+++ US UB++ P+++ L+++ E--- W+ N+ o-- K- w--- ?O M-- ?V PS++ PE- Y++ PGP+++ t+ 5 X+ R tv b+++ DI+++ D+++ G+ e h! r y+ Gregor Best pgpegLFWIw8d4.pgp Description: PGP signature
Re: [dev] GSoC 2010
On Mon, Mar 8, 2010 at 3:57 PM, Gregor Best wrote: > I never read the actual docs of that function (a few glances at the > manpage aside), and if it definitely says "count the number of bytes", > fine. But intuitively, I would've thought it gives the length of a > string, as in "how many letters appear on my screen if I printf() > this?". Plan 9 has utflen() for that purpose. Also, how many characters appear depends on what encoding your terminal is using. strlen() is absolute, and is probably more useful in most contexts.
Re: [dev] GSoC 2010
On 8 March 2010 15:57, Gregor Best wrote: > On Mon, Mar 08, 2010 at 03:44:28PM +, Anselm R Garbe wrote: >> [...] >> Sure, but according to the spec: >> >> "The strlen() function shall compute the number of bytes in the string >> to which s points, not including the terminating null byte." >> >> strlen() should not count multi-char characters as 1 but rather return >> number of bytes. Do you disagree? >> [...] > > I never read the actual docs of that function (a few glances at the > manpage aside), and if it definitely says "count the number of bytes", > fine. But intuitively, I would've thought it gives the length of a > string, as in "how many letters appear on my screen if I printf() > this?". Well if so, then many C programs would completely fall over, because it is common to allocate buffers of the length returned by strlen(), and if that returns just number of UTF-8 glyphs we'll have buffer overflows in nearly any language except English presumably. The only part where UTF-8 might matter are sorting routines, but I wouldn't bother too much about it because in most case < or > on a per-byte basis will still lead to reasonable results, which is another reason for the beauty of UTF-8. And if you really want to use more improved sorting routines, I'd recommend Plan 9 Rune's (http://swtch.com/plan9port/man/man3/rune.html) on top of the plain handling. Cheers, Anselm
[dev] [dwm] Setting up XIM/SCIM
I've gleefuly merged from Gnome + Metacity to a plain X session with dwm on top. No complaints, and it has done everything I need it to, but I'm stumbling on getting a XIM/SCIM toolbar to work for an IME. I need to use CJK characters on a daily basis, so I find myself popping back into Gnome with dwm on top in order to do this. It does work in Gnome, but I have no idea what differs in that setup to enable it to launch. Here is the relevant part of my .xinitrc where I am starting to launch SCIM: http://pastebin.com/EWLRCCbq Based on the log, the SCIM daemon is indeed successfully loading in the background: http://pastebin.com/2nrCdf5L But the keys assigned to pulling it up don't do anything. I first thought that maybe dwm was stealing input with its own modkeys, so I mapped the SCIM launching (in scim setup) to different keys, but this didn't work. I'm wondering if this has something to do with the fact that the panel is designed for use in GTK and has been configured as part of Gnome and its keybindings. Does anyone have experience running an IME like scim-anthy (which is more than a key overlay - it needs a dictionary of words for word completion from Japanese syllabary to kanji) in dwm? I didn't find any relevant help online, perhaps because XIM/SCIM is a perennial problem regardless of environment. Thanks in advance. Benito Cachinero
Re: [dev] [dwm] Setting up XIM/SCIM
Hi Benito, I use UIM for Japanese input in dwm on a daily basis. I have shift+space mapped to toggle between Japanese and English input. It was fairly painless to setup, just had to add this to my .xinitrc: export GTK_IM_MODULE='uim' export QT_IM_MODULE='uim' uim-xim & export xmodifie...@im='uim' I can use the gtk panel too under dwm if I need to mess with settings just fine. I'm not as familiar with SCIM, but maybe this wiki can offer some help (lots of distro agnostic info can be gleaned from there): http://wiki.archlinux.org/index.php/Smart_Common_Input_Method_platform Hope that helps! がんばてね。 On Tue, Mar 9, 2010 at 8:49 AM, Benito Cachinero wrote: > I've gleefuly merged from Gnome + Metacity to a plain X session with dwm on > top. No complaints, and it has done everything I need it to, but I'm > stumbling on getting a XIM/SCIM toolbar to work for an IME. I need to use > CJK characters on a daily basis, so I find myself popping back into Gnome > with dwm on top in order to do this. It does work in Gnome, but I have no > idea what differs in that setup to enable it to launch. > > Here is the relevant part of my .xinitrc where I am starting to launch SCIM: > http://pastebin.com/EWLRCCbq > > Based on the log, the SCIM daemon is indeed successfully loading in the > background: > http://pastebin.com/2nrCdf5L > > But the keys assigned to pulling it up don't do anything. I first thought > that maybe dwm was stealing input with its own modkeys, so I mapped the SCIM > launching (in scim setup) to different keys, but this didn't work. > > I'm wondering if this has something to do with the fact that the panel is > designed for use in GTK and has been configured as part of Gnome and its > keybindings. > > Does anyone have experience running an IME like scim-anthy (which is more > than a key overlay - it needs a dictionary of words for word completion from > Japanese syllabary to kanji) in dwm? > > I didn't find any relevant help online, perhaps because XIM/SCIM is a > perennial problem regardless of environment. > > Thanks in advance. > Benito Cachinero >
Re: [dev] Re: Simple port scanner again (was: GSoC 2010)
On Mon, Mar 8, 2010 at 9:08 AM, Anselm R Garbe wrote: > On 8 March 2010 00:05, anonymous wrote: >> On Sun, Mar 07, 2010 at 11:48:38PM +0100, Uriel wrote: >>> No, there is a fairly clear consensus about the meaning of 'process', >>> there is no such consensus regarding 'threads', so being explicit >>> saying 'pthreads', or 'CSP threads' (as in 'libthread'), or >>> 'goroutines' is the best. >> >> Difference between pthreads and libthread is the way threads communicate >> (locks/mutexes vs channels) but 'thread' means the same. Both in pthreads >> and in libthread threads are like processes that share the same address >> space (everything except registers and stack). > > Can we please stop this useless discussion. We all know Uriel's > opinion about pthreads and many of us agree that the pthread API > sucks. Most of us will agree that not using the term "thread" is good > when CSP-like concurrency is implicated. This doesn't change the fact > however, that the conventional meaning of "thread" is well understood > and that there is no real controversy in programming (pthreads, > windows threads, Java threads, etc are all the same concept) about it, > apart from Uriel's favor for CSP. I will only add that even when one says "Java Threads" it is very ambiguous as there are many kinds of Java threads (and this is one of the areas where Java fails miserably at portability specially since they decided to replace 'green' threads with 'native' threads). If you are talking about 'processes that share the same address space' is much better to be explicit and say that, than to use the vague and confusing word 'thread' (unless the context is damned clear). uriel > Thanks, > Anselm > >
Re: [dev] GSoC 2010
I like this one too :) On Mon, Mar 08, 2010 at 08:25:10AM +, Anselm R Garbe wrote: > On 4 March 2010 22:15, Uriel wrote: > > Here is an idea the Google folks might like: Port sta.li (and p9p?) to > > use Android's libc. AFAIK there is no real linux distro that uses the > > Android libc, and this would be a project that might be useful for > > everyone. > > Good idea. I add it. > > Cheers, > Anselm >
Re: [dev] [dwm] Setting up XIM/SCIM
i use uim too, but on wmii. scim had have C++ ABI issue ago that was resolved by scim-bridge though. and I heard a rumor that scim devs switch to ibus. uim ships w/ sigscheme, it's fun to me. 2010/3/9 Alex Matviychuk : > Hi Benito, > > I use UIM for Japanese input in dwm on a daily basis. I have > shift+space mapped to toggle between Japanese and English input. It > was fairly painless to setup, just had to add this to my .xinitrc: > > export GTK_IM_MODULE='uim' > export QT_IM_MODULE='uim' > uim-xim & > export xmodifie...@im='uim' > > I can use the gtk panel too under dwm if I need to mess with settings just > fine. > > I'm not as familiar with SCIM, but maybe this wiki can offer some help > (lots of distro agnostic info can be gleaned from there): > http://wiki.archlinux.org/index.php/Smart_Common_Input_Method_platform > > Hope that helps! > > がんばてね。 > > On Tue, Mar 9, 2010 at 8:49 AM, Benito Cachinero > wrote: >> I've gleefuly merged from Gnome + Metacity to a plain X session with dwm on >> top. No complaints, and it has done everything I need it to, but I'm >> stumbling on getting a XIM/SCIM toolbar to work for an IME. I need to use >> CJK characters on a daily basis, so I find myself popping back into Gnome >> with dwm on top in order to do this. It does work in Gnome, but I have no >> idea what differs in that setup to enable it to launch. >> >> Here is the relevant part of my .xinitrc where I am starting to launch SCIM: >> http://pastebin.com/EWLRCCbq >> >> Based on the log, the SCIM daemon is indeed successfully loading in the >> background: >> http://pastebin.com/2nrCdf5L >> >> But the keys assigned to pulling it up don't do anything. I first thought >> that maybe dwm was stealing input with its own modkeys, so I mapped the SCIM >> launching (in scim setup) to different keys, but this didn't work. >> >> I'm wondering if this has something to do with the fact that the panel is >> designed for use in GTK and has been configured as part of Gnome and its >> keybindings. >> >> Does anyone have experience running an IME like scim-anthy (which is more >> than a key overlay - it needs a dictionary of words for word completion from >> Japanese syllabary to kanji) in dwm? >> >> I didn't find any relevant help online, perhaps because XIM/SCIM is a >> perennial problem regardless of environment. >> >> Thanks in advance. >> Benito Cachinero >> > >
[dev] Fullscreen troubles.
Hi, I use dwm for longtime now, it's the only one tiling wm which does everything by almost default. Like manage fixed sixe windows (zsnes, games,..) perfectly and has a full xinerama support whereas ratpoison does not have free layout or the possibility to manage free windows, same for i3, it does not support everything well. I was used to mplayer for watching some videos, and fullscreen mode works pretty well. But the last time I wanted to start zsnes, foobillard as fullscreen it just does not anything. Your screen is resized and you can see the bar with the window getting mangled. Try that with zsnes, foobillard and maybe wesnoth ? (not tested the last).
Re: [dev] Fullscreen troubles.
I have similar problems with dwm too. For example I cannot play game "apricots" nor "openarena" within dwm. I solve this by using second X server (env WM=pekwm startx -- :2), and use this second X server for games and java things. Not a real solution, but I don't need it so often. Martin
Re: [dev] Fullscreen troubles.
Hi, On 9 March 2010 07:16, David DEMELIER wrote: > I use dwm for longtime now, it's the only one tiling wm which does > everything by almost default. Like manage fixed sixe windows (zsnes, > games,..) perfectly and has a full xinerama support whereas ratpoison > does not have free layout or the possibility to manage free windows, > same for i3, it does not support everything well. > > I was used to mplayer for watching some videos, and fullscreen mode > works pretty well. But the last time I wanted to start zsnes, > foobillard as fullscreen it just does not anything. Your screen is > resized and you can see the bar with the window getting mangled. > > Try that with zsnes, foobillard and maybe wesnoth ? (not tested the last). Thanks for reporting this, apparently this bug is on my TODO for quite some time and I'll be able to look into it soon. Cheers, Anselm
