On Friday, November 15, 2013 23:39:38 Jacek Furmankiewicz wrote:
> Many other languages are starting to frown on returning null
> values from methods (due to NullPointerException risks, etc) and
> wrapping them instead in an Optional like in
>
> Scala:
> http://blog.danielwellman.com/2008/03/using
Thanks for the book! I printed it, all 673 pages of it. Immense
work you have there.
On 11/15/2013 02:35 PM, Jacek Furmankiewicz wrote:
> "Programming in D" PDF and he did not show this in his initial chapter on
> Strings.
Sorry about that. :)
As I was targeting novices to programming, I tried to give as much as
needed but as little as possible, so that the reader would not be
Justin Whear:
No, Nullable adds a potential null state to value types, e.g.
it allows you to null an int.
In std.typecons there is another version of Nullable, that uses a
state as "null". So you can use it as nullable class reference.
Is that good enough for the OP?
Bye,
bearophile
On Fri, 15 Nov 2013 23:41:38 +0100, Brad Anderson wrote:
> On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz wrote:
>> Many other languages are starting to frown on returning null values
>> from methods (due to NullPointerException risks, etc)
>> and wrapping them instead in an Opti
On Friday, 15 November 2013 at 22:35:48 UTC, Jacek Furmankiewicz
wrote:
I am learning D by going through Ali Cehreli's otherwise
excellent "Programming in D" PDF and he did not show this in
his initial chapter on Strings.
Well, Appender is not string specific.
D feels like being in a differen
On Friday, 15 November 2013 at 22:41:40 UTC, Brad Anderson wrote:
On Friday, 15 November 2013 at 22:39:40 UTC, Jacek
Furmankiewicz wrote:
Many other languages are starting to frown on returning null
values from methods (due to NullPointerException risks, etc)
and wrapping them instead in an Opt
Thanks! std.typecons definitely looks like something I need to
dig into.
On Friday, 15 November 2013 at 22:39:40 UTC, Jacek Furmankiewicz
wrote:
Many other languages are starting to frown on returning null
values from methods (due to NullPointerException risks, etc)
and wrapping them instead in an Optional like in
Scala:
http://blog.danielwellman.com/2008/03/using-
Thank you all.
I am learning D by going through Ali Cehreli's otherwise
excellent "Programming in D" PDF and he did not show this in his
initial chapter on Strings.
Many other languages are starting to frown on returning null
values from methods (due to NullPointerException risks, etc) and
wrapping them instead in an Optional like in
Scala:
http://blog.danielwellman.com/2008/03/using-scalas-op.html
Google Guava for Java: (now rolled into the base JDK for
On Fri, 15 Nov 2013 22:30:35 +, Justin Whear wrote:
> std.array has an Appender type that can be used to build up a string (or
> any other array type) efficiently.
Oh, and if you have an idea of how large the result might grow, be sure
to use the reserve() method on the appender.
On Friday, 15 November 2013 at 22:26:20 UTC, Jacek Furmankiewicz
wrote:
Since D strings are immutable (like in most other languages),
string concatenation is usually pretty inefficient due to the
need to create a new copy of the string every time.
I presume string concatenation using the typic
On Fri, 15 Nov 2013 23:26:19 +0100, Jacek Furmankiewicz wrote:
> Since D strings are immutable (like in most other languages), string
> concatenation is usually pretty inefficient due to the need to create a
> new copy of the string every time.
>
> I presume string concatenation using the typical
Sohow does Facebook handle it with their new D code?
No GC at all, explicit memory management?
Since D strings are immutable (like in most other languages),
string concatenation is usually pretty inefficient due to the
need to create a new copy of the string every time.
I presume string concatenation using the typical array syntax can
be optimized by the compiler to do all of this in on
On Thursday, 14 November 2013 at 23:10:58 UTC, Jacek
Furmankiewicz wrote:
While looking a D, I am just trying to focus on the parts which
I know would be a showstopper for us on day one...and this
particular issue is it.
Yes, I also think for long-running memory-hungry server-stuff the
curren
On Friday, 15 November 2013 at 14:01:36 UTC, Chris Cain wrote:
On Friday, 15 November 2013 at 13:32:38 UTC, Mikko Ronkainen
wrote:
Ok, thanks! That linked list cache thrashing was just the
thing I knew that I don't know :)
Let's say I just use dynamic array and grow it when adding new
particl
Am Fri, 15 Nov 2013 21:56:15 +0900
schrieb Mike Parker :
> On 11/15/2013 9:19 PM, Mikko Ronkainen wrote:
> >
> > If relevant, doubly-linked might work better? dcollections LinkList, or
> > maybe DList? I'm asking mostly because I'd like the container to avoid
> > memory allocations while in use.
>
I thrid compiling thrift 0.9.1 from github with d support, but
there's a bug in the makefile it seems.
$(addprefix.log: $(addprefix
@p='$(addprefix'; \
b='$(addprefix'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs
On Thursday, 14 November 2013 at 17:36:09 UTC, Jacek
Furmankiewicz wrote:
Could anyone point me to what would be the closest D
equivalents (maybe in an external library if not part of
Phobos) so we can playing around with them?
Much appreciated
Jacek
In such cases the easiest route is to fin
Thank you Russell for the explanation.
Always a chance to learn something new.
On Fri, 2013-11-15 at 20:10 +0100, Jacek Furmankiewicz wrote:
> if I recall from the initial Go discussion, the Go folks were
> saying that for close to realtime SLAs the goroutine/channel
> approach may have some scalability limits...which is why they
> started recommending the RW mutex approac
On 11/15/2013 10:37 AM, Ali Çehreli wrote:
> > this(this) {
> > a = a.dup;
>
> That line can work only if a is mutable. The trouble is, the type of a
> is const(int[]) there.
I lied! :) The type of a is int[] in there. The actual trouble is, to be
able to start executing
if I recall from the initial Go discussion, the Go folks were
saying that for close to realtime SLAs the goroutine/channel
approach may have some scalability limits...which is why they
started recommending the RW mutex approach in the end.
Now, that was a few months ago, since then Go 1.1 (and
On Friday, 15 November 2013 at 17:46:41 UTC, Russel Winder wrote:
If D programmers are being told to use locks in applications
code, then
the D programming model and library are failing. Or the advice
is
wrong ;-)
I don't really buy it. It is good from simplicity/safety point of
view (just u
On Fri, 2013-11-15 at 18:55 +0100, Jacek Furmankiewicz wrote:
> Yes, that is what they say in Go...but it doesn't scale either.
> :-)
I don't follow. CSP scales very well and Go implements CSP. (Well an
updated version from Hoare's 1978 CSP.)
> I had the exact same discussion on the Go forums a
The short answer to the question in the subject line is because D does
not have copy constructors.
On 11/15/2013 07:12 AM, Atila Neves wrote:
> private struct DummyStruct {
> int[] a;
>
> this(this) {
> a = a.dup;
That line can work only if a is mutable. The
On Fri, 2013-11-15 at 19:05 +0100, ilya-stromberg wrote:
> On Friday, 15 November 2013 at 17:46:41 UTC, Russel Winder wrote:
> > If D programmers are being told to use locks in applications
> > code, then
> > the D programming model and library are failing. Or the advice
> > is
> > wrong ;-)
>
>
On Friday, 15 November 2013 at 18:16:17 UTC, Jacek Furmankiewicz
wrote:
taskPool looks like the closest equivalent in D that I could
find.
Yes, that's sad truth: if you want to use D, be ready make
something yourself.
BTW, why did you decide to migrate to D? Any problems with Java?
No, we didn't decide to migrate to D. Java is working out fine
for us.
I am however always interested in what is out there, 'cause you
never know if there may not be a better solution.
And from what I've seen so far I really like D in terms of pure
language features.
Go is cool too, but it
On Friday, 15 November 2013 at 17:46:41 UTC, Russel Winder wrote:
The trend in the JVM-verse is very much "if you use
synchronized or an
explicit lock, and you are not creating a core library data
structure,
you are doing it wrong". The background is that the whole
purpose of a
lock it to contr
On Friday, 15 November 2013 at 17:46:41 UTC, Russel Winder wrote:
If D programmers are being told to use locks in applications
code, then
the D programming model and library are failing. Or the advice
is
wrong ;-)
It's possible to implement lock-free data structures in D, you
can use core.at
Yes, that is what they say in Go...but it doesn't scale either.
:-)
I had the exact same discussion on the Go forums a while back and
the conclusion was basically the same...roll your own maps with
RW locks:
https://groups.google.com/forum/?fromgroups#!searchin/golang-nuts/furmankiewicz/gola
On Fri, 2013-11-15 at 18:03 +0100, ilya-stromberg wrote:
> On Friday, 15 November 2013 at 16:36:56 UTC, Jacek Furmankiewicz
> wrote:
> > How can you achieve lock-free reads with the synchronized MyMap
> > approach?
>
> In this case you can use Readers-writer lock
> http://en.wikipedia.org/wiki/R
On Friday, 15 November 2013 at 17:09:54 UTC, Dicebot wrote:
On Friday, 15 November 2013 at 17:03:15 UTC, ilya-stromberg
wrote:
I don't know any D implementation of Readers-writer lock, but
you can ask this question - maybe it already exist.
http://dlang.org/phobos/core_sync_rwmutex.html
Than
On Friday, 15 November 2013 at 17:03:15 UTC, ilya-stromberg wrote:
I don't know any D implementation of Readers-writer lock, but
you can ask this question - maybe it already exist.
http://dlang.org/phobos/core_sync_rwmutex.html
On Friday, 15 November 2013 at 16:36:56 UTC, Jacek Furmankiewicz
wrote:
How can you achieve lock-free reads with the synchronized MyMap
approach?
In this case you can use Readers-writer lock
http://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock
It allows multiple reads and single write. I t
So, if you add a read() method to MyMap for those threads, would
that be synchronized as well?
That is what we would not want due performance impact.
How can you achieve lock-free reads with the synchronized MyMap
approach?
On Friday, 15 November 2013 at 15:21:59 UTC, Jacek Furmankiewicz
wrote:
So what happens when the "write" operation is doing
map[1] = map[1].editData(5);
and at the same time 50 threads are simultaneously reading the
value in map[1]?.
Is that reassignment operation thread safe?
Or would I ge
Thank you for the quick response, that is great news.
Cheers
Jacek
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz
wrote:
One of the nice features of Go is that when you compile an app,
it pulls in ALL the dependencies (i.e. the full SDK + all
libraries your app depends on) and generates a single binary
(around 2 MB for a Hello World app).
T
On Friday, 15 November 2013 at 15:12:23 UTC, Alexandr Druzhinin
wrote:
15.11.2013 22:09, Adam D. Ruppe пишет:
You could make it work like this:
auto slice3 = array[
slice1.length + (slice1.ptr - array.ptr)
..
(slice2.ptr - array.ptr)];
Si
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz
wrote:
One of the nice features of Go is that when you compile an app,
it pulls in ALL the dependencies (i.e. the full SDK + all
libraries your app depends on) and generates a single binary
(around 2 MB for a Hello World app).
T
On Friday, 15 November 2013 at 14:01:36 UTC, Chris Cain wrote:
By default (using the default GC and everything), D does not
reallocate a dynamic array every time you change the length
(even increasing it), so this will still be okay with
allocations.
Not exactly so. If you decrease the lengt
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz
wrote:
One of the nice features of Go is that when you compile an app,
it pulls in ALL the dependencies (i.e. the full SDK + all
libraries your app depends on) and generates a single binary
(around 2 MB for a Hello World app).
T
One of the nice features of Go is that when you compile an app,
it pulls in ALL the dependencies (i.e. the full SDK + all
libraries your app depends on) and generates a single binary
(around 2 MB for a Hello World app).
This is extremely useful for deployment purposes, since it is so
straight
On Friday, 15 November 2013 at 07:42:22 UTC, ilya-stromberg wrote:
On Thursday, 14 November 2013 at 22:12:10 UTC, Jacek
Furmankiewicz wrote:
On Thursday, 14 November 2013 at 21:36:46 UTC, ilya-stromberg
wrote:
On Thursday, 14 November 2013 at 21:31:52 UTC, Jacek
Furmankiewicz wrote:
How often d
On Friday, 15 November 2013 at 14:08:20 UTC, bearophile wrote:
The situation is a little more complex, there is a capacity
field that I think is kept in a cold place of the array, it's
also cached, but only if you append to just one array, etc.
An alternative might be hold an array and manage
15.11.2013 22:13, bearophile пишет:
Alexandr Druzhinin:
A simple solution is to keep two indexes, and use them to find the
slices when you need them.
I did it the first. But then I decided to make it more D-ish and
stumbled upon the issue. Wasn't it wrong decision and would be better to
stay w
Alexandr Druzhinin:
I'd like to get slice that's consist of begining one other
slice and end of yet another slice (all slices belong to the
same array of course). Is it possible? With iterators it's
simple, but I can't manage do it with slices.
http://dpaste.dzfl.pl/443cd4a1
A simple soluti
15.11.2013 22:09, Adam D. Ruppe пишет:
You could make it work like this:
auto slice3 = array[
slice1.length + (slice1.ptr - array.ptr)
..
(slice2.ptr - array.ptr)];
Since the slices all start into array somewhere, subtracting the
point
private struct DummyStruct {
int[] a;
this(this) {
a = a.dup;
}
}
void main() {
const dummy1 = DummyStruct();
DummyStruct dummy2 = dummy1;
}
struct_copy.d(12): Error: conversion error from
const(DummyStruct) to DummyStruc
You could make it work like this:
auto slice3 = array[
slice1.length + (slice1.ptr - array.ptr)
..
(slice2.ptr - array.ptr)];
Since the slices all start into array somewhere, subtracting the
pointers gives their start index.
I'd like to get slice that's consist of begining one other slice and end
of yet another slice (all slices belong to the same array of course). Is
it possible? With iterators it's simple, but I can't manage do it with
slices.
http://dpaste.dzfl.pl/443cd4a1
Go to bugzilla.
Chris Cain:
Instead of having a "dead flag", you could swap (
http://dlang.org/phobos/std_algorithm.html#swap ) the dying
particle with the last particle in the list and then decrement
the list's length.
If the array is long you are accessing a cold part of it to swap
with the end.
By de
On Friday, 15 November 2013 at 13:32:38 UTC, Mikko Ronkainen
wrote:
Ok, thanks! That linked list cache thrashing was just the thing
I knew that I don't know :)
Let's say I just use dynamic array and grow it when adding new
particles to the system, and when particles die, just set their
dead f
Mikko Ronkainen:
Let's say I just use dynamic array and grow it when adding new
particles to the system, and when particles die, just set their
dead flag on. This means that, when adding a new particle, I
need to scan the array first for possible dead particles that
can be reused. Is there so
Ok, thanks! That linked list cache thrashing was just the thing I
knew that I don't know :)
Let's say I just use dynamic array and grow it when adding new
particles to the system, and when particles die, just set their
dead flag on. This means that, when adding a new particle, I need
to scan
On Friday, 15 November 2013 at 11:52:44 UTC, Mikko Ronkainen
wrote:
What would be the best data structure for handling particles in
a particle system in D2?
Here's some thoughts:
Particles are simple structs.
Two lists, one for alive particles, one for dead ones.
Memory allocations should be a
On 11/15/2013 9:19 PM, Mikko Ronkainen wrote:
If relevant, doubly-linked might work better? dcollections LinkList, or
maybe DList? I'm asking mostly because I'd like the container to avoid
memory allocations while in use.
For a particle system, I would avoid lists. A list of particles needs to
Use just one list with a flag in the particle to see whether the
particle is alive or dead, saves swapping between lists and you
can use a simple array for fast access.
Yes, simplicity, that's a good idea :) I was just wondering how
much time would be saved if just iterating over the active
pa
On Friday, 15 November 2013 at 11:52:44 UTC, Mikko Ronkainen
wrote:
What would be the best data structure for handling particles in
a particle system in D2?
Here's some thoughts:
Particles are simple structs.
Two lists, one for alive particles, one for dead ones.
Memory allocations should be a
What would be the best data structure for handling particles in a
particle system in D2?
Here's some thoughts:
Particles are simple structs.
Two lists, one for alive particles, one for dead ones.
Memory allocations should be avoided, preallocate everything, no
allocations when moving between l
15-Nov-2013 03:35, Charles Hixson пишет:
On 11/14/2013 01:36 PM, ilya-stromberg wrote:
On Thursday, 14 November 2013 at 21:31:52 UTC, Jacek Furmankiewicz wrote:
hashmap per thread is not an option. The cache may be a few GBs of
data, there is no way we can duplicate that data per thread.
Not t
This code (http://dpaste.dzfl.pl/4c499303) causes strange error
description:
class Bar had semantic errors when compiling
On win32 it causes AV:
Error: class Bar had semantic errors when compiling
Assertion failure: '0' on line 1215 in file 'glue.c'
On Friday, 15 November 2013 at 09:19:04 UTC, Orfeo wrote:
I have found in the module
https://github.com/NCrashed/serial-port/blob/master/source/serial/device.d
this function:
void write(const(void[]) arr) {
...
What exactly is void[]? An array of pointers? An array of
"an
I have found in the module
https://github.com/NCrashed/serial-port/blob/master/source/serial/device.d
this function:
void write(const(void[]) arr) {
...
What exactly is void[]? An array of pointers? An array of
"anything"?
Thank you
On 2013-11-15 05:30, Jonathan M Davis wrote:
Deimos is specifically for bindings to C libraries and _not_ for D-ified
wrappers. And that's the stance that Walter has taken when it's come up. But
with dub and code.dlang.org, it should be simple enough to put a D-ified
wrapper in a place where fol
On 2013-11-14 23:17, Oleg B wrote:
Oh sorry i mean
interface A {
void funcA();
}
class B : A {
final void funcA() { writeln( "B.funcA()" ); }
}
class C : B {
}
we can't change anything in class B
I would have moved "final void funcA()" to a template and mixin it in
both B and C, but
On 2013-11-14 22:02, TheFlyingFiddle wrote:
After looking at the DIP some more i can see that my suggestion
implementation does not make any sense (and i missed some of the
syntax). If it can be done with AST's i don't have a sugestion for it.
If you have the an example like:
int a = foo.baz("
On 2013-11-14 21:39, TheFlyingFiddle wrote:
Might this be something you could solve using the DIP50 AST macros?
Possibly, if the context parameter provides enough information about
where the macro is used.
--
/Jacob Carlborg
On Thu, Nov 14, 2013 at 5:02 PM, bearophile wrote:
> Ali Çehreli:
>
>
> > When is an enum *better* than a normal (static
>> const/immutable) constant?
>>
>> Good question. :)
>>
>
> When you can or want to compute something at compile-time, when you need
> values to feed to templates, etc.
>
>
bu
On 2013-11-14 14:49, Andrea Fontana wrote:
BTW: you say "used like header files". You mean files that are not
"compiled" but "imported"?
Yes. When you have a pre-compiled library and need to declarations.
--
/Jacob Carlborg
75 matches
Mail list logo
