xancorreu xancor...@gmail.com wrote:
Hi,
Is there any way for localizate and internationalizate messages?
I were shocked if D has something like Fantom
[http://fantom.org/doc/docLang/Localization.html]. Gettext is pretty ugly
;-)
I use small D script to internationalize Delphi projects.
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in unless the parameter is a
reference type, and
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in unless
On 02/03/12 11:41, Artur Skawina wrote:
On 02/03/12 11:21, Alex Rønne Petersen wrote:
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you,
why have protection attributes on/in interfaces and abstract
classes/methods no effect outside a module?
module types;
private interface itest
{
private static void blub();
public void blub2();
private void blub3();
}
private class test
{
protected abstract void blub4();
public
On 03-02-2012 11:41, Artur Skawina wrote:
On 02/03/12 11:21, Alex Rønne Petersen wrote:
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you,
I think that It not would show D awesomeness. The code of D thrift
serverclient looks more long and complex that Python, Perl and Ruby
examples with xml-rpc ...
Why not are something more simple ? I think that D allow to something in
the line of these xml-rpc implementations in Python or Ruby.
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing, just like immutable strings - not
using it
On 02/03/12 13:06, Jonathan M Davis wrote:
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing, just
Jonathan M Davis:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying.
Having const value types is useful because you can't change them later inside
the method. This helps you avoid
Artur Skawina:
Would marking the ctor as scope (similarly to const or pure) work for
your
case? (it is reasonable to expect that the compiler checks this by itself;
it's
per-type, so not nearly as expensive as analyzing the flow)
Maybe this is a topic worth discussing in the main D
Al 02/02/12 20:11, En/na Ali Çehreli ha escrit:
On 02/02/2012 11:00 AM, xancorreu wrote:
Al 02/02/12 19:18, En/na bearophile ha escrit:
Can I say serialize the first, second and third arguments as Class
Person?
I mean, if you define a class Person like:
class Person {
string name
uint
Al 02/02/12 20:40, En/na Jonathan M Davis ha escrit:
And whether that's the best way to handle it depends on what you're
trying to do in terms of user input and error messages. How on earth
is all of that going to be handled generically? It all depends on what
the programmer is trying to do.
Al 03/02/12 00:14, En/na bearophile ha escrit:
xancorreu:
But you only put a in in
recFactorial function argument. What this mean? **Why** this is more
efficient than mine?
It wasn't meant to improve performance. in turns a function argument to input only
(and eventually scoped too).
Al 02/02/12 20:40, En/na Stewart Gordon ha escrit:
On 02/02/2012 18:48, xancorreu wrote:
Hi,
Is there any way for localizate and internationalizate messages?
I were shocked if D has something like Fantom
[http://fantom.org/doc/docLang/Localization.html]. Gettext is pretty
ugly ;-)
Is this
Al 03/02/12 09:09, En/na Alex_Dovhal ha escrit:
xancorreuxancor...@gmail.com wrote:
Hi,
Is there any way for localizate and internationalizate messages?
I were shocked if D has something like Fantom
[http://fantom.org/doc/docLang/Localization.html]. Gettext is pretty ugly
;-)
I use small D
I deduce so that there is no official support for that. If it's, it's
a pain.
Pain? Writing such a system can be done in a couple of lines.
This I knew: Being UTF-8 and UTF-16 encodings, and because those
encodings are variable-width, char[] and wchar[] cannot be
RandomAccessRange ranges (dchar[] can be):
import std.range;
void main()
{
assert(!isRandomAccessRange!( char[]));
assert(!isRandomAccessRange!(wchar[]));
The main question is how do I either compile the library with the right
version suffix (@12)
Or get the linker to use the right version suffix (@8)
That's no version suffix. It's the number of bytes of the arguments IIRC.
Windows calling convention.
char[] and wchar[] could still define a put method, which would make them
output ranges. This is worth a bug report.
Ali Çehreli acehr...@yahoo.com wrote in message
news:jgh4a1$1286$1...@digitalmars.com...
This I knew: Being UTF-8 and UTF-16 encodings, and because those encodings
are
On Fri, Feb 03, 2012 at 06:51:56AM +0100, Philippe Sigaud wrote:
Quick question: I have a function that takes an alias parameter:
struct X { ... };
void func(alias G)(object O) {
...
X x = ...;
G(x);
...
On Fri, Feb 03, 2012 at 09:03:54PM +0100, xancorreu wrote:
Al 03/02/12 18:07, En/na Trass3r ha escrit:
I deduce so that there is no official support for that. If
it's, it's a pain.
Pain? Writing such a system can be done in a couple of lines.
How? I don't know how to do that. How to read
Al 03/02/12 19:48, En/na DNewbie ha escrit:
You can build multiple versions of you app:
http://dsource.org/projects/tutorials/wiki/LocalesExample
On Thu, Feb 2, 2012, at 07:48 PM, xancorreu wrote:
Hi,
Is there any way for localizate and internationalizate messages?
I were shocked if D has
Thanks a lot, So I just need to detect user locale using How to do
that?
You can always use the functions you would use in C.
03.02.2012 22:03, xancorreu пишет:
Al 03/02/12 18:07, En/na Trass3r ha escrit:
I deduce so that there is no official support for that. If it's,
it's a pain.
Pain? Writing such a system can be done in a couple of lines.
How? I don't know how to do that. How to read user current locale?
An
On Fri, Feb 3, 2012, at 09:48 PM, Trass3r wrote:
Thanks a lot, So I just need to detect user locale using How to do
that?
You can always use the functions you would use in C.
You can see your language id in this page:
On 02/03/2012 04:26 AM, Manfred Nowak wrote:
H. S. Teoh wrote:
I don't think that should be grounds to get rid of CTFE,
though.
In contrast to your remark, I do not see the benefits of reducing two
compiling phases to one. For me CTFE ist nothing else than running the
executables of a first
On 02/03/2012 12:22 AM, H. S. Teoh wrote:
I'm experimenting with pluggable expression parser modules, and I'm
wondering if I can use CTFE to build parser tables and such. What are
the current limitations of CTFE? Are dynamic arrays of structs
supported? Associative arrays? What about
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in
On 02/03/2012 01:06 PM, Jonathan M Davis wrote:
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing,
On Sat, Feb 04, 2012 at 01:54:55AM +0100, Timon Gehr wrote:
[...]
On another level, how far are we expecting CTFE to go eventually? In
my mind, the ideal situation would be that CTFE can replace writing
an arbitrarily complex helper program that generates D code (either
functions or data,
Timon Gehr:
However, it is
nice that the shortest storage class, 'in', implies scope.
I'd like to ask this to be valid, to shorten my code:
alias immutable imm;
Is this silly?
Bye,
bearophile
Timon Gehr wrote:
You probably haven't made extensive use of the feature.
That is correct.
- needed for a third compilation, needed for a fourth compilation,
needed for a fifth compilation ...
Provide an example please and I will change my opinion.
- better syntax, can do complex things
bearophile bearophileh...@lycos.com wrote in message
news:jgi3jn$2o6p$1...@digitalmars.com...
I'd like to ask this to be valid, to shorten my code:
alias immutable imm;
Is this silly?
Yes =)
immutable might be more characters than you want to type, but at this point
it's extremely unlikely
On Sat, Feb 04, 2012 at 02:36:10AM +, Manfred Nowak wrote:
[...]
- better syntax, can do complex things without obfuscating the
code
If the codes for more than one _needed_ phase are tangled into one
code base, I call that an obfuscated base.
[...]
One major advantage of CTFE that is
Why does the following code give a compiler error?
static int[string] table = [abc:1, def:2, ghi:3];
Error message is:
prog.d:3: Error: non-constant expression [abc:1,def:2,ghi:3]
How is a literal non-constant?
T
--
GEEK = Gatherer of Extremely Enlightening Knowledge
A limitation of the current implementation. Associative arrays are built on
the heap, and you can't currently build things on the heap and have them
exist at runtime.
The best current workaround is probably:
static int[string] table;
static this()
{
table = [abc:1, def:2, ghi:3];
}
or if
On Fri, Feb 03, 2012 at 10:18:18PM -0800, H. S. Teoh wrote:
Why does the following code give a compiler error?
static int[string] table = [abc:1, def:2, ghi:3];
Error message is:
prog.d:3: Error: non-constant expression [abc:1,def:2,ghi:3]
How is a literal non-constant?
38 matches
Mail list logo
