Re: Socket: Detect connection close
Also, SocketStream: http://dlang.org/phobos/std_socketstream.html Warning: This module is considered out-dated and not up to Phobos' current standards. It will remain until we have a suitable replacement, but be aware that it will not remain long term. I wouldn't write any code using it.
Re: Socket: Detect connection close
In Java, the only way to know is to attempt to send something. I presume it's limited that way because the OS's don't provide more info, or because TCP itself does not tell if a connection has closed unless something is sent. I could be wrong, but all my network code in other languages rely on sending stuff to register a closed connection. For connections that are open for a very long time with low throughput I send small packages regularly just to be sure it's still open.
Final class and interface
Is there any loss in performance instantiating an interface variable as a final class implementing only that interface, as opposed to a class variable?
Re: Question about CPU caches and D context pointers
On Tuesday, 18 February 2014 at 08:11:04 UTC, Dicebot wrote:
None of your buffers are on stack in both examples. As those
are dynamic arrays you only get pointer + length as value and
data itself resides on heap in some unknown location.
That.
struct S {}
class C {}
S[] s1; // fat pointer to an array of structs
S[2] s2; // array of two structs, plus a length?
C[] c1; // fat pointer to an array of pointers
C[2] c2; // array of two pointers, plus a length?
I tested some prime sieves both in C++ and D. They worked fastest
with dynamic arrays with a size matching the L1 cache. I presume
the instructions are located elsewhere in the CPU.
Re: Strange result with nextUp for reals
If you swap the line to writefln(nextUp of %a is %a, 1.0L, 1.0L.nextUp()); you get the same result as the second case.
Re: Avoiding allocation in broadcast server
On Saturday, 8 February 2014 at 17:49:24 UTC, Kagamin wrote: Client reads from the client? And what does the server? Server reads from client and broadcasts to clients.
Re: Avoiding allocation in broadcast server
On Saturday, 8 February 2014 at 11:15:31 UTC, Jakob Ovrum wrote: However, if this one allocation really is a problem, you might want to implement a simple free-list kind of allocator to allocate from. Say, pre-allocate N string buffers with M length and treat them as a free-list. If the free-list is full (all N buffers are being processed), wait until there is a free space before reading another datagram from the socket. This makes program performance deterministic depending on the worst-case complexity achieved when allocating from the free-list. GC cycles are never run if the program doesn't allocates GC memory. Meh, it sounds rather ghastly. Perhaps if I periodically call GC.collect instead I can keep it down to a manageable delay.
Re: 3d vector struct
On Friday, 7 February 2014 at 10:50:49 UTC, Stanislav Blinov wrote: I know. I also know that people making games are obsessed with performance :) And, where there's 3d vector, there would also be 4d vector and matrices... Wouldn't it make more sense to aim for a float SIMD implementation instead then? :P
Avoiding allocation in broadcast server
Suppose I have a multi client broadcast server. One client sends a string, every client receives it. The client read thread reads the input from the client into a static byte array, makes a copy and casts it to a string, and passes it to the host thread, which relays it to all client write threads. This is done with message passing. Is there a way it can be done without allocation? That is, currently I use .idup on the static array.
Re: Interfaces allow member definitions?
Compiling with DMD 2.064, I am NOT able to get any function in interfaces accepted unless they are final. This means you cannot provide default behavior in the interface, at least not in the ways shown above.
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: Keywords: How to trick the compiler?
On Tuesday, 28 January 2014 at 12:57:02 UTC, Andrej Mitrovic wrote: body is probably the most frequent issue I run into when porting C/C++ code to D. I really wonder whether the rule could be relaxed a little bit. All my input and output streams in Java are called in and out. x.x Reminds me of max and min in competitive programming in C++.
Algorithm remove Tid
import std.algorithm;
import std.concurrency;
void main() {
Tid[] tids = [];
Tid tid = thisTid;
tids ~= tid;
tids.remove(tid);
}
Why does this not compile?
Re: Algorithm remove Tid
On Wednesday, 22 January 2014 at 13:16:18 UTC, monarch_dodra wrote: Because remove takes an offset as an argument, not an element. To remove an element, I *think* you do it this way: tids = tids.remove!(a=a == tid)(); Thanks a lot. I was trying to get that part to work, but I had a hard time realizing that = was a lambda and not a =. x.x
Re: Algorithm remove Tid
On Wednesday, 22 January 2014 at 13:51:51 UTC, bearophile wrote: Casper Færgemand: To remove an element, I *think* you do it this way: tids = tids.remove!(a=a == tid)(); is that removing only 0 or 1 items? Bye, bearophile It removes all items that match the tid.
Re: Create mixins from a list of strings
On Saturday, 11 January 2014 at 07:50:51 UTC, Jakob Ovrum wrote:
Your problem is probably better solved without string mixins,
but we'd probably need to see some code or more elaboration to
accurately suggest a solution.
enum semanticArray = [test];
mixin(`T ` ~ semanticArray[0] ~ `(T)(T t) {
t.name ~= ` ~ semanticArray[0] ~ `;
return t;
}`);
This will mixin a single templated function named test, which
changes an AST node's name to whatever it was concatenated with
test. I want this to happen automatically for any length of
semanticArray.
Re: Create mixins from a list of strings
On Saturday, 11 January 2014 at 09:17:34 UTC, Philippe Sigaud wrote: case Gramm.Expr: return foo(t); case Gramm.FunctionCall: return foo(t); case Gramm.Declaration: return foo(t); default: throw new Exception(...); I can't do this since there will be multiple rules with the same name that require different treatment. The reason I want to use semantic actions is that I don't want to push an already heavy grammar into double or triple size just to name specific rules in a certain way. Semantic actions take up very little space and fit nicely into the syntax. or do it with a template, holding function names as aliases: alias actor = dispatcher!(foo, bar, baz); I have no idea what you mean. :D
Re: Is it true that dub compiles everything in the source dir whether it's imported or not?
On Saturday, 11 January 2014 at 13:46:51 UTC, Gary Willoughby wrote: I've seen this but the problem is not with my project but a dependency. I only include two files from the dependency but when my project is compiled the entire source of the dependency is compiled and produces the error. Is that by any chance also why compiling with Dub is slower than just with Dmd? If so, it would be nice to not do for non-release builds.
Re: Create mixins from a list of strings
On Saturday, 11 January 2014 at 16:07:30 UTC, Philippe Sigaud
wrote:
I'm a bit leery of putting D call syntax into semantic actions,
because it'll also explode the Pegged grammar size (I'm fairly
sure
I'd have to pull in a big part of D if I want to get function
calls
right). That's one feature I wanted at one time, but I'm not
sure it's
a good idea.
Yes, and I would not be able to argue this is the definite way to
handle things anyway. It's a try at type checking with little
regard to efficiency. I'm just happy it works with Timon Gehr's
extremely simple solution. :3
On Saturday, 11 January 2014 at 20:52:15 UTC, Timon Gehr wrote:
import std.string, std.algorithm;
enum semanticArray = [derp, lala];
mixin(semanticArray.map!(a=`T `~a~`(T)(T t) {
t.name ~= `~a~`;
return t;
}`).join());
Here, have a heart. 3
Create mixins from a list of strings
Have: enum (or is immutable array better?) array = [derp, lala]; Want: mixin(some syntax ~ array[0]); mixin(some syntax ~ array[1]); Basically, to specify a number of similar functions based on a list of strings. Why? Pegged's semantic actions allows only calling a function by name, not specifying parameters. I could probably ask for an extension, but if there's a cool template or whatever way to do this, it would be a lot nicer. :3
Re: How do I choose the correct primative?
On Wednesday, 1 January 2014 at 04:17:30 UTC, Jake Thomas wrote: snip Are you looking for something like int_fast32_t and the likes from Boost? If you don't care terribly much for when your numbers overflow, then as others suggested, size_t and pttwhatever work fine.
Re: A little DUB question
On Tuesday, 31 December 2013 at 10:42:35 UTC, ponce wrote: Looks like a bug. In the meantime you can compile combined. $ dub --build=release --combined Error executing command run: Failed to find a package named '--combined'.
Re: lexer/parser library for D
If you like Parser Expression Grammar there's Pegged: https://github.com/PhilippeSigaud/Pegged
Re: scope(faliure) flow control.
On Saturday, 28 December 2013 at 20:31:14 UTC, TheFlyingFiddle
wrote:
int foo()
{
scope(failure) return 22;
throw new Exception(E);
}
unittest
{
assert(foo() == 22);
}
Is this defined behavior? At least in x64 dmd the exception is
swallowed and the assert evaluates to true.
In any case what should happen? Should the method return or
should the exception be propagated up the callstack?
It's rewritten as follows:
int foo()
{
try {
throw new Exception(E);
} catch (Exception e) { // or whatever the D syntax is, I
never used it
return 22;
}
}
So yes, it's intended. scope(exit) uses finally instead of catch.
Compile time getTimes
I'm writing a compiler that uses Pegged for parsing D code. Pegged is fed a string with a special grammar syntax and changes it into templated D code, which is in turn mixed in. Even with just a small subset of D, Pegged currently produces 4000 lines of dense code, and it consumes enough time for it to be bothersome on every change, especially changes to the compiler that don't touch the grammar. I wrote some simple code that uses datetime's getTimes to compare modification time. If grammar.d was modified more recently than precompiled_grammar.d, grammar.d will be churned through the machine once more and the result overwrite the precompiled_grammar.d. However, it works only on runtime. I moved stuff around and used an enum for the mixin, forcing compile time function execution, but it whines about getTimes being unusable: Error: GetFileAttributesExW cannot be interpreted at compile time, because it has no available source code Is there some hack available? Currently I run the compiler twice to use the past precompiled stuff or run it once and accept that it's slow. And this is D, so I really feel I shouldn't have to. =3
Re: Function declaration
On Wednesday, 25 December 2013 at 08:34:27 UTC, Philippe Sigaud wrote: On Wednesday, December 25, 2013, quot;Casper Færgemand\quot; lt;shortt...@hotmail.comgt;quot;@puremagic.com wrote: Never mind, found it. I searched for parameters and found it in http://dlang.org/declaration.html#DeclaratorSuffix Thanks. :3 I had a lot of problems with function declarations when testing the example D grammar. If you find any mistake in the provided D grammar, could you push it as an issue in Pegged? Yes, certainly.
Re: Function declaration
From http://dlang.org/declaration.html#Parameter Parameter: InOutopt BasicType Declarator InOutopt BasicType Declarator ... InOutopt BasicType Declarator = DefaultInitializerExpression InOutopt Type InOutopt Type ... How do I add a declarator to a parameter like char * format? I altered the language specification to add a InOutopt Type Declarator, but is there another way? The specification overall is really good, but I've found a few missing things elsewhere, and I'm wondering if it really is missing or I'm missing the point. :P I can't see any way to add a parameter name to something of type Type.
Re: Function declaration
On Wednesday, 25 December 2013 at 21:23:23 UTC, Philippe Sigaud wrote: I'll consider that as a D grammar question, and not a Pegged-specific question, since Pegged just uses a copy of the D site grammar :-) Thank you regardless. I'll be sure to submit some issues once we're a bit further down the road. Error handling is what has displeased me the most so far, with only a single test case ever displaying something useful. I'm not sure what the solution should be though, perhaps the matches that munched the most tokens before failing? Also, it should be possible to detect non-munching cycles aka. left recursion without too much extra compile time. It's funny because it's fine on compile time, but instant death at runtime. I'll post some of that once we're further. On Wednesday, 25 December 2013 at 22:28:06 UTC, Timon Gehr wrote: The following is a parse tree for char* format: snip Oooh, I missed that. I didn't think it possible one would dissect it like that. In my mind it would make more sense to keep char and * together, since it's a type of its own. Interesting. And weird. I consider the grammar specification (as well as some details of what is valid syntax) to be quite inelegant, unnecessarily repetitive and inconvenient for parser generators, but I am not sure if a clean-up would be welcome. I'm not sure. I haven't imported too much yet, but the only thing I've had to work around was left recursion in some arithmetic expressions (add and mul I believe). It's complicated for sure, but the language specification has survived nearly intact. My only past experience is the toy language Tiger made for education and stories I've been told of normal language specifications being really awful. So some copy paste is nice for a change. I'd still like a look at a clean grammar if anyone has one around.
Re: Function declaration
Never mind, found it. I searched for parameters and found it in http://dlang.org/declaration.html#DeclaratorSuffix Thanks. :3
Function declaration
Where is the function declaration in the language specification?
I'm trying to parse a simple void main() {} with Pegged, but I
can't figure our which declarations contain the function
declaration. I tried with Pegged's example D grammar, but it's
unwilling to parse said program.
Language subset for printing
How big of a subset of D would a compiler need to use writeln? I managed to track stdout to file. At the very least it seems to require templates and type tuples. Or will everything in stdio and file be needed, and perhaps thing in other files as well? Is there possibly an easier way to write to stdout? Calling printf in some C code perhaps? We'd like to start out with as small a subset as possible, but looking at return codes only is not particularly appealing. :3
Re: Language subset for printing
On Saturday, 21 December 2013 at 01:18:55 UTC, Adam D. Ruppe
wrote:
Just call printf in D!
import core.stdc.stdio;
void main() {
printf(hello world!\n);
}
int printf(in char* format, ...);
I take it that means it's intrinsic?
Re: Language subset for printing
On Saturday, 21 December 2013 at 01:47:07 UTC, Adam D. Ruppe wrote: snip Well that answered more than my question. That's pretty useful actually. Having skimmed core.stdc.stdio.d now, it's seems pretty manageable to parse, so we'll go with that. Thankies. :3
Re: Windows 64
On Monday, 7 October 2013 at 07:03:39 UTC, Rainer Schuetze wrote: The linker does not find the import libraries from the Windows SDK, so it hits the 32-bit libraries that come with dmd. The released sc.ini does not work with VS2012+ or a Windows SDK 8, you should add the following lines to it: [Environment64] LIB=%@P%\..\lib;%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\win8\um\x64 ;; for some additional improvements PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE DFLAGS=%DFLAGS% -L/OPT:NOICF Thank you. I added the lines and I'm still getting the same 103 unresolved externals. Commenting out stuff in the file makes dmd throws other errors, so I'm sure I'm editing the correct sc.ini. Where are the correct libraries supposed to be exactly?
Re: Windows 64
On Monday, 7 October 2013 at 17:48:13 UTC, Rainer Schuetze wrote:
Maybe the WindowsSdkDir environment variable is not set in your
console. For the Windows 8 SDK, the standard location of the
x64 libraries is
c:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64
for the Windows 7 SDK or previous (replace the version):
c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\x64
so the entry with expanded environment variables on my system
using VS 2012 and Windows SDK 8 is:
LIB=%@P%\..\lib;c:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64;c:\Program Files (x86)\Windows
Kits\8.0\Lib\win8\um\x64
I don't think the quotes are necessary, but the original sc.ini
has them, too.
When I run %WindowsSdkDir% from the start menu I end up in the
v7.0A folder, so the path seems correct.
I have v7.0A, but there is no x64 folder in the Lib folder.
In fact, I get the same 103 unresolved dependencies even if I
change the name of the Lib folder to Lib2, so presumably I never
get that far in the linking that it reaches the directory?
What exactly does it need from WinSDK to link? Does it need
anything if the program is simply void main() {}?
Re: Windows 64
I have four folders in the SDK folder: v7.0A, v7.1, v8.0 and v8.0A. The latter three contain nothing but a few files, presumably installed by VS 11 or something else. I'm currently trying to install v7.1.
Re: Windows 64
A lot of deleted posts and a lot of stupid later, v7.1 SDK is apparently installed in Program Files and not Program Files (x86). Kinda obvious given the names of said folders, but whatever. x.x The x64 version does indeed have an x64 folder in the Lib folder. However, all that aside, still the same 103 unresolved externals.
Re: Windows 64
More searching suggests all the unresolved external symbols are found in the lib files in v7.1\Lib\x64\ I'm guessing the linker doesn't know this. Any easy way to tell it where to look? Does the linker have an include folder? I tried with -LPATH%WindowsSdkDir%\Lib\x64 as well as -L+C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\ShLwApi (one of the files mentioned in a search result), however they failed since D doesn't recognize spaces in paths. cannot open file '+C:\Program.obj Any clue on what I'm doing wrong? Any correct way to tell the linker where it can find stuff?
Re: Windows 64
Okay, it's definitely a problem with dmd passing something bad to
link. I was able to link it manually and the program was working
fine.
import std.stdio;
void main() {
writeln(Hello Linker!);
}
I ran dmd -m64 test.d. The usual errors were dumped in the
terminal. I then ran link test.obj @lala.txt, with lala.txt
containing the following:
C:\D\Tools\dmd2\windows\lib\phobos64.lib
C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64\LIBCMT.lib
C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64\oldnames.lib
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\x64\shell32.lib
C:\Program Files\Microsoft
SDKs\Windows\v7.1\Lib\x64\kernel32.lib
After adding the five lines one by one, the linking succeeded and
test.exe outputted Hello Linker!.
So, how do I not link it manually? It's sorta acceptable for
small things, but I want DDT and Eclipse to do it automatically.
Re: Windows 64
And I'm done. The problem was this: LIB=%@P%\..\lib;%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\x64 The lib folder linked first contains kernel32.lib and shell32.lib. Removing both made -m64 possible, but killed -m32. Changing it to this: LIB=%VCINSTALLDIR%\lib\amd64;%WindowsSdkDir%\Lib\x64;%@P%\..\lib solved everything. Now the dmd lib is checked last, when the real kernel32 and shell32 have already been found. Well that only took half a year. ~~ Thanks for the help.
Windows 64
Hey, I've been trying for a while to compile 64 bit programs on a
Windows 7 platform. The setup is the following:
Version: 2.063.2
OS: Windows 7 64
Linked: VS 11 64 bit linker
sc.ini:
[Version]
version=7.51 Build 020
[Environment]
LIB=%@P%\..\lib;\dm\lib
DFLAGS=-I%@P%\..\..\src\phobos
-I%@P%\..\..\src\druntime\import
LINKCMD=%@P%\link.exe
LINKCMD64=%VCINSTALLDIR%\bin\amd64\link.exe
VCINSTALLDIR=%VCINSTALLDIR%
WindowsSdkDir=%WindowsSdkDir%
Environment variables are as follows:
VCINSTALLDIR: C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\
WindowsSdkDir: C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\
(I had initially forgot a \ at the end of the environment
variables)
On compiling the program void main() {} with -m64 -v in Eclipse
with DDT (same result for command line), I get this thrown back:
Build Commands:
-odbin
-ofbin\temp.exe
-Isrc
src\temp.d
-m64 -v
binaryC:\D\Tools\dmd2\windows\bin\dmd.exe
version v2.063.2
configC:\D\Tools\dmd2\windows\bin\sc.ini
parse temp
importall temp
import
object (C:\D\Tools\dmd2\windows\bin\..\..\src\druntime\import\object.di)
semantic temp
entry main src\temp.d
semantic2 temp
semantic3 temp
code temp
function D main
C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\amd64\link.exe /NOLOGO bin\temp /OUT:bin\temp.exe
/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\lib\amd64 /LIBPATH:C:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\lib\x64
C:\D\Tools\dmd2\windows\bin\..\lib\shell32.lib : warning LNK4003:
invalid library format; library ignored
C:\D\Tools\dmd2\windows\bin\..\lib\kernel32.lib : warning
LNK4003: invalid library format; library ignored
C:\D\Tools\dmd2\windows\bin\..\lib\shell32.lib : warning LNK4003:
invalid library format; library ignored
C:\D\Tools\dmd2\windows\bin\..\lib\kernel32.lib : warning
LNK4003: invalid library format; library ignored
phobos64.lib(dmain2_480_47b.obj) : error LNK2019: unresolved
external symbol IsDebuggerPresent referenced in function
_d_run_main
LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol
__imp_WideCharToMultiByte
...
bin\temp.exe : fatal error LNK1120: 103 unresolved externals
--- errorlevel 1120
I took the liberty of removing the mid section, since everything
was LIBCMT.lib and phobos64.lib things that were unresolved. Any
heads up on what I need to tinker with?
Re: Calculation differences between Debug and Release mode
The D book has a diagram that shows implicit conversions. All implicit conversions from integral types to floating point go to real, not double or float.
