toStringz in std.file
Hi! Why in std.file toStringz used without store a pointer in function body to prevent GC collection? https://github.com/D-Programming-Language/phobos/blob/master/std/file.d Best Regards, Ilya
Re: toStringz in std.file
On Wednesday, 29 January 2014 at 08:27:14 UTC, Ilya Yaroshenko wrote: Hi! Why in std.file toStringz used without store a pointer in function body to prevent GC collection? https://github.com/D-Programming-Language/phobos/blob/master/std/file.d Best Regards, Ilya It is assumed that the pointer is not moved to the C heap where the GC can't see it. The stack is the stack; it doesn't matter if it's a D or C function, the GC sees it anyway.
Re: A possible enhancement related to is()
On 1/29/14, Jakob Ovrum jakobov...@gmail.com wrote: On a related note, I would like the body of a template to be able to access aliases introduced in IsExpression's in the template's constraints. Me too, but I can't remember if this was filed in bugzilla.
Re: HTTPS, SSL, TLS client on D
On Wednesday, 29 January 2014 at 07:20:52 UTC, Uranuz wrote: I continue to practice with web applications on D and I have some questions about secure protocols of data transmissions. I don't have any experience with SSL/TLS so I need an advice how to get started. Is there any ready solution how to create client based on secured socket (for example HTTPS client). I would consider some existing C library with good interface. I was looking at libcurl but it looks confusing and couldn't make something that works. P.S. I would be glad for any useful advice If your goal is to write web applications in D, probably you should use a web-framework (like vibe.d) or a (fast/s)cgi interface over a well known server. In our company we use D for web applications using fastcgi with nginx and lightppd. It works fine, also with https that is managed by nginx itself.
Re: HTTPS, SSL, TLS client on D
In this case I want client programme on D that will communicate with some server over secure HTTP. I want to be able to update DNS records via it's web API using web interface of my web application written on D. I could do it using some cross-site request on JavaScript XmlHTTPRequest, but I want to have some console utility too. HTTPS client written on D would be suitable but only obvious idea is to use libcurl. But it has slightly complicated C interface. Is there something simplier exists that you can advise?
Sorting structs?
Hello everybody. I'm trying to learn D by solving simple exercises. The current exercise: read names and grades of students, then print the names of students in descending order of their grades. In C++, I would define a Student struct, overload the operators: bool operator(const Student, const Student) std::istream operator(std::istream, Student) Then I'd store the Students in let's say a std::vector, sort it in reverse, then print it accordingly. But I don't know how to do things in D. I'm reading Cehreli's book, so far I've only finished its first trinity (just before struct). I would appreciate it if you explained your approach and gave source code illustrating it. Thanks!
Re: Sorting structs?
It's also worth noting that you can avoid passing structs into predicate function by value, and instead pass them by reference: sort!((ref const a, ref const b) = a.grade b.grade)(students); This is useful for heavy structs to save on performance. E.g. in this case, Student.sizeof is 24 bytes on 64 bit machine. Passing by reference will only need to copy 16 bytes (i.e. size of two pointers), whereas passing by value will incur copying 48 bytes (two structs).
Re: Set global immutables from main/getopt?
On Wednesday, 29 January 2014 at 00:28:29 UTC, Meta wrote: You can also use the Github Gist feature for displaying code, can't you? But you'd need a github account for that, won't you? :)
Re: Sorting structs?
Also sorry for double posting but I'm confused how the sorting works when we only specify to be sorted by grade. I think in C++, disregarding other data members can lead to loss of data in things such as std::set.
Re: Sorting structs?
Thanks for the help so far. My current code is here: http://dpaste.dzfl.pl/b9acff399649 Are there problems with my code, or do you have suggestions to improve it?
Re: Set global immutables from main/getopt?
One can always turn global into pointer to immutable - it will preserve most benefits but can be always replaced with differently initialized one.
Re: Sorting structs?
On Wednesday, 29 January 2014 at 10:30:06 UTC, Boomerang wrote:
I'll paste here with comments:
import std.algorithm;
import std.stdio;
import std.array;
void main()
{
struct Student
{
string name;
float grade;
}
Student[] studs;
writeln(Enter student data. Reading stops when student name
is empty.);
while (true)
{
// Calls to readf() may throw an exception
// if user inputs invalid data.
// You may want to consider accounting
// for that.
typeof(Student.name) name;
write(Student name: );
readf(%s\n, name);
// Don't burden users with typing STOP :)
if (name.empty)
break;
typeof(Student.grade) grade;
write(Student grade: );
import std.exception;
import std.conv : ConvException;
// EXAMPLE: catch all ConvExceptions
// to persuade user to input a number :)
while(collectException!ConvException(readf(%s\n,
grade)))
{
// Conversion failed but there's still data in
// stdin. We get rid of it:
readln;
write(Please enter NUMERIC student grade: );
}
// Create Student only when necessary
// (a good compiler will optimize that
// to avoid copying):
studs ~= Student(name, grade);
}
// Use anonymous function with explicit
// parameter storage class specifier;
// Also Use UFCS
studs.sort!((ref const a, ref const b) = a.grade b.grade);
// You can omit type name in foreach;
// also it's worth using ref const to avoid
// unnecessary copies
foreach (ref const s; studs)
writeln(s.name);
// Or avoid foreach altogether:
studs.map!((ref const s) = writeln(s.name));
}
Also sorry for double posting but I'm confused how the sorting
works when we only specify to be sorted by grade. I think in
C++, disregarding other data members can lead to loss of data
in things such as std::set.
Yes and no. In fact, std::set is by default instantiated with an
std::less predicate. But std::set is intended to store unique
elements. So if you try to insert an element that std::set
already considers to exist (it uses the predicate to determine
that), it doesn't insert it.
But you must understand that despite being generic, algorithms
and containers still serve particular purposes. You wouldn't
store students in a set unless you had some way to uniquely
identify them :)
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 10:55:57 UTC, Cooler wrote:
Consider 3 functions taking array as an argument:
void fun1(in int[] x){...}
void fun2(ref int[] x){...}
void fun3(int[] x){...}
auto a = new int[10];
fun1(a); // Guaranteed that a will not be changed
fun2(a); // Guaranteed that we will see any change to a, made
in fun2()
fun3(a); // Changes to a in fun3() may be or may be not
visible to the caller
In case of fun3() we have ambiguous behaviour, depending on the
body of the function.
Am I right?
Is that intentional?
Arrays are a pair of pointer and length.
fun1 marks the pointer, the length and the data pointed as const.
fun3 marks nothing const, but since pointer and length are passed
by value, you'll only see changes to the content of x.
fun2 is like fun3, but pointer and length are itself passed by
reference.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote:
Thank you for detailed explanation. But the question is - Is
that correct that language allows ambiguous behavior?
Could you expand your example?
fun(int[] a) {} is passing a by value, that is, the pointer and
length is copied over to fun. Any changes to the elements of a
will be visible, but if you reassign a directly or indirectly
(expanding it so it needs to be copied to a new memory location),
the changes are not visible.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote: Thank you for detailed explanation. But the question is - Is that correct that language allows ambiguous behavior? Where is it ambiguous?
Re: Sorting structs?
On Wednesday, 29 January 2014 at 12:44:37 UTC, Tobias Pankrath wrote: On Wednesday, 29 January 2014 at 11:24:54 UTC, Stanislav Blinov wrote: // Or avoid foreach altogether: studs.map!((ref const s) = writeln(s.name)); } Did you test this one? std.algorithm.map is lazy. Ah yes, sorry, my bad. I forgot to remove foreach during testing and assumed it worked. Facepalm m)
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote: On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote: On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote: Thank you for detailed explanation. But the question is - Is that correct that language allows ambiguous behavior? Where is it ambiguous? Ambiguity is here... When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array a, the caller must see to fun3() body. Ambiguity is - in first and second cases the caller knows what happens with a, but in third case the caller does not know what happens with a. 'in' is a shorthard for 'const scope'. 'const' means that the callee cannot change the passed in parameter in any way, including anything available through that type (for example x[0]) 'scope' means it cannot leave the scope of the callee - that it cannot be stored away anywhere. 'ref' means that the parameter is passed by reference, and thus might be reassigned or changed in any way. No parameters means that it's mutable, but the reference cannot change. I don't see any ambiguities here.
Re: toStringz in std.file
On Wednesday, 29 January 2014 at 08:29:42 UTC, Jakob Ovrum wrote: On Wednesday, 29 January 2014 at 08:27:14 UTC, Ilya Yaroshenko wrote: Hi! Why in std.file toStringz used without store a pointer in function body to prevent GC collection? https://github.com/D-Programming-Language/phobos/blob/master/std/file.d Best Regards, Ilya It is assumed that the pointer is not moved to the C heap where the GC can't see it. The stack is the stack; it doesn't matter if it's a D or C function, the GC sees it anyway. Thanks!
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 13:15:30 UTC, Cooler wrote: On Wednesday, 29 January 2014 at 12:40:00 UTC, Tobias Pankrath wrote: On Wednesday, 29 January 2014 at 11:46:23 UTC, Cooler wrote: Thank you for detailed explanation. But the question is - Is that correct that language allows ambiguous behavior? Where is it ambiguous? Ambiguity is here... When I call fun1() or fun2() I know the behavior directly from function signature (read the comments in my first post). For fun3() case the caller side don't know the behavior directly from function signature. To know what will happen with array a, the caller must see to fun3() body. Ambiguity is - in first and second cases the caller knows what happens with a, but in third case the caller does not know what happens with a. I believe you encounter an array reallocation. If fun3 doesn't change the size of the array - you will see every change made by fun3 to the contents of `a` (but the `a` itself cannot be changed - only the contents). No other way around. If, however, in fun3 you change the size of the array - it may reallocate. Like, if you're appending to `x` - it will allocate a new array and make x point to it. Now `a` and `x` point to distinct arrays. And any change you do using `x` won't be seen by `a`. And, yes, this is the intended behavior.
Re: Array as an argument, ambiguous behaviour.
On 01/29/2014 02:55 AM, Cooler wrote:
Consider 3 functions taking array as an argument:
void fun1(in int[] x){...}
void fun2(ref int[] x){...}
void fun3(int[] x){...}
auto a = new int[10];
fun1(a); // Guaranteed that a will not be changed
fun2(a); // Guaranteed that we will see any change to a, made in fun2()
fun3(a); // Changes to a in fun3() may be or may be not visible to the
caller
In case of fun3() we have ambiguous behaviour, depending on the body of
the function.
Am I right?
Is that intentional?
Yes, that is how slices work in D. The following article explains the
non-determinism that you mention:
http://dlang.org/d-array-article.html
Ali
Re: A possible enhancement related to is()
Jakob Ovrum:
We can already do this, but you have to omit the `Unused` alias
(a semi-recent enhancement allows for that):
---
import std.traits : Unqual;
struct Tuple(Args...) {}
enum isTuple(T) = is(Unqual!T : Tuple!Types, Types...);
Thank you.
Bye,
bearophile
Re: HTTPS, SSL, TLS client on D
You can also use OpenSSL. I wrote a little wrapper class that
extends std.socket.Socket for it:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/sslsocket.d
If you download that file and compile it with your app:
dmd yourfile.d sslsocket.d
you should be able to
import sslsocket.
void main() {
auto sock = new OpenSslSocket(AddressFamily.INET);
sock.connect(new InternetAddress(localhost, 443));
sock.send(GET / HTTP/1.0\r\n\r\n);
import std.stdio;
char[1024] buffer;
writeln(buffer[0 .. sock.receive(buffer)]);
}
which gets from a local https server. Or of course you can
connect to other things too and use the raw socket.
If you want a wrapper library to do http, curl is one option
phobos wrapper:
http://dlang.org/phobos/std_net_curl.html
my old wrapper:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/curl.d
the key function on mine is:
string curl(string url, string data = null, string contentType =
application/x-www-form-urlencoded);
if you pass it a data string, it does a POST, otherwise it goes a
GET on the url.
I've also written non-curl http clients (see http.d and http2.d
in my github), a http server (see cgi.d, it doesn't do ssl itself
but you can put it behind apache or nginx or IIS to get it from
them), and some oauth code (oauth.d in there). If you need to
know anything about them feel free to ask.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote: Yes, that is how slices work in D. The following article explains the non-determinism that you mention: http://dlang.org/d-array-article.html Ali Thank you for the article. Quotation from the article It is a good idea to note in the documentation how the passed in slice might or might not be overwritten. May be just prohibit at language level the case of fun3() function, to do not allow unpredictable behavior? This behavior is just a consequence of the deliberate decision on how arrays should be implemented. Any decision would be a trade-off. Like, if you just disallow this signature, you will have to use .dup at the caller side if you want the semantics of fun3. And often this copy might be unnecessary. It's really like a ball under the carpet. You make it flat in one place, but the ball pops up in the other. The trade-off that D chooses is pretty reasonable. You just have to accept that and get used to it.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 15:11:33 UTC, Cooler wrote: Yes, that is how slices work in D. The following article explains the non-determinism that you mention: http://dlang.org/d-array-article.html Ali Thank you for the article. Quotation from the article It is a good idea to note in the documentation how the passed in slice might or might not be overwritten. May be just prohibit at language level the case of fun3() function, to do not allow unpredictable behavior? It's not unpredictable, at least not more unpredictable then fun2. Should we dissallow this two? int[] a = [1,2,3,4]; b = a; b ~= [5, 6, 7, 8];
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 15:38:34 UTC, Cooler wrote: It's not unpredictable, at least not more unpredictable then fun2. Should we dissallow this two? int[] a = [1,2,3,4]; b = a; b ~= [5, 6, 7, 8]; You don't understand me. You consider that I am author of the fun() and the caller side. Read two post above http://forum.dlang.org/post/dxqxlhyhmdfuashhm...@forum.dlang.org I consider that author of fun() and author of caller side are different persons. They must agree between them how to provide some functionality. If I fun()'s author why do I need to provide fun3() if I already provided fun1() and fun2()? I I caller's author - why may I require fun3() variant, if I already have fun1() and fun2()? Oh, I guess I understood quite well. I just don't see a special problem with arrays, it's just the same as any other aliasing issue. Take this for example: void funS(S* s); // S is a struct, maybe containing a ptr and a length member :-) Should we disallow this as well? When I give a unqualified pointer to a function, the only guarantee I get is that it's pointing to the same location after the call. It's the same with arrays. And since we have this problem every time we pass a pointer to function I don't see why arrays should get special treatment.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote: Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2(). fun3 guarantees that the argument has the same length for example.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote: Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()? Gosh. To allow the function to modify the contents, but not the size of the array.
Re: N-body bench
On Friday, 24 January 2014 at 15:56:26 UTC, bearophile wrote: If someone if willing to test LDC2 with a known benchmark, there's this one: http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody A reformatted C++11 version good as start point for a D translation: http://codepad.org/4mOHW0fz Bye, bearophile Hmm.. How would one use core.simd with LDC2? It doesn't seem to define D_SIMD. Or should I go for builtins?
Re: N-body bench
Stanislav Blinov: Hmm.. How would one use core.simd with LDC2? It doesn't seem to define D_SIMD. Or should I go for builtins? I don't know if this is useful for you, but here I wrote a basic usage example of SIMD in ldc2 (second D entry): http://rosettacode.org/wiki/Four_bits_adder#D Bye, bearophile
Re: Using std.algorithm how to uniq and sort a multidimensional array?
Meta: auto tags = tags.flatMap!uniq.array ? That's another solution. In Phobos a flatMap can be useful (just as a zip overload that accepts a function to apply on the pairs, named zipWith in haskell: http://zvon.org/other/haskell/Outputprelude/zipWith_f.html ). Bye, bearophile
Re: N-body bench
On Wednesday, 29 January 2014 at 16:43:35 UTC, bearophile wrote: Stanislav Blinov: Hmm.. How would one use core.simd with LDC2? It doesn't seem to define D_SIMD. Or should I go for builtins? I don't know if this is useful for you, but here I wrote a basic usage example of SIMD in ldc2 (second D entry): http://rosettacode.org/wiki/Four_bits_adder#D Bye, bearophile I meant how to make it compile with ldc2? I've translated the code, it compiles and works with dmd (although segfaults in -release mode for some reason, probably a bug somewhere). But with ldc2: nbody.d(68): Error: undefined identifier __simd nbody.d(68): Error: undefined identifier XMM those are needed for that sqrt reciprocal call.
Re: N-body bench
Stanislav Blinov: I meant how to make it compile with ldc2? I've translated the code, it compiles and works with dmd (although segfaults in -release mode for some reason, probably a bug somewhere). But with ldc2: nbody.d(68): Error: undefined identifier __simd nbody.d(68): Error: undefined identifier XMM those are needed for that sqrt reciprocal call. Usually for me ldc2 works with simd. Perhaps you have to show us the code, ask for help in the ldc newsgoup, or ask for help in the #ldc IRC channel. Regarding dmd with -release, I suggest you to minimize the code and put the problem in Bugzilla. Benchmarks are also useful to find and fix compiler bugs. Bye, bearophile
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 16:54:27 UTC, Cooler wrote: On Wednesday, 29 January 2014 at 16:36:44 UTC, Stanislav Blinov wrote: On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote: Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()? Gosh. To allow the function to modify the contents, but not the size of the array. Сам то понял чего написал??? :) Yes I did.
Re: Keywords: How to trick the compiler?
On Wednesday, 29 January 2014 at 17:11:32 UTC, Ary Borenszweig wrote: Yes, as there are other ways for body: _body, _body, Body, HtmlBody, etc. But body is the best one. torso? ;)
Re: Keywords: How to trick the compiler?
On 1/28/14, 3:17 PM, Chris wrote: On Tuesday, 28 January 2014 at 17:18:44 UTC, Ary Borenszweig wrote: On 1/28/14, 11:30 AM, bearophile wrote: Ary Borenszweig: In Ruby you can do this: class Foo def end 1 end end Foo.new.end Ruby is a different language from D, they define code safety in quite different ways. Bye, bearophile Having a method named end doesn't make the language less safe. End is cumbersome and looks awkward. Sure there are other ways ;) Yes, as there are other ways for body: _body, _body, Body, HtmlBody, etc. But body is the best one.
Re: N-body bench
On Wednesday, 29 January 2014 at 16:54:54 UTC, bearophile wrote: Stanislav Blinov: I meant how to make it compile with ldc2? I've translated the code, it compiles and works with dmd (although segfaults in -release mode for some reason, probably a bug somewhere). But with ldc2: nbody.d(68): Error: undefined identifier __simd nbody.d(68): Error: undefined identifier XMM those are needed for that sqrt reciprocal call. Usually for me ldc2 works with simd. Perhaps you have to show us the code, ask for help in the ldc newsgoup, or ask for help in the #ldc IRC channel. It's a direct translation of that C++ code: http://dpaste.dzfl.pl/89517fd0bf8fa This line: distance = __simd(XMM.CVTPS2PD, __simd(XMM.RSQRTPS, __simd(XMM.CVTPD2PS, dsquared))); The XMM enum and __simd functions are defined only when D_SIMD version is set. ldc2 doesn't seem to set this, unless I'm missing some sort of compiler switch. Regarding dmd with -release, I suggest you to minimize the code and put the problem in Bugzilla. Benchmarks are also useful to find and fix compiler bugs. I'm already onto it :)
Re: Any library with OAuth support?
On Wednesday, 22 January 2014 at 11:58:17 UTC, Rikki Cattermole wrote: On Wednesday, 22 January 2014 at 11:14:22 UTC, ilya-stromberg wrote: Do you know any library with OAuth support? Not currently. But I can add it to my todo list for Cmsed[0]. [0] https://github.com/rikkimax/Cmsed Yes, it will be great.
Re: A small question default values in tmplate-functions
import std.stdio;
import core.vararg;
auto veryStableAPI(bool brave = false)(string parameter, ...)
{
static if (!brave)
{
pragma(msg, I'm not brave);
}
else
{
pragma(msg, I'm very brave);
}
}
void main(string[] args)
{
veryStableAPI(test);
veryStableAPI!(true)(test);
}
Sorry but that does not anwer my question.
is it legal or is it not ?
Re: A small question default values in tmplate-functions
valid according to spec ? Only trailing parameter can have default arguments.
Static Factory
(Guess is didn't get sent, I guess I'm just a big spam bot cause
I keep getting flagged every post)
The following code demonstrates a way to have an easy factory in
D requiring very little work. I imagine it can be improved to
handle the abstract case(basically dependencies/constraints).
Any ideas on how to improve it? I think auto serialization of the
data of the object will end up being the default behavior. One
should be able to templatize the save/restore code. Once this is
all done I would think very little work would be required in
creating pluggable code(simply use the templates).
module main;
import std.file, std.stdio;
// Mixin iStaticFactory into an interface to provide generic
pluggable derived instantiation.
// Must use New(id, data) as a way to instantiate a new object of
type A(specified by ID) : T. New() is allowed but only provides
// default type and is not pluggable. A msg is given anywhere
New() is used(should only be used when pluggability is not
desired) or during mock up.
//
// The corresponding mixin template cStaticFactory must be used
in all derived types that are to be pluggable.
//
// The user must provide a way to store and retrieve the object
data to allow generic and configurable pluggability. As is,
// any derived type of T may be substituted for T dynamically..
mixin template iStaticFactory(T)
{
@property string _getID();
// returns the type name for
this object
static final T function(string data)[string] _Creators; // An
AA of functions that are registered by the classes which are
desired to be plugged into the interface T.
// Generic New function that returns an initiated instance of a
derived type of T corresponding to data.ID.
static final T New(string file = __FILE__, size_t line =
__LINE__, string mod = __MODULE__)(string id, string data = null)
{
if (id != null _Creators[id] != null) return
_Creators[id](data);
return myA.New(null); // provides default type
}
// Non-Generic New function returning a default derived type of
T used for testing purposes or default object
static final T New(string file = __FILE__, size_t line =
__LINE__, string mod = __MODULE__)()
{
pragma(msg, StaticFactory: Not pluggable at
~mod~:~std.string.chomp(line.stringof, u)~ [~file~]);
return New(null);
}
}
// Mixin cStaticFactory into any class A derived from interface T
to allow it to be pluggable. Mixin static final A New to provide
data initialization of object.
mixin template cStaticFactor(A, T) if (is(A : T))
{
enum _ID = std.traits.fullyQualifiedName!A;
@property string _getID() { return _ID; }
// Registers this class with the _Creators of T's StaticFactory
allowing it to be used to create it's own type. (interface is
only used to ensure the class is registered at runtime. Could be
done elsewhere or dynamically)
static interface iStaticFactory { static this() {
T._Creators[_ID] = New; } }
// Creates and instantiates this type with data. Override to
instantiate data.
static final T New(string data) { A t = new A; if (data == null)
return t; return t; }
}
// Demo:
interface A
{
mixin iStaticFactory!A;
void foo();
}
class myA : A
{
mixin cStaticFactor!(myA, A);
void foo() { writeln(---Called from myA); }
}
class otherA : A
{
mixin cStaticFactor!(otherA, A);
void foo() { writeln(Called from otherA); }
}
void main()
{
enum fn = tempSFdata.tmp;
// load/create our object.
A a = A.New(exists(fn) ? cast(string)read(fn, 100) : null);
// Display object's typeDo something with the object
writeln(Current object type is ~a._getID~ with output :);
a.foo();
// Provide mechanism to change object
foreach(k, v; A._Creators)
{
if (k == a._getID) continue;
writeln(Would you like to change to ~k~ [y/n]); if
(readln() == n) continue;
// Set a to new object type, assume no data
a = v(null);
std.file.write(fn, a._getID);
writeln(Changed to ~k~);
break;
}
}
Re: Win32 with D: Using RegisterClassExA instead of RegisterClass
You need to fill in the cbSize field like so: wce.cbSize = WNDCLASSEXA.sizeof; Ungh. How embarassing. Now it works, thank you.
Re: A small question default values in tmplate-functions
On Wednesday, 29 January 2014 at 18:24:22 UTC, Uplink_Coder wrote: is it legal or is it not ? Yours isn't, no.
Message passing pattern matching
Hey, I'm handling concurrency with message passing, previously with D's concurrency, now with Vibe-d, which I assume works the same way. My app is a chat server, and when a connection is opened to a client, I store the Tid of the thread (or fibre?) handling sending messages out to the client. This lets me broadcast messages to all Tids. When a connection is closed, the thread requests that its Tid is removed from the list. Both adding and removing the Tid technically require only the Tid to be message passed. However, I would like to distinguish between the two cases. I currently have two empty structs named AddTid and RemoveTid, and I pass those along. I assume some bytes must be passed in their place to tell of their type, but that's fine. It does feel rather hacked, however. I'm aware that D doesn't support excessively fancy pattern matching, like what is found in SML, but is there a more correct way to do this? Enums don't work, because they have the same type. I can pattern match the enums later, but I want to do it immediately.
Re: Message passing pattern matching
A small example:
while (true) {
receive(
(Tid tid, AddTid _) {some code}
(Tid tid, RemoveTid _) {some other code}
(string s) {broadcast stuff}
)
}
struct AddTid {}
struct RemoveTid {}
Re: Message passing pattern matching
On Wednesday, 29 January 2014 at 21:50:28 UTC, Casper Færgemand
wrote:
A small example:
while (true) {
receive(
(Tid tid, AddTid _) {some code}
(Tid tid, RemoveTid _) {some other code}
(string s) {broadcast stuff}
)
}
struct AddTid {}
struct RemoveTid {}
From where I sit that's a perfectly fine approach. After all, you
do want to distinguish your own message types: any other
std.concurrency-aware code (i.e. library) could pass its own
messages. You wouldn't want to mistake those for your own private
communication protocol.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 22/01/2014 14:13, Flamaros a écrit :
On Wednesday, 22 January 2014 at 02:11:02 UTC, TheFlyingFiddle wrote:
On Saturday, 18 January 2014 at 19:40:38 UTC, Xavier Bigand wrote:
I am not sure the issue come really from my code, cause it just works
fine on ATI cards, I do something Nvidia drivers dislike.
I tried to replace GL_LINE_LOOP by triangles, increase buffer size,
put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right before
glDrawElements without success.
Crash only append when I fill text mesh before those ones. So I need
dig more.
From what i saw in your code you are not using Vertex Array Objects. I
have had similar problems that code ran fine on ATI but crashed on
nvidia. The problem went away for me when i just created and bound a
global VAO just after context creation.
Also i would recommend calling glGetError after every call, it helps
finding errors. Here is a simple trick to do this automatically.
static gl
{
static ref auto opDispatch(string name, Args...)(Args args)
{
enum glName = gl ~ name[0].toUpper.to!string ~ name[1 .. $];
debug scope(exit) checkGLError(); //Do glGetError and log it or
something.
mixin(return ~ glName ~ (args););
}
}
After this simply change all glFunctionName(args) to gl.functionName
or gl.functionName.
I will try the global VAO.
I already check glError with checkgl! function.
I finally found the issue, glDisableVertexAttribArray calls were
missing. I just doesn't understand why it works majority of times and
any openGL debugging tool was able to warm me about that.
Maybe I need try DirectX and see if debugging tools are better.
Re: Sorting structs?
On Wednesday, 29 January 2014 at 11:24:54 UTC, Stanislav Blinov wrote: On Wednesday, 29 January 2014 at 10:30:06 UTC, Boomerang wrote: // also it's worth using ref const to avoid // unnecessary copies I am new to D. Why should someone use ref const instead of in?
core.stdc.config
So, there is a module core.stdc.config (referenced here): http://dlang.org/interfaceToC.html That is presumably part of the D Standard library. I am curious to know why no mention of this library is included at: http://dlang.org/phobos/index.html Is it not part of Phobos? Are there standard modules in D that are not included in Phobos? If so, where would one find the list of these modules.
Re: Source code annotations alla Java
On Friday, 21 January 2011 at 20:50:39 UTC, Jonathan M Davis
wrote:
On Friday, January 21, 2011 12:36:23 Ary Manzana wrote:
On 1/20/11 5:48 PM, Jacob Carlborg wrote:
On 2011-01-20 21:34, Steven Schveighoffer wrote:
On Thu, 20 Jan 2011 15:03:55 -0500, Jacob Carlborg
d...@me.com wrote:
On 2011-01-20 19:18, Steven Schveighoffer wrote:
On Thu, 20 Jan 2011 13:07:58 -0500, Jacob Carlborg
d...@me.com wrote:
On 2011-01-20 15:02, Steven Schveighoffer wrote:
On Thu, 20 Jan 2011 08:47:28 -0500, Justin Johansson
j...@nospam.com
wrote:
Not long ago the Java Language people introduced the
idea of
annotations together with an annotation processing
tool (apt).
Now perhaps the idea of source code annotations is not
actually a
Java
invention per se, however for someone learning D is
there any
equivalent idiom [of Java annotations] in the D
language?
Haven't used Java since they added annotations, but I
think they are
like C# attributes?
In any case, D has an annotation syntax like:
@property
But I think at the moment, annotations have no custom
ability. Only
compiler-defined annotations are allowed. This may
change in the
future,
but probably not short-term. FWIW, I think we need a
much richer
runtime-reflection capability before we can use custom
annotations
to any great effect.
-Steve
I would rather formulate it like: currently D has a
syntax for
keywords that are similar to Java annotations.
I don't think it's the same thing. Keywords are not
allowed to be used
anywhere else, even for things that would parse properly
were they not
keywords. They are anchors for the parser to determine
where it is. In
contrast, a compiler-defined annotation is parsed just
the same as a
custom one, it's just that the meaning is predefined.
For example, you can legally do:
int property;
without error, but this won't even get past the parsing
stage:
int struct;
-Steve
I assume you meant int @property;?
No. I meant int property;
Of course that would work, isn't that like saying this won't
work:
int struct_; // ?
A keyword is specifically not allowed where the grammar
would otherwise
allow it. A symbol isn't allowed to have @ in it, so this
naturally
prevents a conflict. I realize the poor example, but it's
definitely not
a keyword. Otherwise, it would be listed here:
http://www.digitalmars.com/d/2.0/lex.html#keyword
(actually, are
annotations part of the lexical grammar there?).
It's more like Object, which is not a keyword, but you
aren't allowed to
use it to mean anything besides what it means.
The end result is, it fails if you use it in the wrong
place, but the
keyword status makes it fail at the parsing stage. I am not
a compiler
writer, so I'm talking a bit from my ass here.
-Steve
Ok, maybe you're right. I'm pretty sure, as you say, that a
keyword in
the wrong place would fail during parsing. But I don't know
where a
misplaced annotation/attribute would fail.
Jacob is right here.
This, as you say, fails:
int struct;
And also this fails:
int @property;
So yes, currently @property is just a keyword with a prepended
@.
Annotations in Java anc C# can have arguments. That is not the
case in
D. For example, as it is said in DIP6, you could have:
@extern('C')
void someFunc();
instead of having extern a keyword and thus being unable to
use it for
identifiers.
No. No attributes are keywords. The reasoning is simple. A
keyword is a word
that would be a valid identifier but isn't, because the
language treats it as
special. @ is not a valid part of an identifier. So, @property
can't be a
keyword. And property certainly isn't a keyword, since you
_can_ use it as an
identifier, so it isn't a keyword with @ prepended on either.
True, @property is treated as a special symbol by the compiler,
and I don't
expect that it really treats it like an attribute with the name
property (which
it will pretty much have to do if we ever get user-defined
attributes), but
definitely isn't a keyword, because it was never possible for
it to be a valid
identifier in the first place.
- Jonathan M Davis
I see eclipse4 used java annotations heavily to mark up code
for dependency injection in the new ide framework.
Someone recommended use of mixin in this thread, in place of the
java use of user defined annotations. Is that still the
recommended D solution for handling ports of java annotations?
https://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection
Re: Sorting structs?
On Thursday, 30 January 2014 at 03:00:43 UTC, Paul-Andre wrote: On Wednesday, 29 January 2014 at 11:24:54 UTC, Stanislav Blinov wrote: On Wednesday, 29 January 2014 at 10:30:06 UTC, Boomerang wrote: // also it's worth using ref const to avoid // unnecessary copies I am new to D. Why should someone use ref const instead of in? in is the same as 'scope const' (scope checks aren't implemented) So you be relying on the optimizer to not copy.
Re: core.stdc.config
On 1/30/2014 12:28 PM, Craig Dillabaugh wrote: Is it not part of Phobos? Are there standard modules in D that are not included in Phobos? If so, where would one find the list of these modules. All of the core.* modules are part of DRuntime, not Phobos.
Re: Array as an argument, ambiguous behaviour.
On Wednesday, 29 January 2014 at 16:26:05 UTC, Cooler wrote: On Wednesday, 29 January 2014 at 16:15:36 UTC, Tobias Pankrath wrote: On Wednesday, 29 January 2014 at 16:01:08 UTC, Cooler wrote: Do you read my post? I am answering... why do I need fun3() if I already have fun1() and fun2(). fun3 guarantees that the argument has the same length for example. Where argument has the same length? After function call, or inside function? I don't understand what my intention should be to push me to use fun3()? If you want to modify the slice and make changes visible in caller, you should use ref. If you don't care whether changes are visible in caller, you can omit any attributes and use plain array. This belongs to the case you are asking about. If you don't want to change array in callee, pass it as const qualified. Now, after rethinking the issue I am inclining that don't care whether changes are visible for caller is not very wrong, but not very good design. Ideally it should be specified to avoid unexpected problems to pop up. So yes, it is better to qualify array. Another point. This casino games of whether changes would be visible or not is direct consequence of how slices are implemented (and how runtime service them). Remember, that many features in D work in a strange way not because of wise design but as a consequence of not fully thought design (like array). As a result, some features work in not best way they should. Although many folks in newsgroups would eagerly say that you don't understand the lang, it wouldn't make a bad design a good one.
Re: core.stdc.config
On 2014-01-30 05:42, Mike Parker wrote: All of the core.* modules are part of DRuntime, not Phobos. Unfortunately none of the core.stdc.* modules are documented. It's understandable that duplicating the documentation of the C library is not done since that would require extra work. But it would be nice to at least see which modules and declarations are available. -- /Jacob Carlborg
