Re: [dev] [surf] bug in url changing
[2009-11-17 00:10] Tadeusz =?utf-8?B?U2/Fm25pZXJ6?= > > There is this small bug, not sure if it isn't some dmenu limitation. > E.g. when we are on suckless.org/manifest, and then we try to change > the uri to suckless.org, surf still puts us to manifest site. No idea > how to fix this though. I stumpled across this too. You have to hit Shift-Enter if you want to take exactly the input text. Enter takes the selected item in the list. I thought about how to change the behavior in a nice way, but none came to my mind. meillo
[dev] [surf] bug in url changing
Hello, There is this small bug, not sure if it isn't some dmenu limitation. E.g. when we are on suckless.org/manifest, and then we try to change the uri to suckless.org, surf still puts us to manifest site. No idea how to fix this though. Regards, Ted
Re: [dev] [st] problem with zsh
2009/11/16 Michał Fogelman : > > 2009/11/16 Aurélien Aptel >> >> 2009/11/16 Michał Fogelman : >> > >> > 2009/11/15 Aurélien Aptel >> >> >> >> Can I see the output of st when zsh do the visual effect you're talking >> >> about ? >> >> >> >> 2009/11/15 Michał Fogelman : >> >> > i've got problem with st and zsh - it seems to "ignore" visual effect >> >> > of >> >> > backspace adding empty spaces at the end of the line, but deleting >> >> > command >> >> > in line. After changing TERM variable to "xterm" it works fine. Any >> >> > clue >> >> > what should i change in st/zsh config to make it work properly? >> >> > >> >> > Fogel >> >> >> > >> > It gives no output to the console i run it from, i can only show how >> > does it >> > look like: >> > >> > http://img.nopaste.pl/upload/2009-11-16-012837_2880x900_scrot_4b008f2525cdb.png >> > The only so called output can be the first line (error) >> > >> >> Did you compile the terminfo entry ? ($ tic st.info) >> > i suppose not, in fact i do not even exactly know what should i add there > Just exec the following line in st source directory: tic st.info It should write the terminfo entry for st.
Re: [dev] [OT]: Go programming language
On Sun, Nov 15, 2009 at 02:54:23PM +0100, Tobias Ulmer wrote: On Sun, Nov 15, 2009 at 02:24:41PM +0100, frederic wrote: All this is more than just nit-picking. Pike claims a 10-20% loss compared to C, which would still be quite good. However, the first benchmarks tell another story at the moment: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go Be careful with this link, the results may be ok for higher level languages with built-in datatypes, but they are not for low level languages. One example i've looked at just yesterday demonstrates this nicely: http://shootout.alioth.debian.org/u64/benchmark.php?test=knucleotide&lang=all&box=1 Indeed, I found 3 more of this "anomalies". I think it has more to do with social aspects - that is the fact that there are people interested in improving the benchmark results in language X - than with high/low level; the general shape of the results shows quite the opposite of your hypothesis. I didn't dig into your example, but one possible reason C++ does better than C is that the programmer uses templates in order to perform compile-time evaluation. Take a look at the implementation before you draw any conclusion, that's all. I pointed out this benchmark precisely because I was puzzled by the low performances of Go - I don't think Pike is lies. I was wondering if the 10-20% loss applied to gccgo or 6g. When I compiled Go, I saw that these benchmarks were in the package, so I thought that they were ok for the shootout (including appropriate makefiles). But apparently the submitters have screwed it up. I'd also mention that that compares 6g, rather than GCC Go, to GCC C. 6g uses very meager optimizations, and they claim that the GCC version is faster. The standard caveat of the shootout stands: it compares implementations, not languages. Yes, I was also puzzled that they use 6g instead of gccgo, or even better that they didn't submit both. It looks like sabotage. That said, I don't see what's wrong with using this benchmark to compare the efficiency of two languages - provided that one interprets the results carefully.
Re: [dev] [OT]: Go programming language
On 16/11/2009, frederic wrote: >> Go has no inheritance, and that is >> basically the root of all OO evil (and inheritance is in mainstream >> programming considered the defining characteristic of any OO >> language.) >> > > Why do you think inheritance is the root of all evil? > > That's an important issue, given that Go offers " ways to embed types > in other types to provide something analogous—but not identical—to > subclassing" > [from "Effective Go"] Infact not really like sub-classing at all. Embeding is putting structs inside other structs and has nothing to do with the methods associated with those structs. It's almost exactly like you'd do it in C except a bit nicer. The problem with inheritance has nothing to do with the data structures and everything to do with the methods. - Jessta -- = http://jessta.id.au
Re: [dev] [OT]: Go programming language
Compared to your grand-daddy's GC? Obviously yes. But no GC language
has yet prevailed against C in benchmarks.
I don't have any statistics, but I'm not so sure of that. At least, as I
said, depending on the use case. Heavily multi-threaded and dynamic
memory intensive code takes a huge hit in locking for every malloc, and
garbage collectors have a lot to gain by managing their collection in
batches. I'm fairly certain that I can find benchmarks to the contrary.
You're right, I've read something similar: the GC-featured performed better
because the multi-thread/manual memory management was beyond human
capabilities.
In these situations, it's hard to get things right for a start, and one
may argue that the programmer has simply shot himself in the foot; heavy
use of threads and dynamic allocation doesn't look like a "suckless"
implementation.
Beyond that, there are cases like the Dis vm, which uses ref counting
with a low priority, real-time, non-locking GC to clean up cycles.
Automatic ref counting has no performance drawbacks over manual ref
counting, and the GC has virtually no impact on performance otherwise.
This must be taken with a grain of salt. A measured performance impact of
the GC of 2% in a VM-based system is one thing. Given that VMs are
generally
an order of magnitude slower than native code, the measured performance
impact of the same GC in a native code program could raise to 20%.
Interfaces and packages are free, as far as performance is concerned,
though implementations may vary.
It seems to me that there's virtual tables behind interfaces, which
means one level of indirection.
It may be cheap compared to the provided facility, but it's not free.
That's an implementation detail. In principal, they're not necessary.
And it very much depends on what you're comparing them to. It's fairly
common for C code to provide structs of function pointers, and this is
no different. Namespaces require nothing more than symbol mangling.
You're right, it's not more expensive than function pointers.
C strings are slow when you need to get their length.
It's not a win-all situation. Immutable strings may be more expensive
in some use cases.
Furthermore, they either have to convert back to zero-terminated
strings when passing them to libs, or use the trick of appending
("quand même") a zero byte, which is redundant wrt to the array lenght.
Well, you didn't exactly elaborate on "strings". C provides both mutable
and immutable strings, and I imagine that Go provides the same, too
(although it would probably call the former byte arrays). There's no
issue with passing them to libs, since Go uses its own libs. The C code
it might interface with is a different (and irrelevant, given that the
same issue presents itself in any language-to-language interface) issue.
I took a look in Go's library, and it seems to me they are using
zero-terminated
strings. I bet they use the trick I talked about.
In Go, strings are indeed read-only byte arrays, but I'm not sure one may
pass
a byte array to a function that expects a string.
I don't agree that library interface is irrelevant to the language
implementation.
The availability of library bindings and their quality is 50% of a
language.
Hard to make bindings is a serious drawback IMO. I heard garbeam complained
about that on IRC, but OTOH his binding to xlib in godwm looks like a
trivial
thing.
Closures needn't be any more expensive than any other kind of function
reference,
[...]
I'll admit, though, that without the restriction that a closure is only
valid along with the current stack frame, closed over variables are
forced into heap allocation, but again it's no loss over other methods.
Yes, I was talking about closures :-)
You're right, it's certainly no more expensive than doing the
same in C, and perhaps even less expensive.
[...]
it's very easy to decide what is heap and what is static or stack
allocated in C, and I very much doubt that to be the case in Go (yes,
I'm citing memory management issues other than GC).
I don't understand your point. The removal of these storage specifications
is precisely one of the benefits of a GC; storage specifications only exist
because different objects in programs may have different lifespans, which
is
what the GC watches and manages.
Re: [dev] [st] problem with zsh
2009/11/16 Aurélien Aptel > 2009/11/16 Michał Fogelman : > > > > 2009/11/15 Aurélien Aptel > >> > >> Can I see the output of st when zsh do the visual effect you're talking > >> about ? > >> > >> 2009/11/15 Michał Fogelman : > >> > i've got problem with st and zsh - it seems to "ignore" visual effect > of > >> > backspace adding empty spaces at the end of the line, but deleting > >> > command > >> > in line. After changing TERM variable to "xterm" it works fine. Any > clue > >> > what should i change in st/zsh config to make it work properly? > >> > > >> > Fogel > >> > > > > It gives no output to the console i run it from, i can only show how does > it > > look like: > > > http://img.nopaste.pl/upload/2009-11-16-012837_2880x900_scrot_4b008f2525cdb.png > > The only so called output can be the first line (error) > > > > Did you compile the terminfo entry ? ($ tic st.info) > > i suppose not, in fact i do not even exactly know what should i add there
