Re: constant expression
On Tuesday, 23 February 2016 at 07:43:37 UTC, Ali Çehreli wrote:
On 02/22/2016 11:38 PM, Nicholas Wilson wrote:
I've tried with both mutable and immutable a module scope.
Scope I want
is global (don't care about mutability)
Uncomment immutable if you want immutable and remove 'shared'
if you want multiple of this per thread (probably not).
/* immutable */ string[string] ctodtypes;
shared static this() {
ctodtypes =
[
"void" : "void",
"uint32_t" : "uint",
"uint64_t" : "ulong",
"int32_t" : "int",
"int64_t" : "long",
"char" : "char",
"uint8_t" : "ubyte",
"size_t": "size_t",
"float" : "float"
];
}
void main() {
ctodtypes["hello"] = "world";
}
Ali
Thanks
Silly question. Why is this necessary?
SIGSEGV when using D DLL with Qt MinGW
Hello guys, as the title says I'm getting a SIGSEGV when trying
to use a D DLL.
Let's take a look on this C++ code:
extern "C" __declspec(dllimport) void D_user_fillEngine(const
char* workDir, void* engine);
extern "C" __declspec(dllimport) int D_user_startUp();
extern "C" __declspec(dllimport) int D_user_terminate();
int main(int argc, char *argv[])
{
D_user_startUp();
D_user_fillEngine("path", nullptr);
QApplication app(argc, argv);
QQmlApplicationEngine engine;
engine.load(QUrl(QStringLiteral("qrc:/main.qml")));
int res = app.exec();
D_user_terminate();
return res;
}
Just normal Qt startup code with some external DLL
loading/calling by OS.
The D_user_* calls just have to be there to cause the SIGSEGV,
not being executed. So I guess something is wrong with the way
this DLL is loaded.
And the D code:
export extern(C) void D_user_fillEngine(char* c_workDir, void*
c_qmlEngine) {
//Foo
}
export extern(C) int D_user_startUp() {
//Intended for rt_init();
}
export extern(C) int D_user_terminate() {
//Intended for rt_term();
}
I am using the following environment:
Windows 7
Qt 5.5
MinGW 4.9
DMD 2.69.1
DUB (with dynamicLibrary option)
Everything is x86.
I am really stuck here. Thanks on beforehand.
call to super trashes pointer?
struct A
{
int blah;
}
class B
{
A* a;
this(A* _a)
{
writeln(_a)
a =_a;
}
}
class C : B
{
this(A* _a)
{
writeln(_a)
super(_a);
}
}
int main(string[] args)
{
A a;
writeln(&a);
C c = new C(&a);
}
prints
7FFF56E787F8
7FFF56E787F8
null
??? What is happening here?
Re: call to super trashes pointer?
On Tuesday, 23 February 2016 at 09:16:08 UTC, Nicholas Wilson
wrote:
struct A
{
int blah;
}
class B
{
A* a;
this(A* _a)
{
writeln(_a)
a =_a;
}
}
class C : B
{
this(A* _a)
{
writeln(_a)
super(_a);
}
}
int main(string[] args)
{
A a;
writeln(&a);
C c = new C(&a);
}
prints
7FFF56E787F8
7FFF56E787F8
null
??? What is happening here?
fwiw I can reassign the reference (in the classes) to a after B's
call to super but still ...
Re: call to super trashes pointer?
On Tuesday, 23 February 2016 at 09:16:08 UTC, Nicholas Wilson
wrote:
struct A
{
int blah;
}
class B
{
A* a;
this(A* _a)
{
writeln(_a)
a =_a;
}
}
class C : B
{
this(A* _a)
{
writeln(_a)
super(_a);
}
}
int main(string[] args)
{
A a;
writeln(&a);
C c = new C(&a);
}
prints
7FFF56E787F8
7FFF56E787F8
null
??? What is happening here?
I can't reproduce this. After making a few changes to get the
code to compile (adding ; after the first two writeln's, and
changing int main to void main), everything works as expected.
Which compiler and version are you using?
Re: call to super trashes pointer?
On Tuesday, 23 February 2016 at 10:47:17 UTC, Rene Zwanenburg
wrote:
On Tuesday, 23 February 2016 at 09:16:08 UTC, Nicholas Wilson
wrote:
struct A
{
int blah;
}
class B
{
A* a;
this(A* _a)
{
writeln(_a)
a =_a;
}
}
class C : B
{
this(A* _a)
{
writeln(_a)
super(_a);
}
}
int main(string[] args)
{
A a;
writeln(&a);
C c = new C(&a);
}
prints
7FFF56E787F8
7FFF56E787F8
null
??? What is happening here?
I can't reproduce this. After making a few changes to get the
code to compile (adding ; after the first two writeln's, and
changing int main to void main), everything works as expected.
Which compiler and version are you using?
v2.067-devel-e431363
I "fixed" it see above.
dub dustmite: Initial test fails
Hi!
I have a code with segfault. I decided to try to take advantage
with dub dustmite:
$ dub dustmite ~/ssd/pgator_dustmite0 --program-status=139 --
--config=my_pgator.conf --debug=true
WARNING: A deprecated branch based version specification is used
for the dependency vibe-d-postgresql. Please use numbered
versions instead. Also note that you can still use the
dub.selections.json file to override a certain dependency to use
a branch instead.
Copy package 'pgator' to destination folder...
Copy package 'vibe-d-postgresql' to destination folder...
Copy package 'dpq2' to destination folder...
Copy package 'derelict-pq' to destination folder...
Copy package 'derelict-util' to destination folder...
Copy package 'vibe-d' to destination folder...
Copy package 'libasync' to destination folder...
Copy package 'memutils' to destination folder...
Copy package 'libev' to destination folder...
Copy package 'libevent' to destination folder...
Copy package 'openssl' to destination folder...
Executing dustmite...
None => No
object.Exception@DustMite/dustmite.d(243): Initial test fails
but if I try to run already compiled binary it is successfully
core dumps:
$ ./pgator --config=my_pgator.conf --debug=true; echo $?
2016-02-23T18:07:00.748:package.d:_sharedStaticCtor6:9 DerelictPQ
loading...
2016-02-23T18:07:00.748:package.d:_sharedStaticCtor6:16
...DerelictPQ loading finished
2016-02-23T18:07:00.750:package.d:connectionFactory:50 creating
new connection
2016-02-23T18:07:00.750:package.d:connectionFactory:54 new
connection is started
2016-02-23T18:07:00.750:package.d:runStatementBlockingManner:126
runStatementBlockingManner
2016-02-23T18:07:00.750:package.d:doQuery:66 get connection from
a pool
2016-02-23T18:07:00.753:package.d:doQuery:90 doesQuery() call
2016-02-23T18:07:00.753:package.d:__lambda5:140 consumeInput()
2016-02-23T18:07:00.753:package.d:__lambda5:145 getResult()
2016-02-23T18:07:00.753:package.d:__lambda5:145 getResult()
2016-02-23T18:07:00.754:app.d:main:88 found method row:
"echo" "SELECT $1::text as echoed" ["value_for_echo"] false
2016-02-23T18:07:00.754:app.d:main:137 Method echo loaded.
Content: Method("echo", "SELECT $1::text as echoed",
["value_for_echo"], false)
2016-02-23T18:07:00.754:app.d:main:88 found method row:
"echo2" "SELECT $1::text" ["value_for_echo"] NULL
2016-02-23T18:07:00.754:app.d:main:132 Value of column
one_row_flag is NULL, skipping reading of method echo2
2016-02-23T18:07:00.754:app.d:main:88 found method row:
"wrong_sql_statement" "wrong SQL statement" [] false
2016-02-23T18:07:00.754:app.d:main:137 Method wrong_sql_statement
loaded. Content: Method("wrong_sql_statement", "wrong SQL
statement", [], false)
2016-02-23T18:07:00.754:app.d:main:141 Number of methods in the
table "pgator_rpc": 3, failed to load: 1
2016-02-23T18:07:00.754:app.d:__foreachbody18:148 try to prepare
method wrong_sql_statement
2016-02-23T18:07:00.754:package.d:runStatementBlockingManner:126
runStatementBlockingManner
2016-02-23T18:07:00.754:package.d:doQuery:66 get connection from
a pool
2016-02-23T18:07:00.754:package.d:doQuery:90 doesQuery() call
2016-02-23T18:07:00.754:package.d:__lambda5:140 consumeInput()
2016-02-23T18:07:00.754:package.d:__lambda5:145 getResult()
2016-02-23T18:07:00.754:package.d:__lambda5:145 getResult()
2016-02-23T18:07:00.755:app.d:__foreachbody18:160 ОШИБКА: ошибка
синтаксиса (примерное положение: "wrong")
LINE 1: wrong SQL statement
^
, skipping preparing of method wrong_sql_statement
2016-02-23T18:07:00.755:app.d:__foreachbody18:162 catched
2016-02-23T18:07:00.755:app.d:__foreachbody18:165 next
Ошибка сегментирования (core dumped)
139
How how to understand why dub dustmite doesn't work for me?
arsd.dom getElementsByTagNameChildrenOnly?
So the vulkan spec has a lot of stuff like VkStructureType sType const void* pNext optional="true">VkBufferCreateFlags flags VkDeviceSize size VkBufferUsageFlags usage VkSharingMode sharingMode uint32_t queueFamilyIndexCount len="queueFamilyIndexCount">const uint32_t* pQueueFamilyIndices ... ... How do I iterate over the child level elements only (ignoring the ones like VkStructureType)? Do i have to check their parentage each time or is there an easier way?
Re: Simple performance question from a newcomer
On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote: I do have to wonder, however, about the default settings of dub in this case. Having gone through its documentation, I might still not have guessed to try the compiler options you provided, thereby losing out on a 2-3x performance improvement. What build options did you use in your dub.json that it managed to translate to the correct compiler switches? Your experience is exactly what the D community needs to get right. You've come in as an interested user with patience and initially D has offered slightly disappointing performance for both technical reasons and because of the different compilers. You've gotten to the right place in the end but we need point A to point B to be a lot smoother and more obvious so more people get a good initial impression of D. Every D user thread seems to go like this- someone starts with DMD, they then struggle a little and hopefully get LDC working with a list of slightly obscure compiler switches offered. A standard algorithm performs disappointingly for somewhat valid technical reasons and more clunky alternatives are then deployed. We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. What are your thoughts on D now? What would have helped you get to the right place much faster?
Re: SIGSEGV when using D DLL with Qt MinGW
On Tuesday, 23 February 2016 at 08:50:45 UTC, Jerry wrote: I am using the following environment: Windows 7 Qt 5.5 MinGW 4.9 DMD 2.69.1 DUB (with dynamicLibrary option) Everything is x86. I am really stuck here. Thanks on beforehand. I'm surprised you're able to get an executable when linking with the import library. By default, DMD uses the OPTLINK linker for 32-bit output, which creates object files in OMF format. MinGW uses COFF. If you want 32-bit COFF output from DMD, you'll need to make sure you have the Microsoft compiler tools installed (Visual Studio Community Edition is an easy way to get everything you need) and use the -m32mscoff command line switch with DMD when compiling your DLL. However, there are often incompatibilities between MinGW's COFF and Microsoft's COFF, so you may still get no joy.
Re: SIGSEGV when using D DLL with Qt MinGW
On Tuesday, 23 February 2016 at 11:10:30 UTC, Mike Parker wrote: I'm surprised you're able to get an executable when linking with the import library. I actually just tried a bunch of extern(?), extern "?" combinations and it compiled. If you want 32-bit COFF output from DMD, you'll need to make sure you have the Microsoft compiler tools installed (Visual Studio Community Edition is an easy way to get everything you need) and use the -m32mscoff command line switch with DMD when compiling your DLL. However, there are often incompatibilities between MinGW's COFF and Microsoft's COFF, so you may still get no joy. I guess I should switch C++ compiler then. Just to stay on the safe side. Maybe Clang. Tryed to Google for the format but didn't find it. Also it seems someone has compiled Qt using it.
Re: dub dustmite: Initial test fails
On Tuesday, 23 February 2016 at 11:09:00 UTC, denizzzka wrote: Hi! I have a code with segfault. I decided to try to take advantage with dub dustmite: $ dub dustmite ~/ssd/pgator_dustmite0 --program-status=139 -- --config=my_pgator.conf --debug=true Shells process signal exit codes in a special way. Try `--program-status=-11`.
Re: constant expression
On 2/23/16 3:00 AM, Nicholas Wilson wrote:
On Tuesday, 23 February 2016 at 07:43:37 UTC, Ali Çehreli wrote:
On 02/22/2016 11:38 PM, Nicholas Wilson wrote:
I've tried with both mutable and immutable a module scope. Scope I want
is global (don't care about mutability)
Uncomment immutable if you want immutable and remove 'shared' if you
want multiple of this per thread (probably not).
/* immutable */ string[string] ctodtypes;
shared static this() {
ctodtypes =
[
"void" : "void",
"uint32_t" : "uint",
"uint64_t" : "ulong",
"int32_t" : "int",
"int64_t" : "long",
"char" : "char",
"uint8_t" : "ubyte",
"size_t": "size_t",
"float" : "float"
];
}
void main() {
ctodtypes["hello"] = "world";
}
Ali
Thanks
Silly question. Why is this necessary?
D cannot create associative arrays at compile time that can be used
during runtime. You have to create them at runtime.
It could probably do effectively what is done above, however. Just
nobody has made that enhancement.
-Steve
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. While I agree with most of what you're saying, I don't think we should prioritize performance over accuracy or correctness. Especially for numerics people, precision is very important, and it can make a just as bad first impression if we don't get this right. We can however make the note in the documentation (which already talks about performance) a bit more prominent: http://dlang.org/phobos/std_algorithm_iteration.html#sum
Re: call to super trashes pointer?
On 2/23/16 6:05 AM, Nicholas Wilson wrote:
On Tuesday, 23 February 2016 at 10:47:17 UTC, Rene Zwanenburg wrote:
On Tuesday, 23 February 2016 at 09:16:08 UTC, Nicholas Wilson wrote:
struct A
{
int blah;
}
class B
{
A* a;
this(A* _a)
{
writeln(_a)
a =_a;
}
}
class C : B
{
this(A* _a)
{
writeln(_a)
super(_a);
}
}
int main(string[] args)
{
A a;
writeln(&a);
C c = new C(&a);
}
prints
7FFF56E787F8
7FFF56E787F8
null
??? What is happening here?
I can't reproduce this. After making a few changes to get the code to
compile (adding ; after the first two writeln's, and changing int main
to void main), everything works as expected. Which compiler and
version are you using?
v2.067-devel-e431363
I "fixed" it see above.
This is not a released version. Using both 2.067.1 and 2.068.0, I get
the expected behavior. There could have been a regression fixed between
that version and the release, I suggest you try a released version:
http://dlang.org/download.html#dmd
-Steve
Re: arsd.dom getElementsByTagNameChildrenOnly?
On Tuesday, 23 February 2016 at 11:10:17 UTC, Nicholas Wilson
wrote:
How do I iterate over the child level elements only (ignoring
the ones like VkStructureType)?
Element.childNodes gives only direct children.
You could also do
document.querySelectorAll("types > type")
to get only the tags that are a direct child of .
(If you've ever done CSS or Javascript, this is similar syntax. I
didn't implement the whole selector syntax and haven't kept up
with any of the bleeding edge stuff, but all the basics work the
same way.)
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote: I do have to wonder, however, about the default settings of dub in this case. Having gone through its documentation, I might still not have guessed to try the compiler options you provided, thereby losing out on a 2-3x performance improvement. What build options did you use in your dub.json that it managed to translate to the correct compiler switches? Your experience is exactly what the D community needs to get right. You've come in as an interested user with patience and initially D has offered slightly disappointing performance for both technical reasons and because of the different compilers. His concern is with the default settings of Dub. I've tried Dub and given up several times, and I've been using D since 2013. The community needs to provide real documentation. It's embarrassing that it's pushed as the official package manager and will soon be included with DMD.
Re: Issues
On Tuesday, 23 February 2016 at 00:13:23 UTC, ag0aep6g wrote: On 22.02.2016 23:56, Andre wrote: I was wondering how people in this D community think about the number of issues with NEW status... It could scare individuals/organizations to start with D, when they get the impression that there are a large and growing number of issues that are open (for years). I know this is not a fair interpretation of what's going on, but it's a conclusion one could make. I guess my reopening of issue 4763 [1] got you here. Old issues may be embarrassing, but I believe closing them without proper resolution, just because they're old, is very bad practice. Regarding old enhancement request that never got anywhere, it's certainly tempting to just throw them away, but I think it's a bad move when a single member of the community just closes issues that have been filed by someone else. That would make for bad weather in the community. Instead, I suggest to engage in discussion with the proponent(s) of the request. Or implement the request and try to get it merged. - Is there a preferred way to clean things up? Fix stuff :P A resolution status? Not sure what kind of status you're looking for. There's WONTFIX, but you shouldn't apply it just because an issue is old. As far as I know, we don't use LATER and REMIND. A maximum time? No. - Or perhaps the bugtracker (https://dlang.org/bugstats.php) needs to be adjusted for irrelevant things.. What do you mean by "irrelevant"? If you think an issue is irrelevant, please argue your point in the comments section of the issue. Maybe all enhancement requests (that are not closely followed by an implementation) are "irrelevant"? I could understand that viewpoint, but that's not how we operate at the moment. If you want us to go in that direction, ask about it in the General group, and if there's consensus to do away with (long-lived) enhancement requests, mass-close them. By the way, I don't like the bugstats.php page all that much. Some time ago I've played around with charts and put this together: https://issues.dlang.org/chart.cgi?category=D&datefrom=&dateto=&label0=normal%20bugs&label1=enhancement%20requests&label2=major%20bugs&label3=minor%20bugs&label4=critical%20bugs&label5=blockers&label6=trivial%20bugs&label7=regressions&line0=101&line1=104&line2=100&line3=102&line4=99&line5=98&line6=103&line7=97&name=98&subcategory=data%20sets%20by%20severity&action=wrap&width=600&height=650 I think it's more interesting than the one on bugstats.php. But it doesn't go back as far - it only started counting when I created it. Then I gave up. - Or is it a non-issue and should we just ignore the tail of the list? Not ignore it, work towards reducing it by actually resolving stuff. [1] https://issues.dlang.org/show_bug.cgi?id=4763 Judging from the quick response(s) to #4763 and this question I get the impression this is an active, positive and thoughtful community. Compliments! I think your 'definition' of irrelevant is getting us somewhere: - enhancement requests - that are not closely followed by an implementation - with outdated information - empty CC - no votes - no owner I agree with your point that a single member should not close something just because it's old. On the other hand, the issuer also has a responsibility to track/coordinate/complete issues. In case of #4763 I closed it because 2 out of 3 enhancement requests were fixed/solved and the 3rd was open for about 5 years, without recent activity, no owner, empty CC and no votes. Instead, I suggest to engage in discussion with the proponent(s) of the request. Point taken, I could have asked the proponent. Or implement the request and try to get it merged. I agree with all people responding, resolving is the best way to go. About the >bugif it only shows bugs. For marketing and to challenge everyone to keep it near zero. Thanks for everyone's insights.
Starting threads inside class
My goal with the code below is to eventually have my main
communicate with Foo and Bar classes listening for packets on a
different address/port, each in a separate thread. They would
then communicate with Foobaz and Barbaz threads respectively to
do other work. In trying to get just Foo working though, I'm
getting this error:
Error: template std.concurrency.spawn cannot deduce function from
argument types !()(void delegate(Tid ownerTid), Tid), candidates
are:
D:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(466):
std.concurrency.spawn(F, T...)(F fn, T args) if
(isSpawnable!(F, T))
The code works fine if I call daemon as a normal function, but it
holds up the main thread.
Is there anything I'm doing wrong here? I'm not accessing
anything outside this class from inside, and the most I would be
doing from outside is accessing the Tid in order to send packets
from my main.
class Foo
{
private string address = "127.0.0.1";
private ushort port = 5;
private ubyte[256] buffer;
private TcpSocket mysock;
Tid listenerd;
this()
{
listenerd = spawn(&daemon, thisTid);
}
void setup()
{
mysock = new TcpSocket();
mysock.blocking = true;
try
{
mysock.connect(new InternetAddress(address, port));
}
catch (SocketOSException e)
{
}
}
void initialise()
{
// send init packet
}
void closeConnection()
{
// send close packet
}
void packetHandler()
{
// do something with buffer
}
void daemon(Tid ownerTid)
{
setup();
initialise();
int rxSize = -1;
while (true)
{
rxSize = mysock.receive(buffer);
if (rxSize == 0)
{
break;
}
packetHandler();
}
closeConnection();
}
}
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote: On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. While I agree with most of what you're saying, I don't think we should prioritize performance over accuracy or correctness. Especially for numerics people, precision is very important, and it can make a just as bad first impression if we don't get this right. We can however make the note in the documentation (which already talks about performance) a bit more prominent: http://dlang.org/phobos/std_algorithm_iteration.html#sum Wouldn't it be better to have technically perfect implementations for those numerics people? Sum is a basic function that almost everyone may want to use, this is a factor of four slowdown for the sake of one user group who could be perfectly well served by a sub-library that contains high-accuracy versions. It might make sense if the speed difference were only a few percent.
Re: Issues
On Tue, Feb 23, 2016 at 02:38:42PM +, Andre via Digitalmars-d-learn wrote: [...] > In case of #4763 I closed it because 2 out of 3 enhancement requests > were fixed/solved and the 3rd was open for about 5 years, without > recent activity, no owner, empty CC and no votes. [...] Sometimes people overlook certain issues for a long time, that's why they have empty CC and no votes. But they may be actual issues that should be fixed. When I have free time I like to browse old bugs to see if there are any neglected bugs that ought to be fixed -- I've fixed a few that had been otherwise overlooked for a long time. If you like, you could join me (and several others) who regularly trawl through old bugs and find low-hanging fruit that can be easily fixed. ;-) Or, at the very least, bring it to people's attention in the forum, say, if you feel it's important -- it could be that people just overlooked the bug and it's actually an important issue to fix. Also, as somebody else has said, very few bugs actually get assigned; most of the time people just work on them and submit PRs for them, and they simply go from NEW to RESOLVED directly. We've also tried to promote the use of votes, but AFAICT that hasn't really caught on either, so I wouldn't put too much weight on the fact that most bugs have no votes. T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy
Re: Issues
On Monday, 22 February 2016 at 23:21:28 UTC, Jonathan M Davis wrote: Well, if you'll notice th list of resolved issues is going up way faster than the list of new issues. (To put some oil on the fire:) But the number of new issues /is/ going up. I.e. the number of resolved issues is going way up, the number of new new issues is going way way up. That's how I read the graph. (Please help to resolve issues, rather than spending time on the forum talking about it ;) :-)
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: On Monday, 22 February 2016 at 15:43:23 UTC, dextorious wrote: I do have to wonder, however, about the default settings of dub in this case. Having gone through its documentation, I might still not have guessed to try the compiler options you provided, thereby losing out on a 2-3x performance improvement. What build options did you use in your dub.json that it managed to translate to the correct compiler switches? Your experience is exactly what the D community needs to get right. You've come in as an interested user with patience and initially D has offered slightly disappointing performance for both technical reasons and because of the different compilers. You've gotten to the right place in the end but we need point A to point B to be a lot smoother and more obvious so more people get a good initial impression of D. Every D user thread seems to go like this- someone starts with DMD, they then struggle a little and hopefully get LDC working with a list of slightly obscure compiler switches offered. A standard algorithm performs disappointingly for somewhat valid technical reasons and more clunky alternatives are then deployed. We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. What are your thoughts on D now? What would have helped you get to the right place much faster? Personally, I think a few aspects of documentation for the various compilers, dub and possibly the dlang.org website itself could be improved, if accessibility is considered important. For instance, just to take my journey with trying out D as an example, I can immediately list a few points where I misunderstood or failed to find relevant information: 1. While the dlang.org website does a good job presenting the three compilers side by side with a short pro/con list for each and does mention that DMD produces slower code, I did not at first expect the difference to be half an order of magnitude or more. In retrospect, after reading the forums and learning about how each compiler works, this is quite obvious, but the initial impression was misleading. 2. The LDC compiler gave me a few issues during setup, particularly on Windows. The binaries supplied are dynamically linked against the MSVS2015 runtime (and will fail on any other system) and seem to require a full Visual Studio installation. I assume there are good reasons for this (though I hope in the future a more widely usable version could be made available), but the fact itself could be made clearer on the download page (it can be found after some searching on the D wiki and the forums). 3. The documentation for the dub package is useful, but somewhat difficult to read due to how it is structured and does not seem complete. For instance, I am still not sure how to make it pass the -O5 switch to the LDC2 compiler and the impression I got from the documentation is that explicit manual switches can only be supplied for the DMD compiler. It says that when using other compilers, the relevant switches are automatically translated to appropriate options for GDC/LDC, but no further details are supplied and no matter what options I set for the DMD compiler, using --compiler=ldc2 only yields -O and not -O5. For the moment, I'm compiling my code and managing dependencies manually like I would in C++, which is just fine for me personally, but does leave a slightly disappointing impression about what is apparently considered a semi-official package manager for the D language. Of course, this is just my anecdotal experience and should not be taken as major criticism. It may be that I missed something or did not do enough research. Certainly, some amount of adjustment is to be expected when learning a new language, but there does seem to be some room for improvement.
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 14:07:22 UTC, Marc Schütz wrote: On Tuesday, 23 February 2016 at 11:10:40 UTC, ixid wrote: We really need to standard algorithms to be fast and perhaps have separate ones for perfect technical accuracy. While I agree with most of what you're saying, I don't think we should prioritize performance over accuracy or correctness. Especially for numerics people, precision is very important, and it can make a just as bad first impression if we don't get this right. We can however make the note in the documentation (which already talks about performance) a bit more prominent: http://dlang.org/phobos/std_algorithm_iteration.html#sum Being new to the language, I certainly make no claims about what the Phobos library should do, but coming from a heavy numerics background in many languages, I can say that this is the first time I've seen a common summation function do anything beyond naive summation. Some languages feature more accurate options separately, but never as the default, so it did not occur to me to specifically check the documentation for something like sum() (which is my fault, of course, no issues there). Having the more accurate pairwise summation algorithm in the standard library is certainly worthwhile for some applications, but I was a bit surprised to see it as the default.
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote: Personally, I think a few aspects of documentation for the various compilers, dub and possibly the dlang.org website itself could be improved, if accessibility is considered important. Couldn't agree more. Being new to the language, I certainly make no claims about what the Phobos library should do, but coming from a heavy numerics background in many languages, I can say that this is the first time I've seen a common summation function do anything beyond naive summation. Some languages feature more accurate options separately, but never as the default, so it did not occur to me to specifically check the documentation for something like sum() (which is my fault, of course, no issues there). Having the more accurate pairwise summation algorithm in the standard library is certainly worthwhile for some applications, but I was a bit surprised to see it as the default. I think that's fair. I think part of the reason for the focus on accuracy over speed is that floats can have really weird behavior sometimes. For most people, it's better to be a little slower all the time in order to get the right answer all the time (or as often as possible with floats). And people who want more speed, can look at the docs and figure out what they need to do to get more.
Re: Issues
On Tuesday, 23 February 2016 at 19:53:52 UTC, Johan Engelen wrote: On Monday, 22 February 2016 at 23:21:28 UTC, Jonathan M Davis wrote: Well, if you'll notice th list of resolved issues is going up way faster than the list of new issues. (To put some oil on the fire:) But the number of new issues /is/ going up. I.e. the number of resolved issues is going way up, the number of new new issues is going way way up. That's how I read the graph. (Please help to resolve issues, rather than spending time on the forum talking about it ;) :-) For me this was helpful to get an idea what's going on, how people work on/think about issues, priorities, etc. So please consider this time a little investment to get a new member more involved. I'm considering working on some easy issues first. I will ignore the enhancement requests from bearophile that have status new, no votes, no one in CC, no comments. There are more than 200 (!) of them. These issues could be valid/valuable but I just don't agree with this way of shouting requests and not following up on them. I'd rather help someone else first who is really interested in solving his own requests.
Re: Starting threads inside class
On 02/23/2016 07:31 AM, Josh wrote:
> My goal with the code below is to eventually have my main communicate
> with Foo and Bar classes listening for packets on a different
> address/port, each in a separate thread.
The main issue is that in D all data is thread-local by-default. main()
cannot create objects and then implicitly give access to those objects
from other threads.
> the most I would be doing from outside is accessing the Tid in order
> to send packets from my main.
Even that's not needed because spawn() returns the Tid. And you don't
need to pass ownerTid, it is already available to child threads.
Options:
a) spawn() a thread by passing necessary data for it to create a Foo.
(Preferred.)
b) In case main() needs to have access to the objects, construct objects
as shared(Foo) and pass references to threads.
Here is the code with option a:
import std.socket;
import std.concurrency;
void daemon()
{
auto f = new Foo();
f.setup();
f.initialise();
long rxSize = -1;
while (true)
{
rxSize = f.mysock.receive(f.buffer);
if (rxSize == 0)
{
break;
}
f.packetHandler();
}
f.closeConnection();
}
class Foo
{
private string address = "127.0.0.1";
private ushort port = 5;
private ubyte[256] buffer;
private TcpSocket mysock;
Tid listenerd;
void setup()
{
mysock = new TcpSocket();
mysock.blocking = true;
try
{
mysock.connect(new InternetAddress(address, port));
}
catch (SocketOSException e)
{
}
}
void initialise()
{
// send init packet
}
void closeConnection()
{
// send close packet
}
void packetHandler()
{
// do something with buffer
}
}
void main() {
auto listenerd = spawn(&daemon);
}
Ali
Re: vk.xml
On Sunday, 21 February 2016 at 15:18:44 UTC, ZombineDev wrote: On Sunday, 21 February 2016 at 12:52:33 UTC, Nicholas Wilson wrote: [...] I'm glad to see more people looking to create a D binding from vk.xml! I was also working on this (http://forum.dlang.org/post/ygylvtuwwiwyqtcnl...@forum.dlang.org), unfortunately I won't be able to continue my work until early March, so I hope you'll do a good job in the mean time ;) [...] AA's are nice in theory but the non-deterministic nature of their order of iteration is painful...
Re: Simple performance question from a newcomer
On Tuesday, 23 February 2016 at 20:03:30 UTC, dextorious wrote: For instance, I am still not sure how to make it pass the -O5 switch to the LDC2 compiler and the impression I got from the documentation is that explicit manual switches can only be supplied for the DMD compiler. If you're referring to this: "Additional flags passed to the D compiler - note that these flags are usually specific to the compiler in use, but a set of flags is automatically translated from DMD to the selected compiler" My take is that a specific set of flags are automatically translated (so you don't need to make a separate dflags entry for each compiler you support if you only use those flags), but you can pass any compiler-specific flags you need.
Re: vk.xml
On Wednesday, 24 February 2016 at 00:50:40 UTC, Nicholas Wilson wrote: AA's are nice in theory but the non-deterministic nature of their order of iteration is painful... An ordered map as the default AA implementation would be worse. Most use cases for a hash map don't need ordering. Perhaps we'll have one in std.container at some point, but as it stands I'm unaware of any implementations out there. Neither the EMSI containers [1] nor dcollections [2] has one that I can see. [1] https://github.com/economicmodeling/containers/tree/master/src/containers [2] https://github.com/schveiguy/dcollections/tree/master/dcollections
Re: Installing DUB on OSX
On Saturday, 20 February 2016 at 12:01:04 UTC, Jacob Carlborg wrote: On 2016-02-20 04:21, Joel wrote: How do you do symbolic links? ln -s Replace and with the appropriate paths. I get this: Joels-MacBook-Pro:bin joelcnz$ ln -s /usr/local/bin/dub /usr/bin ln: /usr/bin/dub: Operation not permitted Joels-MacBook-Pro:bin joelcnz$
Re: Installing DUB on OSX
On 2016-02-24 07:49, Joel wrote: I get this: Joels-MacBook-Pro:bin joelcnz$ ln -s /usr/local/bin/dub /usr/bin ln: /usr/bin/dub: Operation not permitted Joels-MacBook-Pro:bin joelcnz$ If you have OS X 10.10.x or lower you can prefix the command with "sudo". If you have OS X 10.11 or later you cannot write to /usr/bin. -- /Jacob Carlborg
