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.
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
Is there any loss in performance instantiating an interface
variable as a final class implementing only that interface, as
opposed to a class variable?
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
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.
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.
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
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
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
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.
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
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 {}
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
import std.algorithm;
import std.concurrency;
void main() {
Tid[] tids = [];
Tid tid = thisTid;
tids ~= tid;
tids.remove(tid);
}
Why does this not compile?
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
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.
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)
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(...);
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
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
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
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.
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'.
If you like Parser Expression Grammar there's Pegged:
https://github.com/PhilippeSigaud/Pegged
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
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
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
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 *
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
Never mind, found it. I searched for parameters and found it in
http://dlang.org/declaration.html#DeclaratorSuffix
Thanks. :3
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.
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
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?
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
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
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
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.
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
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
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
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:
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
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.
43 matches
Mail list logo
