Re: eliminate junk from std.string?
Andrei Alexandrescu wrote: > On 1/11/11 11:21 AM, Ary Borenszweig wrote: >> Why care where they come from? Why not make them intuitive? Say, like, >> "Always camel case"? > > If there's enough support for this, I'll do it. > > Andrei +1
Re: eliminate junk from std.string?
On Tue, 11 Jan 2011 15:00:51 -0800, Andrei Alexandrescu wrote: > On 1/11/11 11:21 AM, Ary Borenszweig wrote: >> Why care where they come from? Why not make them intuitive? Say, like, >> "Always camel case"? > > If there's enough support for this, I'll do it. > > Andrei ++vote IMO, this should be done throughout Phobos before it's too late. -Lars
Re: eliminate junk from std.string?
On 2011-01-12 00:00, Andrei Alexandrescu wrote: On 1/11/11 11:21 AM, Ary Borenszweig wrote: Why care where they come from? Why not make them intuitive? Say, like, "Always camel case"? If there's enough support for this, I'll do it. Andrei vote++ -- /Jacob Carlborg
Re: About std.container.RedBlackTree
On Tue, 11 Jan 2011 15:13:13 +0100, spir wrote: > On 01/11/2011 02:22 PM, Steven Schveighoffer wrote: >>> A tree is a kind of set, so instead of "insert()" I'd like a name like >>> "add()". >>> (But maybe this is not standard in D). >> >> The function names must be consistent across containers, because the >> point is that complexity and semantic requirements are attached to the >> function name. The function names were decided long ago by Andrei, and >> I don't think insert is a bad name (I believe std::set and std::map in >> C++ STL uses insert). > > I have thought at this naming issue, precisely, for a while. "add" is > bad because of connotation with "addition". D does not use '+' as > operator for putting new elements in a container: this is a very > sensible choice imo. > "insert" is bad because of "in-between" connotation: does not fit when > putting an element at the end of a seq, even less for unordered > containers. "put" instead seems to me the right term, obvious and > general enough: one puts a new element in there. This can nicely adapt > to very diverse container types such as sequences including stacks (no > explicite index --> put at end), sets/AAs, trees,... I seem to remember this being discussed before, and 'put' being rejected for fear of confusion with the output range interface. -Lars
Re: eliminate junk from std.string?
Andrei Alexandrescu wrote: On 1/11/11 11:21 AM, Ary Borenszweig wrote: Why care where they come from? Why not make them intuitive? Say, like, "Always camel case"? If there's enough support for this, I'll do it. Andrei ++vote. Bear in mind that with D's spell checker, the error message is: test.d(8): Error: undefined identifier tolower, did you mean function toLower? Which is pretty darn good.
Re: eliminate junk from std.string?
Andrei Alexandrescu Wrote: > If there's enough support for this, I'll do it. > > Andrei for how much it can be worth, +1 Paolo
Re: [review] new string type
On 02/12/10 12:43, Ellery Newcomer wrote: On 12/01/2010 03:35 PM, Steven Schveighoffer wrote: I find that iteration over string characters using index is a very rare thing anyways, you either use foreach, which should give you dchars, or you use something like find, which should never give you an invalid index. -Steve find was the counterargument I had in mind for keeping the operator overload, as something like s[find(s,'\u2729') .. s.codeUnits] is just a bit better than s.codePointSliceAt(find(s,'\u2729'), s.codeUnits); I really don't know. I don't like either. I'd prefer (from std.algorithm) s = find(s, '\u2729'); I still don't see a need for any random-access methods, including slicing, on the code-point range. The ability to convert back and forth between the string_t and T[] would be useful to allow the user to choose between random-access code-unit range and bidirectional code-point range (or grapheme/glyph/etc). For example a T[] accessor property and an opAssign from a T[]. So if there are efficiencies to be had with random-access (and slicing), then the user could choose s = find(s.codeUnits, '\u2729'); Are there any other reasons to slice on a code-point range? Or have any capabilities beyond a bidirectional range? Unless there are compelling reasons, I'd have to say that slicing and indexing on the code-point level is not much more than a hack.
Re: [review] new string type
I like the direction you're taking but have some quibbles about details.
Specifically, I'd go for a more complete separation into random-access
code-unit ranges and bidirectional code-point ranges:
On 01/12/10 02:18, Steven Schveighoffer wrote:
// Written in the D programming language.
/**
Copyright: Copyright Andrei Alexandrescu and Steven Schveighoffer 2008-2010
License: http://www.boost.org/LICENSE_1_0.txt";>Boost License
1.0.
Authors: $(WEB erdani.org, Andrei Alexandrescu, Steven Schveighoffer)
Copyright Andrei Alexandrescu and Steven Schveighoffer 2008-2010.
Distributed under the Boost Software License, Version 1.0.
(See accompanying file LICENSE_1_0.txt or copy at
http://www.boost.org/LICENSE_1_0.txt)
*/
import std.utf;
import std.traits;
struct string_t(T) if (is(Unqual!T == char) || is(Unqual!T == wchar))
Is there a reason not to include is(Unqual!T == dchar)?
{
private T[] _data;
this(T[] data)
{
this._data = data;
}
An opAssign from a T[] could facilitate conversion back and forth
between code-point and code-unit ranges.
// note, this assumes that idx is a valid index
private size_t _charStart(size_t idx) const
{
static if(is(Unqual!T == wchar))
{
immutable c = _data.ptr[idx];
if(c >= 0xDC00 && c <= 0xDFFF)
{
// surrogate pair detected, verify we have at least 2 wchars,
// and that both wchars are properly encoded.
assert(idx > 0, "Invalid UTF character at beginning of string");
return idx-1;
}
else
return idx;
}
else
{
const p = _data.ptr + idx;
if ((p[0] & 0b1100_) != 0b1000_)
{
return idx;
}
else if (idx >= 1 && (p[-1] & 0b1100_) != 0b1000_)
{
return idx - 1;
}
else if (idx >= 2 && (p[-2] & 0b1100_) != 0b1000_)
{
return idx - 2;
}
else if (idx >= 3 && (p[-3] & 0b1100_) != 0b1000_)
{
return idx - 3;
}
else
{
assert(false, "Invalid UTF character in string");
}
}
}
void popFront()
{
auto nc = std.utf.stride(_data, 0);
assert(nc <= _data.length && nc != 0xFF, "Invalid sequence at beginning
of string");
_data = _data[nc .. $];
}
void popBack()
{
immutable n = _data.length;
assert(n, "Attempting to pop back of an empty string");
_data = _data.ptr[0.._charStart(n-1)];
}
@property dchar front() const
{
assert(_data.length, "Attempting to fetch the front of an empty string");
size_t i = 0;
return decode(_data, i);
}
@property dchar back() const
{
immutable n = _data.length;
assert(n, "Attempting to fetch the back of an empty string");
auto idx = _charStart(n-1);
return std.utf.decode(_data, idx);
}
There is the alternative of deferring decoding to the user and returning
T[]'s holding exactly 1 code-point instead of dchars. I'm not sure
which is best, but I'd be interested in seeing a case for choosing one
or the other.
@property bool empty() const
{
return !_data.length;
}
@property typeof(this) save()
{
return this;
}
// support read-only random access via code unit index.
dchar opIndex(size_t idx)
{
idx = _charStart(idx);
return std.utf.decode(_data, idx);
}
string_t opSlice()
{
return this;
}
string_t opSlice(size_t start, size_t end)
{
if(start != _data.length)
start = _charStart(start);
if(end != _data.length)
end = _charStart(end);
return string_t(_data[start..end]);
}
// note we don't call this length because length can be assumed to be the
// number of elements, which this isn't.
@property size_t codeUnits() const
{
return _data.length;
}
I don't see a need for _charStart, opIndex, opSlice and codeUnits. If
the underlying T[] can be returned by a property, then these can be done
through the code-unit array, which is random-access.
// support append and concat
// TODO: need to support appending various types of strings to eachother
// (right now only same-type strings can be appended, or raw arrays)
ref string_t opOpAssign(string op, U)(U data) if (op == "~" && is(U ==
string_t))
{
_data ~= data._data;
return this;
}
ref string_t opOpAssign(string op, U)(U data) if (op == "~" && !is(U ==
string_t) && is(typeof(_data ~= U.init)))
{
_data ~= data;
return this;
}
string_t opBinary(string op, U)(U data) if (op == "~" && is(U == string_t))
{
return string_t(_data ~ data._data);
}
string_t opBinary(string op, U)(U data) if (op == "~" && !is(U ==
string_t) && is(typeof(_data ~ U.init)))
{
return string_t(_data ~ data);
}
}
template string_t(T) if (is(Unqual!T == dchar))
{
alias T[] string_t;
}
/** begin test code **/
import std.stdio;
alias string_t!(immutable char) mystring;
alias string_t!(immutable wchar) mywstring;
alias string_t!(immutable dchar) mydstring;
void main()
{
auto str = mystring("hello");
str ~= " world";
str ~= mystring("!!!");
writeln(str._data);
}
Re: [review] new string type
s = find(s.codeUnits, '\u2729');
Sorry, I didn't mean the the codeUnits retuning a size_t. I meant an
accessor for the underlying code-unit range. Something like
@property T[] codeUnits() { return _data; }
Thin delegate adapter
Hi,
I'm wondering if a delegate adapter template like isn't handy for Phobos (it
may be especially useful for std.signal):
class Switch
{
enum State { ON, OFF }
void trigger()
{
switch (mState)
{
case State.ON: mState = State.OFF; break;
case State.OFF: mState = State.ON; break;
default: break;
}
if (watch !is null) watch(mState);
}
void delegate(State s) watch;
private State mState;
}
class ToggleButton
{
@property toggled(bool toggled)
{
writeln("ToggleButton.toggled(", toggled, ")");
}
}
void main()
{
scope s = new Switch();
scope b = new ToggleButton();
s.watch = &b.toggled; // error: invalid conversion
s.watch = adapt!("obj.toggled = cast(bool)(a)", Switch.State)(b);
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
Yes, it urges to be polished. Particularly, it doesn't support multiple
arguments. I also wanted to place the argument type tuple somwhere else
(actually wanted to hide it completely, but I think that's not possible).
Feedback?
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
Re: Thin delegate adapter
On Wed, Jan 12, 2011 at 10:41 AM, Guilherme Vieira wrote:
> Hi,
>
> I'm wondering if a delegate adapter template like isn't handy for Phobos
> (it may be especially useful for std.signal):
>
> class Switch
> {
> enum State { ON, OFF }
>
> void trigger()
> {
> switch (mState)
> {
> case State.ON: mState = State.OFF; break;
> case State.OFF: mState = State.ON; break;
> default: break;
> }
>
> if (watch !is null) watch(mState);
> }
>
> void delegate(State s) watch;
>
> private State mState;
> }
>
> class ToggleButton
> {
> @property toggled(bool toggled)
> {
> writeln("ToggleButton.toggled(", toggled, ")");
> }
> }
>
> void main()
> {
> scope s = new Switch();
> scope b = new ToggleButton();
>
> s.watch = &b.toggled; // error: invalid conversion
> s.watch = adapt!("obj.toggled = cast(bool)(a)", Switch.State)(b);
>
> s.trigger(); // prints `ToggleButton.toggled(true)`
> s.trigger(); // prints `ToggleButton.toggled(false)`
> s.trigger(); // prints `ToggleButton.toggled(true)`
> s.trigger(); // prints `ToggleButton.toggled(false)`
> }
>
>
> Yes, it urges to be polished. Particularly, it doesn't support multiple
> arguments. I also wanted to place the argument type tuple somwhere else
> (actually wanted to hide it completely, but I think that's not possible).
>
> Feedback?
>
> --
> Atenciosamente / Sincerely,
> Guilherme ("n2liquid") Vieira
>
Oops, missed the template itself:
template adapt(alias fun, Arg)
{
auto adapt(Object)(Object obj)
{
auto adaptImpl = new AdaptImpl!(fun, Object)(obj);
return &adaptImpl.opCall!(Arg);
}
}
class AdaptImpl(alias fun, Object)
{
this(Object obj) { this.obj = obj; }
auto opCall(Arg)(Arg a) { return binaryFun!(fun, "a", "obj")(a, obj); }
private Object obj;
}
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
Re: Thin delegate adapter
On 12.01.2011 15:41, Guilherme Vieira wrote:
Hi,
I'm wondering if a delegate adapter template like isn't handy for
Phobos (it may be especially useful for std.signal):
class Switch
{
enum State { ON, OFF }
void trigger()
{
switch (mState)
{
case State.ON: mState = State..OFF; break;
case State.OFF: mState = State.ON; break;
default: break;
}
if (watch !is null) watch(mState);
}
void delegate(State s) watch;
private State mState;
}
class ToggleButton
{
@property toggled(bool toggled)
{
writeln("ToggleButton.toggled(", toggled, ")");
}
}
void main()
{
scope s = new Switch();
scope b = new ToggleButton();
s.watch = &b.toggled; // error: invalid conversion
s.watch = adapt!("obj.toggled = cast(bool)(a)", Switch.State)(b);
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
Yes, it urges to be polished. Particularly, it doesn't support
multiple arguments. I also wanted to place the argument type tuple
somwhere else (actually wanted to hide it completely, but I think
that's not possible).
Feedback?
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
How is it better then built-in language feature? This works just fine:
void main()
{
//they can't be scope and compiler enforces this (+ scope is deprecated)
//actually, the orignal code is unsafe - what hapens if adapted delegate
escapes current scope?
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State a){ b.toggled = cast(bool)a; };
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
--
Dmitry Olshansky
Re: Thin delegate adapter
Ah, I totally missed that. But what if `s' went out of the scope and the
scope ended? Wouldn't the scope reference (the one containing `b') be lost
and cause memory corruption?
E.g.:
Switch make_switch()
{
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State state) { b.toggled = cast(bool)(state); };
return s;
}
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
On Wed, Jan 12, 2011 at 10:57 AM, Dmitry Olshansky wrote:
> On 12.01.2011 15:41, Guilherme Vieira wrote:
>
>> Hi,
>>
>> I'm wondering if a delegate adapter template like isn't handy for Phobos
>> (it may be especially useful for std.signal):
>>
>>class Switch
>>{
>>enum State { ON, OFF }
>>
>>void trigger()
>>{
>>switch (mState)
>>{
>>case State.ON: mState = State..OFF; break;
>>case State.OFF: mState = State.ON; break;
>>default: break;
>>}
>>
>>if (watch !is null) watch(mState);
>>}
>>
>>void delegate(State s) watch;
>>
>>private State mState;
>>}
>>
>>class ToggleButton
>>{
>>@property toggled(bool toggled)
>>{
>>writeln("ToggleButton.toggled(", toggled, ")");
>>}
>>}
>>
>>void main()
>>{
>>scope s = new Switch();
>>scope b = new ToggleButton();
>>
>>s.watch = &b.toggled; // error: invalid conversion
>>s.watch = adapt!("obj.toggled = cast(bool)(a)", Switch.State)(b);
>>
>>s.trigger(); // prints `ToggleButton.toggled(true)`
>>s.trigger(); // prints `ToggleButton.toggled(false)`
>>s.trigger(); // prints `ToggleButton.toggled(true)`
>>s.trigger(); // prints `ToggleButton.toggled(false)`
>>}
>>
>>
>> Yes, it urges to be polished. Particularly, it doesn't support multiple
>> arguments. I also wanted to place the argument type tuple somwhere else
>> (actually wanted to hide it completely, but I think that's not possible).
>>
>> Feedback?
>>
>> --
>> Atenciosamente / Sincerely,
>> Guilherme ("n2liquid") Vieira
>>
> How is it better then built-in language feature? This works just fine:
>void main()
>{
> //they can't be scope and compiler enforces this (+ scope is deprecated)
> //actually, the orignal code is unsafe - what hapens if adapted delegate
> escapes current scope?
>auto s = new Switch();
>auto b = new ToggleButton();
>
>
>s.watch = (Switch.State a){ b.toggled = cast(bool)a; };
>
>s.trigger(); // prints `ToggleButton.toggled(true)`
>s.trigger(); // prints `ToggleButton.toggled(false)`
>s.trigger(); // prints `ToggleButton.toggled(true)`
>s.trigger(); // prints `ToggleButton.toggled(false)`
>}
>
> --
> Dmitry Olshansky
>
>
Re: Thin delegate adapter
On 12.01.2011 16:07, Guilherme Vieira wrote:
Ah, I totally missed that. But what if `s' went out of the scope and
the scope ended? Wouldn't the scope reference (the one containing `b')
be lost and cause memory corruption?
E.g.:
Switch make_switch()
{
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State state) { b.toggled = cast(bool)(state); };
return s;
}
That's the main point of built-in delegates - the compiler detects them
and places the enclosing stack frame on heap, so it's all sort of cool
magic that just works :)
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
On Wed, Jan 12, 2011 at 10:57 AM, Dmitry Olshansky
mailto:dmitry.o...@gmail.com>> wrote:
On 12.01.2011 15:41, Guilherme Vieira wrote:
Hi,
I'm wondering if a delegate adapter template like isn't handy
for Phobos (it may be especially useful for std.signal):
class Switch
{
enum State { ON, OFF }
void trigger()
{
switch (mState)
{
case State.ON: mState = State..OFF; break;
case State.OFF: mState = State.ON; break;
default: break;
}
if (watch !is null) watch(mState);
}
void delegate(State s) watch;
private State mState;
}
class ToggleButton
{
@property toggled(bool toggled)
{
writeln("ToggleButton.toggled(", toggled, ")");
}
}
void main()
{
scope s = new Switch();
scope b = new ToggleButton();
s.watch = &b.toggled; // error: invalid conversion
s.watch = adapt!("obj.toggled = cast(bool)(a)",
Switch.State)(b);
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
Yes, it urges to be polished. Particularly, it doesn't support
multiple arguments. I also wanted to place the argument type
tuple somwhere else (actually wanted to hide it completely,
but I think that's not possible).
Feedback?
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
How is it better then built-in language feature? This works just fine:
void main()
{
//they can't be scope and compiler enforces this (+ scope is
deprecated)
//actually, the orignal code is unsafe - what hapens if adapted
delegate escapes current scope?
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State a){ b.toggled = cast(bool)a; };
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
--
Dmitry Olshansky
--
Dmitry Olshansky
Re: eliminate junk from std.string?
On 01/12/2011 07:22 AM, Jerry Quinn wrote: Jerry Quinn Wrote: Same comment for icmp(). Also, in the Unicode standard, case folding can depend on the specific language. That uses toUniLower. Not sure how that works. And doesn't mention details about the Unicode standard version it implements. Actually it does. *munch* *munch* my words are delicious. It would be good to have better docs on what icmp() does. Also, it might make sense to do icmp() using unicode case folding and normalization rather than simple lowercase. Thinking out loud here. You'll get this very soon. (see https://bitbucket.org/stephan/dunicode/src/bcf19471ebf9/unicodedata.d for details) Denis _ vita es estrany spir.wikidot.com
Re: eliminate junk from std.string?
On 01/12/2011 07:22 AM, Jerry Quinn wrote: Jerry Quinn Wrote: Same comment for icmp(). Also, in the Unicode standard, case folding can depend on the specific language. That uses toUniLower. Not sure how that works. And doesn't mention details about the Unicode standard version it implements. Actually it does. *munch* *munch* my words are delicious. It would be good to have better docs on what icmp() does. Also, it might make sense to do icmp() using unicode case folding and normalization rather than simple lowercase. Thinking out loud here. You'll get this very soon. (see https://bitbucket.org/stephan/dunicode/src/bcf19471ebf9/unicodedata.d for details) Denis _ vita es estrany spir.wikidot.com
Re: eliminate junk from std.string?
Walter Bright Wrote: > Ary Borenszweig wrote: > > Agreed. So what's wrong with improving things and leaving old things as > > aliases? > > Clutter. > > One of the risks with Phobos development is it becoming a river miles wide, > and > only an inch deep. In other words, endless gobs of shallow, trite functions, > with very little depth. (Aliases are as shallow as they get!) > > As a general rule, I don't want functionality in Phobos that takes more time > for > a user to find/read/understand the documentation on than to reimplement it > himself. Those things give the illusion of comprehensiveness, but are just > useless wankery. > > Do we really want a 1000 page reference manual on Phobos, but no database > interface? No network interface? No D lexer? No disassembler? No superfast > XML > parser? No best-of-breed regex implementation? No CGI support? No HTML > parsing? > No sound support? No jpg reading? > > I worry by endless bikeshedding about perfecting the spelling of some name, > we > miss the whole show. > > I'd like to see more meat. For example, Don has recently added gamma > functions > to the math library. These are hard to implement correctly, and are perfect > for > inclusion. Trivial solution: have a separate set of modules that contain the backward compatible aliases. Have those modules documented *separately* in an appendix. No Clutter and no problems. Want to use familiar functions from e.g. C++? just use: iimport compatibility.cpp.string; instead of: import string; Providing such packages would help programmers to transition from other languages to D and perhaps they should be optional addons to phoboes which are maintained separately.
Re: DVCS (was Re: Moving to D)
On 1/12/11, Jean Crystof wrote: > Claiming that low end components have shorter lifespan is ridiculous. You've never had computer equipment fail on you?
Re: eliminate junk from std.string?
On Wed, 12 Jan 2011 08:00:51 +0900, Andrei Alexandrescu wrote: On 1/11/11 11:21 AM, Ary Borenszweig wrote: Why care where they come from? Why not make them intuitive? Say, like, "Always camel case"? If there's enough support for this, I'll do it. ++vote :) Masahiro
Re: eliminate junk from std.string?
On 12.01.2011 2:00, Andrei Alexandrescu wrote: > On 1/11/11 11:21 AM, Ary Borenszweig wrote: >> Why care where they come from? Why not make them intuitive? Say, >> like, "Always >> camel case"? > > If there's enough support for this, I'll do it. > > Andrei ++vote -- Dmitry Olshansky
This awesome video nicely depicts what happends inside my head when coding in D
http://vimeo.com/18532317 (Are those laser-sword robots the guardians of CTFE? Can't quite make them out..) KR /HF
Re: DVCS (was Re: Moving to D)
Am 12.01.2011 04:02, schrieb Jean Crystof: Walter Bright Wrote: My mobo is an ASUS M2A-VM. No graphics cards, or any other cards plugged into it. It's hardly weird or wacky or old (it was new at the time I bought it to install Ubuntu). ASUS M2A-VM has 690G chipset. Wikipedia says: http://en.wikipedia.org/wiki/AMD_690_chipset_series#690G "AMD recently dropped support for Windows and Linux drivers made for Radeon X1250 graphics integrated in the 690G chipset, stating that users should use the open-source graphics drivers instead. The latest available AMD Linux driver for the 690G chipset is fglrx version 9.3, so all newer Linux distributions using this chipset are unsupported." I guess a recent version of the free drivers (as delivered with recent Ubuntu releases) still is much better than the one in Walters >2 Years old Ubuntu. Sure, game performance may not be great, but I guess normal working (even in 1920x1200) and watching youtube videos works. Fast forward to this day: http://www.phoronix.com/scan.php?page=article&item=amd_driver_q111&num=2 Benchmark page says: the only available driver for your graphics gives only about 10-20% of the real performance. Why? ATI sucks on Linux. Don't buy ATI. Buy Nvidia instead: No it doesn't. The X1250 uses the same driver as the X1950 which is much more mature and also faster than the free driver for the Radeon HD *** cards (for which a proprietary Catalyst driver is still provided). http://geizhals.at/a466974.html This is 3rd latest Nvidia GPU generation. How long support lasts? Ubuntu 10.10 still supports all Geforce 2+ which is 10 years old. I foretell Ubuntu 19.04 is last one supporting this. Use Nvidia and your problems are gone. I agree that a recent nvidia card may improve things even further. Cheers, - Daniel
Re: either
I don't really know what I'm up to, but I ended up making this thing: https://gist.github.com/776604 I can't figure out how to make two nice templates called anySatisfy and allSatisfy and make them call find and compare the lengths. So I just ripped these two from std.typetuple and made them operate on variadic arguments. Well, at least it's somewhat amusing to look at..
Re: eliminate junk from std.string?
spir wrote: On 01/11/2011 09:11 PM, Ary Borenszweig wrote: "Welcome to D. Do you program in C, Javascript, Python or Ruby? Cool! Then you will feel at home." That phrase currently ends like this: "You don't? Oh, sorry, you will have to learn that some names are all lowercase, some not." But it could end like this: "You don't? Don't worry. D has the convention of writing all function names with X convention, but we keep some aliases for things that we want to keep backwards compatibility for." Yop. And anyway those legacy names are not all the same in C, Javascript, Python, Ruby, etc.. One has to be chosen or created for D, why not follow a guideline for the standard D name? (I really cannot (under)stand this general politic of sticking at wrong design choices from the past for generations and generations --even in brand new languages. How do improvements happen in other fields than programming? One day or the other, one needs to throw away old (mental) garbage.) Denis Yes, I recently did the same with many of the math functions. tgamma --> gamma, lgamma -> logGamma. It's pretty funny to try to find out why there is a 't' in front of 'tgamma' in C. http://pubs.opengroup.org/onlinepubs/009695399/functions/tgamma.html "RATIONALE This function is named tgamma() in order to avoid conflicts with the historical gamma() and lgamma() functions." And why the t? 't' stands for 'true'. Because the original gamma() had a bug. Bravo.
Re: DVCS (was Re: Moving to D)
"Andrej Mitrovic" wrote in message news:mailman.571.1294806486.4748.digitalmar...@puremagic.com... > Notice the smiley face -> :D > > Yeah I didn't check the price, it's only 30$. But there's no telling > if that would work either. Also, dirt cheap video cards are almost > certainly going to cause problems. Even if the drivers worked > perfectly, a year down the road things will start breaking down. Cheap > hardware is cheap for a reason. Rediculous. All of the video cards I'm using are ultra-cheap ones that are about 10 years old and they all work fine.
Re: DVCS (was Re: Moving to D)
"Nick Sabalausky" wrote in message news:igkv8v$2g...@digitalmars.com... > "Andrej Mitrovic" wrote in message > news:mailman.571.1294806486.4748.digitalmar...@puremagic.com... >> Notice the smiley face -> :D >> >> Yeah I didn't check the price, it's only 30$. But there's no telling >> if that would work either. Also, dirt cheap video cards are almost >> certainly going to cause problems. Even if the drivers worked >> perfectly, a year down the road things will start breaking down. Cheap >> hardware is cheap for a reason. > > Rediculous. All of the video cards I'm using are ultra-cheap ones that are > about 10 years old and they all work fine. > They're cheap because they have lower clock speeds, fewer features, and less memory.
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
Michel Fortin wrote: On 2011-01-11 20:28:26 -0500, Steven Wawryk said: Why not choose which of these abstractions is most appropriate in a given situation instead of trying to shoe-horn both concepts into a single abstraction, and provide for easy conversion between them? When character representation is the primary requirement then make it a bidirectional range of code points. When storage representation and random access is required then make it a random access range of code units. I think you're right. The need for a new concept isn't that great, and it gets complicated really fast. I think the only problem that we really have, is that "char[]", "dchar[]" implies that code points is always the appropriate level of abstraction.
Re: DVCS (was Re: Moving to D)
On 1/12/11, Nick Sabalausky wrote: > Rediculous. All of the video cards I'm using are ultra-cheap ones that are > about 10 years old and they all work fine. > I'm saying that if you buy a cheap video card *today* you might not get what you expect. And I'm not talking out of my ass, I've had plenty of experience with faulty hardware and device drivers. The 'quality' depends more on who makes the product than what price tag it has, but you have to look these things up and not buy things on first sight because they're cheap.
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
On 1/12/11 11:28 AM, Don wrote:
Michel Fortin wrote:
On 2011-01-11 20:28:26 -0500, Steven Wawryk said:
Why not choose which of these abstractions is most appropriate in a
given situation instead of trying to shoe-horn both concepts into a
single abstraction, and provide for easy conversion between them?
When character representation is the primary requirement then make it
a bidirectional range of code points. When storage representation and
random access is required then make it a random access range of code
units.
I think you're right. The need for a new concept isn't that great, and
it gets complicated really fast.
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I hope to assuage part of that issue with representation(). Again, it's
not documented yet (mainly because of the famous ddoc bug that prevents
auto functions from carrying documentation). Here it is:
/**
* Returns the representation type of a string, which is the same type
* as the string except the character type is replaced by $(D ubyte),
* $(D ushort), or $(D uint) depending on the character width.
*
* Example:
string s = "hello";
static assert(is(typeof(representation(s)) == immutable(ubyte)[]));
*/
/*private*/ auto representation(Char)(Char[] s) if (isSomeChar!Char)
{
// Get representation type
static if (Char.sizeof == 1) enum t = "ubyte";
else static if (Char.sizeof == 2) enum t = "ushort";
else static if (Char.sizeof == 4) enum t = "uint";
else static assert(false); // can't happen due to isSomeChar!Char
// Get representation qualifier
static if (is(Char == immutable)) enum q = "immutable";
else static if (is(Char == const)) enum q = "const";
else static if (is(Char == shared)) enum q = "shared";
else enum q = "";
// Result type is qualifier(RepType)[]
static if (q.length)
return mixin("cast(" ~ q ~ "(" ~ t ~ ")[]) s");
else
return mixin("cast(" ~ t ~ "[]) s");
}
Andrei
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
On 01/12/2011 08:28 PM, Don wrote: I think the only problem that we really have, is that "char[]", "dchar[]" implies that code points is always the appropriate level of abstraction. I'd like to know when it happens that codepoint is the appropriate level of abstraction. * If pieces of text are not manipulated, meaning just used in the application, or just transferred via the application as is (from file / input / literal to any kind of output), then any kind of encoding just works. One can even concatenate, provided all pieces use the same encoding. --> _lower_ level than codepoint is OK. * But any of manipulation (indexing, slicing, compare, search, count, replace, not to speak about regex/parsing) requires operating at the _higher_ level of characters (in the common sense). Just like with historic character sets in which codes used to represent characters (not lower-level thingies as in UCS). Else, one reads, compares, changes meaningless bits of text. As I see it now, we need 2 types: * One plain string similar to good old ones (bytestring would do the job, since most unicode is utf8 encoded) for the first kind of use above. With optional validity check when it's supposed to be unicode text. * One hiher-level type abstracting from codepoint (not code unit) issues, restoring the necessary properties: (1) each character is one element in the sequence (2) each character is always represented the same way. Denis _ vita es estrany spir.wikidot.com
Re: DVCS (was Re: Moving to D)
Wed, 12 Jan 2011 19:11:22 +0100, Daniel Gibson wrote: > Am 12.01.2011 04:02, schrieb Jean Crystof: >> Walter Bright Wrote: >> >>> My mobo is an ASUS M2A-VM. No graphics cards, or any other cards >>> plugged into it. It's hardly weird or wacky or old (it was new at the >>> time I bought it to install Ubuntu). >> >> ASUS M2A-VM has 690G chipset. Wikipedia says: >> http://en.wikipedia.org/wiki/AMD_690_chipset_series#690G >> >> "AMD recently dropped support for Windows and Linux drivers made for >> Radeon X1250 graphics integrated in the 690G chipset, stating that >> users should use the open-source graphics drivers instead. The latest >> available AMD Linux driver for the 690G chipset is fglrx version 9.3, >> so all newer Linux distributions using this chipset are unsupported." >> >> > I guess a recent version of the free drivers (as delivered with recent > Ubuntu releases) still is much better than the one in Walters >2 Years > old Ubuntu. Most likely. After all they're fixing more bugs than creating new ones. :-) My other guess is, while the open source drivers are far from perfect for hardcore gaming, the basic functionality like setting up a video mode is getting better. Remember the days you needed to type in all internal and external clock frequencies and packed pixel bit counts in xorg.conf ?! > Sure, game performance may not be great, but I guess normal working > (even in 1920x1200) and watching youtube videos works. Embedded videos on web pages used to require huge amounts of CPU power when you were upscaling them in the fullscreen mode. The reason is that Flash only recently starting supporting hardware accelerated videos, on ***32-bit*** systems equipped with a ***NVIDIA*** card. The same VDPAU libraries are used by the native video players. I tried to accelerate video playback with my Radeon HD 5770, but it failed badly. Believe it or not, my 3 Ghz 4-core Core i7 system with 24 GB of RAM and the fast Radeon HD 5770 was too slow to play 1080p videos @ 1920x1080 using the open source drivers. Without hardware acceleration you need a modern high-end dual-core system or faster to run the video assuming the drivers aren't broken. If you only want to watch the youtube videos in windowed mode, you still need a 2+ Ghz single-core. But.. Youtube has switched to HTML5 videos recently. This should take the requirements down a notch. Still I wouldn't trust integrated graphics that much. They've always been crap.
Re: DVCS (was Re: Moving to D)
Wed, 12 Jan 2011 14:22:59 -0500, Nick Sabalausky wrote: > "Andrej Mitrovic" wrote in message > news:mailman.571.1294806486.4748.digitalmar...@puremagic.com... >> Notice the smiley face -> :D >> >> Yeah I didn't check the price, it's only 30$. But there's no telling if >> that would work either. Also, dirt cheap video cards are almost >> certainly going to cause problems. Even if the drivers worked >> perfectly, a year down the road things will start breaking down. Cheap >> hardware is cheap for a reason. > > Rediculous. All of the video cards I'm using are ultra-cheap ones that > are about 10 years old and they all work fine. There's no reason why they would break. Few months ago I was reconfiguring an old server at work which still used two 16-bit 10 megabit ISA network cards. I fetched a kernel upgrade (2.6.27.something). It's a modern kernel which is still maintained and had up-to-date drivers for the 20 year old device! Those devices have no moving parts and are stored inside EMP & UPS protected strong server cases. How the heck could they break? Same thing, can't imagine how a video card could break. The old ones didn't even have massive cooling solutions, the chips didn't even need a heatsink. The only problem is driver support, but on Linux it mainly gets better over the years.
Re: DVCS (was Re: Moving to D)
On Wednesday 12 January 2011 13:11:13 retard wrote: > Wed, 12 Jan 2011 14:22:59 -0500, Nick Sabalausky wrote: > > "Andrej Mitrovic" wrote in message > > news:mailman.571.1294806486.4748.digitalmar...@puremagic.com... > > > >> Notice the smiley face -> :D > >> > >> Yeah I didn't check the price, it's only 30$. But there's no telling if > >> that would work either. Also, dirt cheap video cards are almost > >> certainly going to cause problems. Even if the drivers worked > >> perfectly, a year down the road things will start breaking down. Cheap > >> hardware is cheap for a reason. > > > > Rediculous. All of the video cards I'm using are ultra-cheap ones that > > are about 10 years old and they all work fine. > > There's no reason why they would break. Few months ago I was > reconfiguring an old server at work which still used two 16-bit 10 > megabit ISA network cards. I fetched a kernel upgrade (2.6.27.something). > It's a modern kernel which is still maintained and had up-to-date drivers > for the 20 year old device! Those devices have no moving parts and are > stored inside EMP & UPS protected strong server cases. How the heck could > they break? > > Same thing, can't imagine how a video card could break. The old ones > didn't even have massive cooling solutions, the chips didn't even need a > heatsink. The only problem is driver support, but on Linux it mainly gets > better over the years. It depends on a number of factors, including the quality of the card and the conditions that it's being used in. I've had video cards die before. I _think_ that it was due to overheating, but I really don't know. It doesn't really matter. The older the part, the more likely it is to break. The cheaper the part, the more likely it is to break. Sure, the lack of moving parts makes it less likely for a video card to die, but it definitely happens. Computer parts don't last forever, and the lower their quality, the less likely it is that they'll last. By no means does that mean that a cheap video card isn't necessarily going to last for years and function just fine, but it is a risk that a cheap card will be too cheap to last. - Jonathan M Davis
Re: DVCS (was Re: Moving to D)
On 01/12/2011 04:11 PM, retard wrote: Same thing, can't imagine how a video card could break. I recently had a cheap video card break. It at least had the decency to break within the warranty period, but I was too lazy to return it :P I decided that the integrated graphics, while slow, were "good enough" for what I was using the machine for.
Re: DVCS (was Re: Moving to D)
Wow. The thread that went "Moving to D"->"Problems with DMD"->"DVCS"->"WHICH DVCS"->"Linux Problems"->"Driver Problems/Manufacturer preferences"->"Cheap VS. Expensive". It's a personally observed record of OT threads, I think. Anyways, I've refrained from throwing fuel on the thread as long as I can, I'll bite: > It depends on a number of factors, including the quality of the card and the > conditions that it's being used in. I've had video cards die before. I _think_ > that it was due to overheating, but I really don't know. It doesn't really > matter. The older the part, the more likely it is to break. The cheaper the > part, the more likely it is to break. Sure, the lack of moving parts makes it > less likely for a video card to die, but it definitely happens. Computer parts > don't last forever, and the lower their quality, the less likely it is that > they'll last. By no means does that mean that a cheap video card isn't > necessarily going to last for years and function just fine, but it is a risk > that > a cheap card will be too cheap to last. "Cheap" in the sense of "less money" isn't the problem. Actually, HW that cost more is often high-end HW which creates more heat, which _might_ actually shorten the lifetime. On the other hand, low-end HW is often less heat-producing, which _might_ make it last longer. The real difference lies in what level of HW are sold at which clock-levels, I.E. manufacturing control procedures. So an expensive low-end for a hundred bucks might easily outlast a cheap high-end alternative for 4 times the money. Buy quality, not expensive. There is a difference.
Re: DVCS (was Re: Moving to D)
Wed, 12 Jan 2011 13:22:28 -0800, Jonathan M Davis wrote: > On Wednesday 12 January 2011 13:11:13 retard wrote: >> Same thing, can't imagine how a video card could break. The old ones >> didn't even have massive cooling solutions, the chips didn't even need >> a heatsink. The only problem is driver support, but on Linux it mainly >> gets better over the years. > > It depends on a number of factors, including the quality of the card and > the conditions that it's being used in. Of course. > I've had video cards die before. > I _think_ that it was due to overheating, but I really don't know. It > doesn't really matter. Modern GPU and CPU parts are of course getting hotter and hotter. They're getting so hot it's a miracle the components such as capacitors nearby the cores can handle it. You need better cooling which means even more breaking parts. > The older the part, the more likely it is to break. Not true. http://en.wikipedia.org/wiki/Bathtub_curve > The cheaper the part, the more likely it is to break. That might be true if the part is a power supply or a monitor. However, the latest and greatest video cards and CPUs are sold at an extremely high price mainly for hardcore gamers (and 3d modelers -- quadro & firegl). This is sometimes purely an intellectual property issue, nothing to do with physical parts. For example I've earned several hundred euros by installing soft-mods, that is upgraded firmware / drivers. Ever heard of Radeon 9500 -> 9700, 9800SE -> 9800, and lately 6950 -> 6970 mods? I've also modded one PC NVIDIA card to work on Macs (sold at a higher price) and done one Geforce -> Quadro mod. You don't touch the parts at all, just flash the ROM. It would be a miracle if that improved the physical quality of the parts. It does raise the price, though. Another observation: the target audience of the low end NVIDIA cards are usually HTPC and office users. These computers have small cases and require low profile cards. The cards have actually *better* multimedia features (purevideo) than the high end cards for gamers. These cards are built by the same companies as the larger versions (Asus, MSI, Gigabyte, and so on). Could it just be that by giving the buyer less physical parts and less intellectual property in the form of GPU firmware, they can sell at a lower price. There are also these cards with the letters "OC" in their name. The manufacturer has deliberately overclocked the cards beyond their specs. That's actually hurting the reliability but the price is even bigger.
Re: DVCS (was Re: Moving to D)
Wed, 12 Jan 2011 22:46:46 +0100, Ulrik Mikaelsson wrote: > Wow. The thread that went "Moving to D"->"Problems with > DMD"->"DVCS"->"WHICH DVCS"->"Linux Problems"->"Driver > Problems/Manufacturer preferences"->"Cheap VS. Expensive". It's a > personally observed record of OT threads, I think. > > Anyways, I've refrained from throwing fuel on the thread as long as I > can, I'll bite: > >> It depends on a number of factors, including the quality of the card >> and the conditions that it's being used in. I've had video cards die >> before. I _think_ that it was due to overheating, but I really don't >> know. It doesn't really matter. The older the part, the more likely it >> is to break. The cheaper the part, the more likely it is to break. >> Sure, the lack of moving parts makes it less likely for a video card to >> die, but it definitely happens. Computer parts don't last forever, and >> the lower their quality, the less likely it is that they'll last. By no >> means does that mean that a cheap video card isn't necessarily going to >> last for years and function just fine, but it is a risk that a cheap >> card will be too cheap to last. > "Cheap" in the sense of "less money" isn't the problem. Actually, HW > that cost more is often high-end HW which creates more heat, which > _might_ actually shorten the lifetime. On the other hand, low-end HW is > often less heat-producing, which _might_ make it last longer. The real > difference lies in what level of HW are sold at which clock-levels, I.E. > manufacturing control procedures. So an expensive low-end for a hundred > bucks might easily outlast a cheap high-end alternative for 4 times the > money. > > Buy quality, not expensive. There is a difference. Nicely written, I fully agree with you.
Re: DVCS (was Re: Moving to D)
On 1/12/11 2:30 PM, retard wrote: Wed, 12 Jan 2011 22:46:46 +0100, Ulrik Mikaelsson wrote: Wow. The thread that went "Moving to D"->"Problems with DMD"->"DVCS"->"WHICH DVCS"->"Linux Problems"->"Driver Problems/Manufacturer preferences"->"Cheap VS. Expensive". It's a personally observed record of OT threads, I think. Anyways, I've refrained from throwing fuel on the thread as long as I can, I'll bite: It depends on a number of factors, including the quality of the card and the conditions that it's being used in. I've had video cards die before. I _think_ that it was due to overheating, but I really don't know. It doesn't really matter. The older the part, the more likely it is to break. The cheaper the part, the more likely it is to break. Sure, the lack of moving parts makes it less likely for a video card to die, but it definitely happens. Computer parts don't last forever, and the lower their quality, the less likely it is that they'll last. By no means does that mean that a cheap video card isn't necessarily going to last for years and function just fine, but it is a risk that a cheap card will be too cheap to last. "Cheap" in the sense of "less money" isn't the problem. Actually, HW that cost more is often high-end HW which creates more heat, which _might_ actually shorten the lifetime. On the other hand, low-end HW is often less heat-producing, which _might_ make it last longer. The real difference lies in what level of HW are sold at which clock-levels, I.E. manufacturing control procedures. So an expensive low-end for a hundred bucks might easily outlast a cheap high-end alternative for 4 times the money. Buy quality, not expensive. There is a difference. Nicely written, I fully agree with you. Same here. It's not well understood that heating/cooling cycles with the corresponding expansion and contraction cycles are the main reason for which electronics fail. At an extreme, the green-minded person who turns all CFLs and all computers off at all opportunities ends up producing more expense and more waste than the lazier person who leaves stuff on for longer periods of time. Andrei
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
spir wrote: > On 01/12/2011 08:28 PM, Don wrote: >> I think the only problem that we really have, is that "char[]", >> "dchar[]" implies that code points is always the appropriate level of >> abstraction. > > I'd like to know when it happens that codepoint is the appropriate level > of abstraction. When on a document that describes code points... :) > * If pieces of text are not manipulated, meaning just used in the > application, or just transferred via the application as is (from file / > input / literal to any kind of output), then any kind of encoding just > works. One can even concatenate, provided all pieces use the same > encoding. --> _lower_ level than codepoint is OK. > * But any of manipulation (indexing, slicing, compare, Compare according to which alphabet's ordering? Surely not Unicode's... I may be alone in this, but ordering is tied to an alphabet (or writing system), not locale.) I try to solve that issue with my trileri library: http://code.google.com/p/trileri/source/browse/#svn%2Ftrunk%2Ftr Warning: the code is in Turkish and is not aware of the concept of collation at all; it has its own simplistic view of text, where every character is an entity that can be lower/upper cased to a single character. > search, count, > replace, not to speak about regex/parsing) requires operating at the > _higher_ level of characters (in the common sense). I don't know this about Unicode: should e and ´ (acute accent) be always collated? If so, wouldn't it be impossible to put those two in that order say, in a text book? (Perhaps Unicode defines a way to stop collation.) > Just like with > historic character sets in which codes used to represent characters (not > lower-level thingies as in UCS). Else, one reads, compares, changes > meaningless bits of text. > > As I see it now, we need 2 types: I think we need more than 2 types... > * One plain string similar to good old ones (bytestring would do the > job, since most unicode is utf8 encoded) for the first kind of use > above. With optional validity check when it's supposed to be unicode text. Agreed. D gives us three UTF encondings, but I am not sure that there is only one abstraction above that. > * One hiher-level type abstracting from codepoint (not code unit) > issues, restoring the necessary properties: (1) each character is one > element in the sequence (2) each character is always represented the > same way. I think VLERange should solve only the variable-length-encoding issue. It should not get into higher abstractions. Ali
Re: Thin delegate adapter
No sh*t..?! @__@ That's so cool! But is it smart enough to know the stack
frame doesn't need to go to heap in this case? (since it returns a heap
object referecing another heap object, i.e. can it untangle `b' from the
stack?)
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
On Wed, Jan 12, 2011 at 11:49 AM, Dmitry Olshansky wrote:
> On 12.01.2011 16:07, Guilherme Vieira wrote:
>
>> Ah, I totally missed that. But what if `s' went out of the scope and the
>> scope ended? Wouldn't the scope reference (the one containing `b') be lost
>> and cause memory corruption?
>>
>> E.g.:
>>
>>Switch make_switch()
>>{
>>auto s = new Switch();
>>auto b = new ToggleButton();
>>
>>s.watch = (Switch.State state) { b.toggled = cast(bool)(state); };
>>
>>
>>return s;
>>}
>>
>>
>> That's the main point of built-in delegates - the compiler detects them
> and places the enclosing stack frame on heap, so it's all sort of cool magic
> that just works :)
>
>> --
>> Atenciosamente / Sincerely,
>> Guilherme ("n2liquid") Vieira
>>
>> On Wed, Jan 12, 2011 at 10:57 AM, Dmitry Olshansky
>> > dmitry.o...@gmail.com>> wrote:
>>
>>On 12.01.2011 15:41, Guilherme Vieira wrote:
>>
>>Hi,
>>
>>I'm wondering if a delegate adapter template like isn't handy
>>for Phobos (it may be especially useful for std.signal):
>>
>> class Switch
>> {
>> enum State { ON, OFF }
>>
>> void trigger()
>> {
>> switch (mState)
>> {
>> case State.ON: mState = State..OFF; break;
>> case State.OFF: mState = State.ON; break;
>> default: break;
>> }
>>
>> if (watch !is null) watch(mState);
>> }
>>
>> void delegate(State s) watch;
>>
>> private State mState;
>> }
>>
>> class ToggleButton
>> {
>> @property toggled(bool toggled)
>> {
>> writeln("ToggleButton.toggled(", toggled, ")");
>> }
>> }
>>
>> void main()
>> {
>> scope s = new Switch();
>> scope b = new ToggleButton();
>>
>> s.watch = &b.toggled; // error: invalid conversion
>> s.watch = adapt!("obj.toggled = cast(bool)(a)",
>>Switch.State)(b);
>>
>> s.trigger(); // prints `ToggleButton.toggled(true)`
>> s.trigger(); // prints `ToggleButton.toggled(false)`
>> s.trigger(); // prints `ToggleButton.toggled(true)`
>> s.trigger(); // prints `ToggleButton.toggled(false)`
>> }
>>
>>
>>Yes, it urges to be polished. Particularly, it doesn't support
>>multiple arguments. I also wanted to place the argument type
>>tuple somwhere else (actually wanted to hide it completely,
>>but I think that's not possible).
>>
>>Feedback?
>>
>>-- Atenciosamente / Sincerely,
>>Guilherme ("n2liquid") Vieira
>>
>>How is it better then built-in language feature? This works just fine:
>> void main()
>> {
>>//they can't be scope and compiler enforces this (+ scope is
>>deprecated)
>>//actually, the orignal code is unsafe - what hapens if adapted
>>delegate escapes current scope?
>> auto s = new Switch();
>> auto b = new ToggleButton();
>>
>>
>> s.watch = (Switch.State a){ b.toggled = cast(bool)a; };
>>
>> s.trigger(); // prints `ToggleButton.toggled(true)`
>> s.trigger(); // prints `ToggleButton.toggled(false)`
>> s.trigger(); // prints `ToggleButton.toggled(true)`
>> s.trigger(); // prints `ToggleButton.toggled(false)`
>> }
>>
>>-- Dmitry Olshansky
>>
>>
>
> --
> Dmitry Olshansky
>
>
Re: DVCS (was Re: Moving to D)
retard wrote: There's no reason why they would break. Few months ago I was reconfiguring an old server at work which still used two 16-bit 10 megabit ISA network cards. I fetched a kernel upgrade (2.6.27.something). It's a modern kernel which is still maintained and had up-to-date drivers for the 20 year old device! Those devices have no moving parts and are stored inside EMP & UPS protected strong server cases. How the heck could they break? Same thing, can't imagine how a video card could break. The old ones didn't even have massive cooling solutions, the chips didn't even need a heatsink. The only problem is driver support, but on Linux it mainly gets better over the years. I paid my way through college hand-making electronics boards for professors and engineers. All semiconductors have a lifetime that is measured by the area under the curve of their temperature over time. The doping in the semiconductor gradually diffuses through the semiconductor, the rate of diffusion increases as the temperature rises. Once the differently doped parts "collide" the semiconductor fails.
Re: DVCS (was Re: Moving to D)
On 01/10/11 21:14, retard wrote: > Sun, 09 Jan 2011 06:00:21 -0600, Christopher Nicholson-Sauls wrote: > >> On 01/08/11 20:18, Walter Bright wrote: >>> Vladimir Panteleev wrote: On Sun, 09 Jan 2011 00:34:19 +0200, Walter Bright wrote: > Yeah, I could spend an afternoon doing that. sudo apt-get build-dep meld wget http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.0.tar.bz2 tar jxf meld-1.5.0.tar.bz2 cd meld-1.5.0 make sudo make install You're welcome ;) >>> Thanks, I'll give it a try! >> >> I say you should consider moving away from *Ubuntu and to something more >> "developer-friendly" such as Gentoo, where the command to install meld >> is just: >> emerge meld >> >> ...done. And yes, that's an install from source. I just did it myself, >> and it took right at one minute. > > Gentoo really needs a high-end computer to run fast. Tell that to the twelve year old machine here in our living room, running latest Gentoo profile with KDE 4.x all with no problem. FWIW, the same meld > takes 7 seconds to install on my ubuntu. That includes fetching the > package from the internet (1-2 seconds). Probably even faster on Arch. Sure, and my wife's Kubuntu machine would probably do the same -- since *Ubuntu installs pre-compiled binaries (some packages are available as source, as I recall, but very few). I acknowledge that you disclaimed your statement with a "FWIW" but I have to say it isn't much of a comparison: pre-compiled binaries versus locally built from source. I only really brought up how long it took because of Walter's "spend an afternoon" comment anyhow, so really we both "win" in this case. ;) And yes, I'm an unashamed Gentoo advocate to begin with. Been using it as both server and personal desktop OS for years now. (Of course half or more of what I love about it is portage, which can be used with other distros -- and BSD! -- although I know nothing about how one sets that up.) -- Chris N-S
Re: DVCS (was Re: Moving to D)
On 01/11/11 15:36, Walter Bright wrote: > Andrej Mitrovic wrote: >> That's my biggest problem with Linux. Having technical problems is not >> the issue, finding the right solution in the sea of forum posts is the >> problem. > > The worst ones begin with "you might try this..." or "I think this might > work, but YMMV..." How do these wind up being the top ranked results by > google? Who embeds links to that stuff? Nobody. The first "secret" of Linux tech-help is that most real help is dished out via IRC channels. One just has to visit their distro of choice's website and there will inevitably be a listing for an IRC channel or two -- often with one specifically for new users. It may sound like a lot of trouble, but getting help from the source and live is worlds above scanning forum posts hoping the people posting know more than you do. And thanks to the global scale of most FOSS communities, there's always someone around -- and it didn't cost you a dime. That said, a little more integrity in the forums that do exist would be nice. LinuxQuestions.org seems to be one of the better ones, from what I've seen of it. -- Chris N-S
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
On 2011-01-12 14:57:58 -0500, spir said:
On 01/12/2011 08:28 PM, Don wrote:
I think the only problem that we really have, is that "char[]",
"dchar[]" implies that code points is always the appropriate level of
abstraction.
I'd like to know when it happens that codepoint is the appropriate
level of abstraction.
I agree with you. I don't see many use for code points.
One of these uses is writing a parser for a format defined in term of
code points (XML for instance). But beyond that, I don't see one.
* If pieces of text are not manipulated, meaning just used in the
application, or just transferred via the application as is (from file /
input / literal to any kind of output), then any kind of encoding just
works. One can even concatenate, provided all pieces use the same
encoding. --> _lower_ level than codepoint is OK.
* But any of manipulation (indexing, slicing, compare, search, count,
replace, not to speak about regex/parsing) requires operating at the
_higher_ level of characters (in the common sense). Just like with
historic character sets in which codes used to represent characters
(not lower-level thingies as in UCS). Else, one reads, compares,
changes meaningless bits of text.
Very true. In the same way that code points can span on multiple code
units, user-perceived characters (graphemes) can span on multiple code
points.
A funny exercise to make a fool of an algorithm working only with code
points would be to replace the word "fortune" in a text containing the
word "fortuné". If the last "é" is expressed as two code points, as "e"
followed by a combining acute accent (this: é), replacing occurrences
of "fortune" by "expose" would also replace "fortuné" with "exposé"
because the combining acute accent remains as the code point following
the word. Quite amusing, but it doesn't really make sense that it works
like that.
In the case of "é", we're lucky enough to also have a pre-combined
character to encode it as a single code point, so encountering "é"
written as two code points is quite rare. But not all combinations of
marks and characters can be represented as a single code point. The
correct thing to do is to treat "é" (single code point) and "é" ("e" +
combining acute accent) as equivalent.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: VLERange: a range in between BidirectionalRange and RandomAccessRange
On 2011-01-12 19:45:36 -0500, Michel Fortin said:
A funny exercise to make a fool of an algorithm working only with code
points would be to replace the word "fortune" in a text containing the
word "fortuné". If the last "é" is expressed as two code points, as "e"
followed by a combining acute accent (this: é), replacing occurrences
of "fortune" by "expose" would also replace "fortuné" with "exposé"
because the combining acute accent remains as the code point following
the word. Quite amusing, but it doesn't really make sense that it works
like that.
In the case of "é", we're lucky enough to also have a pre-combined
character to encode it as a single code point, so encountering "é"
written as two code points is quite rare. But not all combinations of
marks and characters can be represented as a single code point. The
correct thing to do is to treat "é" (single code point) and "é" ("e" +
combining acute accent) as equivalent.
Crap, I meant to send this as UTF-8 with combining characters in it,
but my news client converted everything to ISO-8859-1.
I'm not sure it'll work, but here's my second attempt at posting real
combining marks:
Single code point: é
e with combining mark: é
t with combining mark: t̂
t with two combining marks: t̂̃
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
What are we missing, in terms of tool support?
Currently I'm using Vim (after the last 10 attempts I've finally made the switch and now I'm sticking with it), and it does provide quite a bit of functionality right in the get-go. I have just written a guide 2 days ago on how to set up Cscope to use it with Vim and D (it's a bit Windows specific but easily adaptable to Linux): http://prowiki.org/wiki4d/wiki.cgi?ReferenceForTools/Cscope I'm pretty sure Cscope can be used with Emacs and other editors as well. (Etags, right? :p) You can also download a prebuilt binary for Ctags on Windows: http://prowiki.org/wiki4d/wiki.cgi?ReferenceForTools/ExuberantCtags They both work pretty good for D, even though they were never designed for it. Ctags does need a tiny patch though. So for jumping around source code we're all set (in Vim land at least). I don't want to make this Vim-specific, so I'm wondering what features are we missing in today's D editors/IDE's that other languages already have in their editors/IDE's? As for any Vimmers: has anyone set up a debugging system that they use with D? I was just about to go look into that, but if someone has already looked into it any info you could give me would be great!
Re: What are we missing, in terms of tool support?
Oh, I forgot to mentioned I made a ctags guide as well (for Vim): http://prowiki.org/wiki4d/wiki.cgi?EditorSupport/VimEditor So give it a spin if you're in Vim.
Re: DVCS (was Re: Moving to D)
Andrej Mitrovic wrote: On 1/12/11, Jean Crystof wrote: Claiming that low end components have shorter lifespan is ridiculous. You've never had computer equipment fail on you? I've had a lot of computer equipment. Failures I've had, ranked in order of most failures to least: keyboards power supplies hard drives fans monitors I've never had a CPU, memory, or mobo failure. Which is really kind of amazing. I did have a 3DFX board once, which failed after a couple years. Never bought another graphics card. The keyboards fail so often I keep a couple spares around. I buy cheap, bottom of the line equipment. I don't overclock them and I make sure there's plenty of airflow around the boxes.
Re: DVCS (was Re: Moving to D)
On Thu, 13 Jan 2011 05:43:27 +0200, Walter Bright wrote: The keyboards fail so often I keep a couple spares around. Let me guess, all cheap rubber-domes? Maybe you should have a look at some professional keyboards. Mechanical keyboards are quite durable, and feel much nicer to type on. -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: DVCS (was Re: Moving to D)
Walter Bright Wrote: > The keyboards fail so often I keep a couple spares around. > > I buy cheap, bottom of the line equipment. I don't overclock them and I make > sure there's plenty of airflow around the boxes. Wow, I have never had a keyboard fail. I'm stilling using my first keyboard from 1998. Hell, I haven't even rubbed off any of the letters. I guess the only components I've had fail on me has been hard drive and CD/DVD drive. Monitor was about to go.
Re: DVCS (was Re: Moving to D)
Vladimir Panteleev wrote: On Thu, 13 Jan 2011 05:43:27 +0200, Walter Bright wrote: The keyboards fail so often I keep a couple spares around. Let me guess, all cheap rubber-domes? Maybe you should have a look at some professional keyboards. Mechanical keyboards are quite durable, and feel much nicer to type on. Yup, the $9.99 ones. They also get things spilled on them, why ruin an expensive one?
Re: Thin delegate adapter
On 13.01.2011 2:16, Guilherme Vieira wrote:
No sh*t..?! @__@ That's so cool! But is it smart enough to know the
stack frame doesn't need to go to heap in this case? (since it returns
a heap object referecing another heap object, i.e. can it untangle `b'
from the stack?)
Ehm, it can optimize certain cases but for the moment it doesn't.
Still, it needs to store b somewhere, right? and delegate is 2 pointers
in fact, so b should go on heap anyway. So it narrows down to if it can
save only parts of the stack frame ...
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
On Wed, Jan 12, 2011 at 11:49 AM, Dmitry Olshansky
mailto:dmitry.o...@gmail.com>> wrote:
On 12.01.2011 16:07, Guilherme Vieira wrote:
Ah, I totally missed that. But what if `s' went out of the
scope and the scope ended? Wouldn't the scope reference (the
one containing `b') be lost and cause memory corruption?
E.g.:
Switch make_switch()
{
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State state) { b.toggled =
cast(bool)(state); };
return s;
}
That's the main point of built-in delegates - the compiler detects
them and places the enclosing stack frame on heap, so it's all
sort of cool magic that just works :)
--
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
On Wed, Jan 12, 2011 at 10:57 AM, Dmitry Olshansky
mailto:dmitry.o...@gmail.com>
>>
wrote:
On 12.01.2011 15:41, Guilherme Vieira wrote:
Hi,
I'm wondering if a delegate adapter template like isn't
handy
for Phobos (it may be especially useful for std.signal):
class Switch
{
enum State { ON, OFF }
void trigger()
{
switch (mState)
{
case State.ON: mState = State..OFF; break;
case State.OFF: mState = State.ON; break;
default: break;
}
if (watch !is null) watch(mState);
}
void delegate(State s) watch;
private State mState;
}
class ToggleButton
{
@property toggled(bool toggled)
{
writeln("ToggleButton.toggled(", toggled, ")");
}
}
void main()
{
scope s = new Switch();
scope b = new ToggleButton();
s.watch = &b.toggled; // error: invalid conversion
s.watch = adapt!("obj.toggled = cast(bool)(a)",
Switch.State)(b);
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
Yes, it urges to be polished. Particularly, it doesn't
support
multiple arguments. I also wanted to place the argument
type
tuple somwhere else (actually wanted to hide it completely,
but I think that's not possible).
Feedback?
-- Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira
How is it better then built-in language feature? This works
just fine:
void main()
{
//they can't be scope and compiler enforces this (+ scope is
deprecated)
//actually, the orignal code is unsafe - what hapens if adapted
delegate escapes current scope?
auto s = new Switch();
auto b = new ToggleButton();
s.watch = (Switch.State a){ b.toggled = cast(bool)a; };
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
s.trigger(); // prints `ToggleButton.toggled(true)`
s.trigger(); // prints `ToggleButton.toggled(false)`
}
-- Dmitry Olshansky
--
Dmitry Olshansky
--
Dmitry Olshansky
Re: What are we missing, in terms of tool support?
> I don't want to make this Vim-specific, so I'm wondering what features are we > missing in today's D editors/IDE's that other languages already have in their > editors/IDE's? IDE with incremental compiler. Non-windows IDEs. Ddoc integration. Refactoring utilities. Template- and conditional-compilation-aware editing. Inline error and warning messages. ...
