unserialize variants
Hi, i want to save data from an array of variants into a file. I saw that to!string format the array content in a nice way... There is a way of converting the resulted string back to an array of varianta? thanks, Bogdan
Re: Any trick for defining an operator overload in a different namespace?
On 9/1/13, Ali Çehreli wrote:
> This is the limitation of inner structs' not having an 'outer'
> reference, right?
Right, but this was just a workaround. Anyway I did just realize I can
use opDispatch for this:
-
class C
{
this()
{
this.opts["foo"] = 1;
}
private auto opDispatch(string field : "opts")()
{
return this;
}
private void opIndexAssign(T)(T value, string option)
{
assign(option, value);
}
private void assign(string option, int value)
{
}
}
-
It might seem a little funny that the only thing it does is just
returns 'this', which we already had. But I wanted to avoid writing
'this["foo"] = 1;'. Well at the end of the day this may or may not be
what I wanted, since I still want to hide opDispatch. Oh well.. :)
Re: Any trick for defining an operator overload in a different namespace?
On 08/31/2013 03:07 AM, Andrej Mitrovic wrote:
> I'm trying to achieve the syntax "opts[...] = 123", rather than using
> the more direct "this[...] = 123". I can use this code:
>
> -
> class C
> {
> this()
> {
> opts = Opts(this);
> opts["foo"] = 1;
> }
>
> struct Opts
> {
> C c;
>
> void opIndexAssign(T)(T value, string option)
> {
> c.assign(option, value);
> }
> }
>
> Opts opts;
>
> private void assign(string option, int value)
> {
> }
> }
>
> void main()
> {
> auto c = new C();
> }
> -
>
> But this explicitly stores the 'this' reference in the struct, I was
> wondering if anyone knows of a trick to avoid having to do that. As
> you can tell I just want a more convenient operator-based syntax over
> calling the 'assign' method, but I don't want the operator to live in
> the class space itself (because then I'd have to use "this[...] =
> that", which is a little quirky for my taste).
>
This is the limitation of inner structs' not having an 'outer'
reference, right?
Even if that were automatically available, it would still need a
reference similar to your explicit 'c' reference. I think... :)
Ali
Re: Problem with rdmd
On 8/30/13 6:32 AM, eles wrote: On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: I'm pretty sure it's DMD that is the problem. Yes. But that's, the least to say, limiting. This: https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L160 should be solved in other manner. Maybe creating a temporary copy. Or forcing dmd in some ways. Besides, for what reasons dmd would impose a .d extension? One possible solution would be for rdmd to create a link in its temporary directory to the original file. (The link would have a .d extension.) Andrei
Re: PyD status and tutorials
On Sat, 2013-08-31 at 12:56 +0200, Larry wrote: > Ok python3-dev was missing. Are you using Python 3.3? Are you using SCons or Tup for the build? I just tried the SCons build OOTB and it fails to build PyD with DMD :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Any trick for defining an operator overload in a different namespace?
On 08/31/13 12:07, Andrej Mitrovic wrote:
> But this explicitly stores the 'this' reference in the struct, I was
> wondering if anyone knows of a trick to avoid having to do that. As
> you can tell I just want a more convenient operator-based syntax over
> calling the 'assign' method, but I don't want the operator to live in
> the class space itself (because then I'd have to use "this[...] =
> that", which is a little quirky for my taste).
Not sure this qualifies as a "trick", but it does what you're asking
for and can be extended further.
struct A {
mixin Namespace!("x", "x_");
int x_min = 42;
int x_max(int a) { return a/2; }
int x_sum(int a, int b) { return a+b; }
@property int x_prop() { return 23; }
@property int x_prop(int a) { return a*a; }
@property int setmin(int a) { return x_min = a; }
mixin Namespace!("opts", "opts_");
void opts_opIndexAssign(T)(T value, string option) {
if (option=="min")
x_min = value;
}
}
class C {
mixin Namespace!("x", "x_");
int x_min = 42;
int x_max(int a) { return a/2; }
int x_sum(int a, int b) { return a+b; }
@property int x_prop() { return 23; }
@property int x_prop(int a) { return a*a; }
mixin Namespace!("opts", "opts_");
void opts_opIndexAssign(T)(T value, string option) {
if (option=="min")
x_min = value;
}
}
import std.stdio;
int main() {
A a;
//C a = new C; // Works too.
writeln(a.x.min);
a.x.min = 17;
writeln(a.x.min);
writeln(a.x.max(4));
writeln(a.x.sum(4, 3));
writeln(a.x.prop);
writeln(a.x.prop=42);
a.x.min = 13;
writeln(a.x.min);
a.opts["min"] = 1234;
writeln(a.x.min);
const A ca;
writeln(ca.x.min);
writeln(typeof({return ca.x.min;}()).stringof);
// ca.x.min = 13; // Disallowed.
return 0;
}
struct NS(O, string PF) {
O _realobjref;
template opDispatch(string M) {
enum _EVALSTR = "this.tupleof[0]."~PF~M;
@property auto ref opDispatch()()
if (is(typeof(function { auto _ = mixin(_EVALSTR); }))) {
return mixin(_EVALSTR);
}
@property auto ref opDispatch(A)(A a)
if (is(typeof(function { return mixin(_EVALSTR~"=a"); }))) {
return mixin(_EVALSTR~"=a");
}
auto ref opDispatch(A...)(A a)
if (is(typeof(function { return mixin(_EVALSTR~"(a)"); }))) {
return mixin(_EVALSTR~"(a)");
}
}
auto ref opIndexAssign(A...)(auto ref A a) { // XXX Won't work if there
are ref&non-ref overloads.
return mixin("this.tupleof[0]."~PF~"opIndexAssign(a)");
}
}
mixin template Namespace(string N, string P) {
mixin(q{
template }~N~q{(this THIS) }~"{"~q{
@property }~N~q{() const @trusted }~"{"~q{
static if (is(THIS==struct)) return NS!(THIS*,
}~P.stringof~q{)(cast(THIS*)&this);
else static if (is(THIS==class)) return NS!(THIS,
}~P.stringof~q{)(cast(THIS)this);
else static assert (0);
}~"}\n"~
"}"
);
}
artur
Re: Relative imports and separate compilation
On Saturday, 31 August 2013 at 09:29:16 UTC, Atila Neves wrote: How to relative imports actually work? Atila Actually for me it looks like it is a bug in automatic module name deduction. It should always use full qualified name built from directory path from closest import folder (set by -I , current working directory by default) to actual module file. So behavior observed in separate compilation case is correct one - don't know what actually happens in second case.
Re: Problem with rdmd
On Friday, 30 August 2013 at 13:32:25 UTC, eles wrote: On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: I'm pretty sure it's DMD that is the problem. Yes. But that's, the least to say, limiting. This: https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L160 should be solved in other manner. Maybe creating a temporary copy. Or forcing dmd in some ways. Besides, for what reasons dmd would impose a .d extension? This is an ancient dmd misfeature - it treats `dmd test` as `dmd test.d`, adding .d silently. No idea if someone actually wants this behavior..
Re: Problem with rdmd
On 2013-08-30 09:39, eles wrote:
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln("hello world!");
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension. This is
not a very good choice, at least when writing git helper scripts.
For example, a "$git command" command would eventually try to execute
the executable (script):
$git-command
The problem is that that line expects git-command, not git-command.d.
A workaround for this?
Why don't just compile it manually once instead of using like a script?
--
/Jacob Carlborg
Re: PyD status and tutorials
Ok python3-dev was missing. Now, it is a gdc problem: [code] def: hello wrap_struct: 'RangeWrapper' class.def: __iter__ class.def: next wrapped_struct_init, S is 'struct pyd.make_object.RangeWrapper' library_dirs: [] runtime_library_dirs: [] libraries: [] gdc -fPIC -nostartfiles -shared -fdebug -o build/lib.linux-x86_64-3.3/hello.cpython-33m.so build/temp.linux-x86_64-3.3/infra/temp.o -Wl,-soname,hello.cpython-33m.so /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a(object_.o): relocation R_X86_64_32S against `_D10TypeInfo_m6__initZ' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding symbols: Bad value collect2: error: ld returned 1 exit status error: command 'gdc' failed with exit status [/code] This line is a mess to manage.. : [code] /usr/lib/gcc/x86_64-linux-gnu/4.8/libgphobos2.a: error adding symbols: Bad value [/code] Does anyone has a clue on what has to be done ? I am on a Debian sid 64bits system.
Re: A little of coordination for Rosettacode
Jos van Uden: It's an old task (from 2007). The task description was changed after the D entries were made. Yes, there are about 63 Rosettacode tasks that I have not yet updated: accumulator_factory.d address_of_a_variable.d animation.d boolean_values.d call_a_function_in_a_shared_library.d collections.d concurrent_computing.d create_an_object_at_a_given_address.d create_a_file.d date_format.d delete_a_file.d distributed_programming.d echo_server.d environment_variables.d execute_a_system_command.d execute_snusp.d file_io.d first_class_functions_use_numbers_analogously.d flow_control_structures.d formal_power_series.d fractal_tree2.d globally_replace_text_in_several_files.d hello_world_graphical.d http.d image_noise.d include_a_file.d input_loop.d json.d literals_floating_point.d literals_string.d memory_layout_of_a_data_structure.d metered_concurrency.d multiple_distinct_objects.d mutex.d object_serialization.d opengl.d parallel_calculations1.d pointers_and_references.d pragmatic_directives.d quine.d rc_24_game.d rename_a_file.d rosetta_code_count_examples.d scripted_main.d secure_temporary_file.d shell_one_liner.d simple_windowed_application.d singleton.d sockets.d synchronous_concurrency.d system_time.d test_a_function.d user_input_text.d variables.d variable_size_get.d variable_size_set.d walk_a_directory_non_recursively.d walk_a_directory_recursively.d window_creation.d xml_dom_serialization.d xml_input.d xml_output.d xml_xpath.d Bye, bearophile
Any trick for defining an operator overload in a different namespace?
I'm trying to achieve the syntax "opts[...] = 123", rather than using
the more direct "this[...] = 123". I can use this code:
-
class C
{
this()
{
opts = Opts(this);
opts["foo"] = 1;
}
struct Opts
{
C c;
void opIndexAssign(T)(T value, string option)
{
c.assign(option, value);
}
}
Opts opts;
private void assign(string option, int value)
{
}
}
void main()
{
auto c = new C();
}
-
But this explicitly stores the 'this' reference in the struct, I was
wondering if anyone knows of a trick to avoid having to do that. As
you can tell I just want a more convenient operator-based syntax over
calling the 'assign' method, but I don't want the operator to live in
the class space itself (because then I'd have to use "this[...] =
that", which is a little quirky for my taste).
Relative imports and separate compilation
I've gone on TDPL and the language reference here but still don't
get relative imports. I've isolated it to this:
./package1/package2/foo.d:
import std.stdio;
void doFoo() {
writeln("Foo!");
}
./main.d:
import package1.package2.foo;
void main() {
doFoo();
}
This works:
dmd -c main.d
dmd -c package1/package2/foo.d
dmd main.o foo.o
This does not:
dmd main.d package1/package2/foo.d
main.d(1): Error: module foo from file package1/package2/foo.d
must be imported as module 'foo'
The only way I know of to make it work in the 2nd case is to use
a module declaration at the top of foo. Which is what I've been
doing so far.
How to relative imports actually work?
Atila
