On Sun, Jun 5, 2016 at 7:59 PM, Laeeth Isharc via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
>
> Have you seen any problems with multithreading in PyD? Ie have you any
> reasons to be concerned? Obviously on the python
> side there is the GIL, but I don't understand well enough any
> co
On Sun, Jun 5, 2016 at 9:35 AM, Laeeth Isharc via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> PyD is not a recent project. Nor is LuaD. Or bachmeier's work on R
> integration.
>
I've learned about the last one only from this thread, and the first two
are listed only on http://wiki.dl
On Sat, Jun 4, 2016 at 5:56 PM, bachmeier via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
>
>
> D integrates quite easily with R. I speak from experience, regularly using
> the two together. You can embed R inside your D program and pass data
> trivially between them. The technical side is
The largest blocking point to me is the community attitude. D constantly
wants to 'rule them all' instead of integrating with other language
ecosystems. This only recently started to change, but only towards C/C++
and not in the other direction, which is dynamic languages. PyD is only
barely alive,
On Monday, 10 August 2015 at 12:29:43 UTC, wobbles wrote:
While doing this I had the idea of implementing a more general
approach to this, using CTFE to build a struct / parserFunction
(Similar to Pegged [1] ).
You describe at compile time how this binary file looks, and
then the parser handl
I had the same situation, and ended up with the malloc/free
option. It's also often possible to get rid of allocations in a
loop by pre-allocating thread-local buffers and reusing them
throughout (see std.parallelism.TaskPool.workerLocalStorage).
On Monday, 15 December 2014 at 10:37:23 UTC, Dicebot wrote:
it is simply too far away effort-wise from something that can
be used.
Contributing something new to C++ standard library - now THAT
is hard :) In D is simply a matter of willingness to do a
quality effort, something any regular cont
On Monday, 15 December 2014 at 10:11:37 UTC, ketmar via
Digitalmars-d wrote:
nope. i'm accepting the fact that D is doomed to be a toy, which
ocasionally used here and there. i tried to fight with this,
but this
fight is lost before it's started. and now i surrender.
Very true.
This community
On Monday, 10 March 2014 at 18:50:28 UTC, Johannes Pfau wrote:
Question: which type T doesn't have slicing, has an ElementType
of
dchar, has typeof(T[0]).sizeof == 4, ElementEncodingType!T ==
char and
still satisfies isArray?
In addition, hasLength!T == false, which totally freaked me out
On Tue, Feb 25, 2014 at 7:06 PM, Adam D. Ruppe wrote:
>
> OR you download and run the binary zip. The instructions aren't very good,
> but this is really easy.
>
Yes, that works great on my Mint laptop and, I guess, the majority of
modern distros.
But let's try your advice on CentOS 5 (and please
On Tue, Feb 25, 2014 at 7:16 AM, Shammah Chancellor wrote:
> Have you looked at having dub be your autotool?
>
The complaint is about difficulties with installation of a compiler and
rdmd, and you suggest to bring in yet another dependency?
My experience is the same as described, I keep a VM on
On Thu, Feb 20, 2014 at 9:05 PM, Kamil Slowikowski
wrote:
>
> Also, I now see the error in my code: I believe I should use rawWrite to
> write compressed data and not writeExact.
>
That's not an error, that's two different ways to access files:
std.stream.File and std.stdio.File - the latter is m
Ah, indeed. I dismissed it because it allocates on each call, and heavy GC
usage in multithreaded app is a performance killer.
On Wed, Feb 19, 2014 at 8:36 PM, Adam D. Ruppe wrote:
>
> std.zlib handles gzip but it doesn't present a file nor range interface
> over it.
>
9, 2014 at 7:51 PM, Kamil Slowikowski
wrote:
>
> I have a second request. I would like to start using D more in my work,
> and in particular I would like to use and extend the BioD library. Artem
> Tarasov made a nice module to handle BGZF, and I would like to see an
> example like my Python code above using Artem's module.
>
Travis CI does have Mac boxes, can't you use them?
Did you try to add some debug printf statements in gcx.d? The log of memory
ranges that were marked/allocated would be helpful.
I couldn't reproduce it on my laptop. (uname -rv: 3.11.0-14-generic
#21-Ubuntu SMP Tue Nov 12 17:04:55 UTC 2013)
But GC is indeed buggy, and it is enormously hard to make a reasonably
small test case that will fail on most machines :(
My two cents.
1. Too long lines. Preferred length for readability is 60-80 characters per
line.
2. I have to scroll quite a while until I see some *code*. I lose interest
with every paragraph about tools setup. Some sentences are blatantly
redundant, like 'I installed DMD by double-clicking on the
An old thread on this topic:
http://forum.dlang.org/thread/mailman.2017.1353214033.5162.digitalmar...@puremagic.com
Nothing has changed since then.
Yes, global variables are thread-local by default. Use shared or _gshared
qualifier.
I guess such questions belong to D.learn.
1. Allocator which preallocates a fixed amount of extra bytes for each
chunk, so that reallocations within that limit are guaranteed to be
in-place. Multiple reallocations should be supported, too, e.g. if the
limit is 10 it allocates 210 bytes when 200 are requested and then reallocs
200 -> 205 ->
The design looks great. Easy to grasp and covers almost all imaginable use
cases.
'Almost' because it would be nice to also have ScopeAllocator!N ~
FallbackAllocator!(InsituRegion!N, Mallocator) which would automatically
deallocate all heap-allocated blocks when exiting the scope (i.e. no
dealloca
On Mon, Oct 21, 2013 at 9:00 PM, Brad Roberts wrote:
> While I haven't re-examined this issue in years, the collector hasn't
> changed and this property continues to hold... it's a natural artifact of
> the stack scan process in the gc. Not every byte of the stack is
> initialized from valgrind'
There seems to be some serious issue with the GC, yet almost no attention
is paid to that.
(See e.g. this thread:
http://forum.dlang.org/thread/anhitkodvlstehwxa...@forum.dlang.org)
I did a simple test: `void main { new ubyte[65536]; }`. This doesn't pass
memcheck!
Valgrind tells about using unini
We have great support for input ranges and thus for the pull-based model of
programming, but the standard library offers almost nothing for the
push-based model :( It utterly lacks tools for composing output ranges.
What I'd like to see working is this:
import std.stdio, std.algorithm, std.range
> http://burner.github.io/phobos/phobos-prerelease/std_logger.html
6 params to logMessage and writeMsgToLog is way too many.
First four of them should be merged into a single struct representing the
location.
26 matches
Mail list logo
