The backtrace code has a parameter that lets you tell it how many
leading frames you want it to skip when generating the result.
This is to get out of the Throwable ctor code itself, but it
wouldn't be hard to bump this by one or two if you need it to.
On Tuesday, 16 December 2014 at 04:56:10 UTC, Ellery Newcomer
wrote:
If I have a thread that I need to detach from druntime, I can
call thread_detachInstance, but for 2.066, this function does
not exist. Is there any way to do this in 2.066? I notice there
is a thread_detachByAddr, but I'm not
Sounds like a module that should be in core.sys.linux. Care to
submit a pull request?
On Monday, 10 November 2014 at 16:01:21 UTC, Charles wrote:
Hi guys,
I've been looking and haven't found any libraries for ODBC or
MSSQL. I saw some for D v1, but nothing for v2. Anyone know of
any, or anyone know of a tutorial that I could use to create
this myself?
Assuming you're using
Oh, here's a sample, since it doesn't look like that zip includes
one:
import sql.Connection;
import sql.Exception;
import sql.ResultSet;
import sql.Statement;
import core.stdc.stdio;
pragma( lib, odbc32.lib );
pragma( lib, sql.lib );
void main()
{
try
{
auto conn = new
On Wednesday, 5 November 2014 at 09:45:50 UTC, Mike wrote:
Greetings,
In core.varar.
(https://github.com/D-Programming-Language/druntime/blob/master/src/core/vararg.d),
why is the X86 implementation singled out and written in D
rather than leveraging the standard c library implementation
On Monday, 3 November 2014 at 04:31:40 UTC, Dirk wrote:
I should of mentioned that I have also seen the MadCodeHook
Library bindings, which is great but the MCH library is very
expensive.
Weird, it used to be open source and free.
On Monday, 3 November 2014 at 14:58:03 UTC, Ali Çehreli wrote:
I think it's the intended behavior. I think documentation is
outdated.
Both forms should really work though. I had always thought that
the short form was simply possible if the names matched.
On Monday, 3 November 2014 at 14:09:21 UTC, Steven Schveighoffer
wrote:
From OP's code, he is on Windows.
I believe on Windows you have to sort out some kind of
permissions to terminate a process. No idea if std.process does
this, but it sounds like probably not.
Note that thread_joinAll is called automatically when main exits,
so if you just want to be sure that your spawned thread completes
you don't have to do anything at all.
The decision to obscure the Thread object in std.concurrency was
deliberate, as it allows us to use more than just kernel
Note that thread_joinAll is called automatically when main exits,
so if you just want to be sure that your spawned thread completes
you don't have to do anything at all.
The decision to obscure the Thread object in std.concurrency was
deliberate, as it allows us to use more than just kernel
On Sunday, 2 November 2014 at 11:59:27 UTC, Marc Schütz wrote:
On Saturday, 1 November 2014 at 21:00:54 UTC, Kagamin wrote:
D claims compatibility with system C compiler, which usually
have 32-bit int.
... and for C/C++ long which can be 32 or 64 bit, DMD recently
introduced the types c_long
On Sunday, 2 November 2014 at 06:23:38 UTC, Ali Çehreli wrote:
On 11/01/2014 11:13 PM, Sean Kelly wrote:
Note that thread_joinAll is called automatically when main
exits
Has that always been the case? I remember having to inject
thread_joinAll() calls at the ends of the main()s of a couple
On Sunday, 2 November 2014 at 16:53:06 UTC, ponce wrote:
c_long and c_ulong get used, should c_int and c_uint too in
bindings?
Looks like fringe use case.
On common 32 and 64-bit platforms, the only type whose size
changed between 32 and 64 bits is long, so the other aliases were
deemed
For those cases you could use spawnLinked and then receive
LinkTerminated as well, if you're looking for a solution within
the concurrency API.
On Monday, 27 October 2014 at 19:13:13 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
The reason that it's not shared is because Sean Kelly didn't
want to make
much of anything in druntime shared until shared was better
ironed out, which
keeps getting talked about but never done.
On Friday, 24 October 2014 at 21:02:05 UTC, Kapps wrote:
Yes, GDB is stopping on SIGUSR1 / SIGUSR2 since that's the
default settings. D's GC uses these signals for suspending /
resuming threads during a collection. You need to type what I
said above, prior to typing 'run'.
I took a look at
On Monday, 20 October 2014 at 09:53:23 UTC, Marco Leise wrote:
Thank you for that honest response. The situation is really
bizarre. I just tried to create a shared worker thread and
there is no ctor in Thread that creates a shared instance.
Is a shared constructor even meaningful? [1]
If we
On Sunday, 19 October 2014 at 13:42:05 UTC, Marco Leise wrote:
I have a thread that is shared by
others, so I have a shared method, inside of which I wrote:
final void opOpAssign(string op : ~)(ref StreamingObject
item) shared
{
synchronized (m_condition.mutex)
{
On Tuesday, 14 October 2014 at 20:08:03 UTC, Brad Anderson wrote:
On Tuesday, 14 October 2014 at 20:05:07 UTC, Brad Anderson
wrote:
https://github.com/D-Programming-Language/phobos/blob/master/std/json.d#L579
Oops. Linked the the parser section. I actually don't see any
unicode escape
On Tuesday, 14 October 2014 at 19:47:00 UTC, jicman wrote:
Greetings.
Imagine this code,
char[] s = ABCabc;
foreach (char c; s)
{
// how do I convert c to something an Unicode code? ie.
\u.
}
I'd look at the JSON string encoder.
On Thursday, 25 September 2014 at 21:43:53 UTC, monarch_dodra
wrote:
On Thursday, 25 September 2014 at 20:58:29 UTC, Gary Willoughby
wrote:
A few questions regarding GC.malloc.
When requesting a chunk of memory from GC.malloc am i right in
assuming that this chunk is scanned for pointers to
Interface and object variables are reference types--you don't
need the '*' to make them so. By adding the extra layer of
indirection you're losing the only reference the GC can decipher
to the currentState instance.
On Friday, 15 August 2014 at 08:36:34 UTC, Kagamin wrote:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
Allocates memory charges (from the overall size of memory and
the paging files on disk) for the specified reserved memory
pages. The function also
On Friday, 15 August 2014 at 14:28:34 UTC, Dicebot wrote:
Won't that kind of kill the purpose of Fiber as low-cost
context abstraction? Stack size does add up for thousands of
fibers.
As long as allocation speed is fast for large allocs (which I
have to test), I want to change the default
On Friday, 15 August 2014 at 14:26:28 UTC, Sean Kelly wrote:
On Friday, 15 August 2014 at 08:36:34 UTC, Kagamin wrote:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887%28v=vs.85%29.aspx
Allocates memory charges (from the overall size of memory and
the paging files on disk) for
At least on OSX, it appears that mapping memory is constant time
regardless of size, but there is some max total memory I'm
allowed to map, presumably based on the size of a vmm lookup
tabe. The max block size I can allocate is 1 GB, and I can
allocate roughly 131,000 of these blocks before
On Friday, 15 August 2014 at 15:25:23 UTC, Dicebot wrote:
No, I was referring to the proposal to supply bigger stack size
to Fiber constructor - AFAIR it currently does allocate that
memory eagerly (and does not use any OS CoW tools), doesn't it?
I thought it did, but apparently the
On Friday, 15 August 2014 at 20:17:51 UTC, Carl Sturtivant wrote:
On Friday, 15 August 2014 at 15:40:35 UTC, Sean Kelly wrote:
I thought it did, but apparently the behavior of VirtualAlloc
and mmap (which Fiber uses to allocate the stack) simply
reserves the range and then commits it lazily,
On 64 bit, reserve a huge chunk of memory, set a SEGV handler and
commit more as needed. Basically how kernel thread stacks work.
I've been meaning to do this but haven't gotten around to it yet.
Superfast. Though Murmur has gotten good enough that I'm tempted
to switch. At the time, Murmur didn't even have a license so it
wasn't an option.
On Tuesday, 12 August 2014 at 15:06:38 UTC, ketmar via
Digitalmars-d-learn wrote:
besides, using atomic operations will allow you to drop
synchronize altogether which makes your code slightly faster.
... and potentially quite broken. At the very least, if this
value is ready anywhere
On Monday, 4 August 2014 at 21:19:14 UTC, Philippe Sigaud via
Digitalmars-d-learn wrote:
Has anyone used (the fiber/taks of) vibe.d for something other
than powering websites?
https://github.com/D-Programming-Language/phobos/pull/1910
This looks like an optimizer bug. Do you see the same result
with -release set vs. not, etc?
On Thursday, 31 July 2014 at 19:28:24 UTC, Marc Schütz wrote:
On Thursday, 31 July 2014 at 18:30:41 UTC, Anonymous wrote:
module test;
import std.stdio;
class buffer(T, size_t sz) {
auto arr = new T[sz];
This allocates an array with `sz` elements once _at compile
time_, places it
On Monday, 10 March 2014 at 11:59:20 UTC, Steve Teale wrote:
Note that there is no call to Runtime.unloadLibrary(). The
assumption her is that once the plugin has been loaded it will
be there for the duration of the program. If you want to unload
it you'll probably have to make sure the
On Thursday, 3 July 2014 at 10:25:41 UTC, Bienlein wrote:
There is also a Semaphore and Barrier class:
http://dlang.org/phobos/core_sync_barrier.html
http://dlang.org/phobos/core_sync_semaphore.html
This is probably what I'd do, though both this and thread_joinAll
will only work if you have
On Monday, 30 June 2014 at 20:53:25 UTC, Sergey Protko wrote:
Is there any proper way to do on-demand lazy-initialization of
used library, which will be also thread-safe? How do i need to
handle cases where some methods, which requires library to be
initialized, called from different threads
On Friday, 27 June 2014 at 13:03:20 UTC, John Colvin wrote:
It's an application and network dependant decision, but I would
suggest http://code.dlang.org/packages/zmqd as suitable for
most situations.
Yeah, this would be my first choice. Or HTTP if integration with
other applications is
On Saturday, 28 June 2014 at 17:11:51 UTC, Russel Winder via
Digitalmars-d-learn wrote:
Sadly, I don't have time to contribute to any constructive work
on this
just now. And I ought to be doing a review and update to
std.parallelism…
That's fine. I have zero free time until August.
On Friday, 27 June 2014 at 07:34:55 UTC, safety0ff wrote:
On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote:
1) After allocating memory by GC.calloc() to place objects on
it, what else should one do?
Use std.conv.emplace.
And possibly set BlkInfo flags to indicate whether the block
On Thursday, 12 June 2014 at 05:29:39 UTC, Mike Franklin wrote:
Hello,
I was recently exposed to this template in core.atomic:
private
{
template HeadUnshared(T)
{
static if( is( T U : shared(U*) ) )
alias shared(U)* HeadUnshared;
else
alias T
On Thursday, 22 May 2014 at 19:21:26 UTC, David Soria Parra via
Digitalmars-d-learn wrote:
I know that thread_detachByAddr exists, but the Thread object
from
Thread.getAll or Thread.opApply doesn't expose the thread
address.
Would thread_detachThis work for you? Alternately, you can use
On Wednesday, 21 May 2014 at 20:19:32 UTC, Ali Çehreli wrote:
I think this is a known issue with immutable and Variant, which
std.concurrency uses for unknown messages. This looks related:
https://issues.dlang.org/show_bug.cgi?id=5538
std.concurrency actually uses Variant as the
44 matches
Mail list logo
