On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev
wrote:
[...]
Agree, however, memory obtained with mmap(..., PROT_READ, ..);
is essentially read-only and any attempt to write to it will
cause immediate crash with segmentation violation. It would be
very desirable in this case
On Friday, 4 September 2015 at 07:27:54 UTC, Namal wrote:
On Friday, 4 September 2015 at 01:55:13 UTC, deed wrote:
On Friday, 4 September 2015 at 01:31:28 UTC, Namal wrote:
How can I get just the maximum element? Do I need to give a
range for it?
Use max?
On Friday, 4 September 2015 at 08:37:26 UTC, Kagamin wrote:
On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev
wrote:
Agree, however, memory obtained with mmap(..., PROT_READ, ..);
is essentially read-only and any attempt to write to it will
cause immediate crash with segmentation
On Friday, 4 September 2015 at 12:06:08 UTC, Edwin van Leeuwen
wrote:
On Friday, 4 September 2015 at 11:50:23 UTC, deed wrote:
import std.algorithm, std.range, std.array, std.string,
std.stdio,
std.conv;
int[] arr1 = [1, 2, 30];
//arr1.max.writeln; // Doesn't work, as you say
On Friday, 4 September 2015 at 11:50:23 UTC, deed wrote:
import std.algorithm, std.range, std.array, std.string,
std.stdio,
std.conv;
int[] arr1 = [1, 2, 30];
//arr1.max.writeln; // Doesn't work, as you say
arr1.reduce!max.writeln;// This does. Prints 30.
Again using reduce is
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner wrote:
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to
come with 2.068
If you use either the -m64 or -mscoff32 interop should be pretty
good.
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to compile it yourself. Use the win64 makefile and
replace the arch=64 with
arch=32mscoff.
For more details see here:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to compile it yourself. Use the win64 makefile and
replace the
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to come
with 2.068
On Friday, 4 September 2015 at 08:58:41 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 08:53:27 UTC, Szymon Gatner
wrote:
Hi,
what is the current status of:
- Win x86/32bit/coff32 interop with C++?
- improvements for general C++ interop that were suppose to
come with 2.068
If
Hello thedeemon,
tvDdl> Yes, DFL!
tvDdl> https://github.com/Rayerd/dfl
Sounds good. but still... I can't find any examples or documentation
:(
--
With best regards from Ukraine,
Andre
Skype: Francophile
Twitter: @m_elensule; Facebook: menelion
My blog: http://menelion.oire.org/
See https://issues.dlang.org/show_bug.cgi?id=13889
On Friday, 4 September 2015 at 09:05:07 UTC, Marc Schütz wrote:
Note that you can however achieve immutability by using a
_private_ read-only mapping.
man pages say the behavior is unspecified.
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos? Last time I checked (2.067) only x64
was distributed.
You have to
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos?
On Thursday, 3 September 2015 at 13:16:41 UTC, Adam D. Ruppe
wrote:
http://arsdnet.net/dcode/book/chapter_08/11/caller.d
https://github.com/adamdruppe/arsd/blob/master/jsvar.d#L608
Thank you for these examples.
On Friday, 4 September 2015 at 14:18:40 UTC, Benjamin Thaut wrote:
On Friday, 4 September 2015 at 10:04:48 UTC, Szymon Gatner
wrote:
On Friday, 4 September 2015 at 09:27:14 UTC, Benjamin Thaut
wrote:
On Friday, 4 September 2015 at 09:07:39 UTC, Szymon Gatner
wrote:
What about 32bit phobos?
On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner wrote:
but now using phobos64.lib from 2.068 distribution does not
even link properly with VC2015.
That's https://issues.dlang.org/show_bug.cgi?id=14849
On Thu, 03 Sep 2015 18:50:21 +0200, Robert M. Münch wrote:
> Hi, I'm not sure how to best implement the following:
>
> 1. I have 4 different tasks to do.
> 2. All can run in parallel 3. Every task will return some result that I
> need
>
> Now how to best do it? When using receive() it fires on
On Friday, 4 September 2015 at 13:54:25 UTC, Andre Polykanine
wrote:
Hello thedeemon,
tvDdl> Yes, DFL!
tvDdl> https://github.com/Rayerd/dfl
Sounds good. but still... I can't find any examples or
documentation :(
Here's some original docs and examples:
On 9/3/15 5:20 PM, Matt Kline wrote:
TDPL suggests that calls to std.concurrency.send will fail with an
"OwnedTerminated" or "OwnedFailed" exception if the destination thread
has exited, but neither the docs nor the current Phobos implementation
make any mention of such exceptions. Thinking the
On Friday, 4 September 2015 at 08:33:08 UTC, Marc Schütz wrote:
They're called `OwnerTerminated` and `OwnerFailed` with an "r".
No, that's received by the child if the owning thread exits. I'm
talking about the "parent" thread attempting to send to a child
thread that has exited.
Relevant
On Friday, 4 September 2015 at 16:26:51 UTC, Kagamin wrote:
On Friday, 4 September 2015 at 15:43:44 UTC, Szymon Gatner
wrote:
but now using phobos64.lib from 2.068 distribution does not
even link properly with VC2015.
That's https://issues.dlang.org/show_bug.cgi?id=14849
yup, that looks
On Friday, 4 September 2015 at 13:29:42 UTC, Kagamin wrote:
On Friday, 4 September 2015 at 09:05:07 UTC, Marc Schütz wrote:
Note that you can however achieve immutability by using a
_private_ read-only mapping.
man pages say the behavior is unspecified.
The Linux man page says:
"It is
On Friday 04 September 2015 23:04, Timon Gehr wrote:
> DMD never warns about dead code.
It warns here:
import std.stdio;
void main()
{
return;
writeln("hi"); /* Warning: statement is not reachable */
}
I discovered the other day (during a cut and paste malfunction!)
that it's possible to have code before the first case in a
switch. Google tells me that it's legal C code and something I
read said it could be used for initialization but was rather
vague.
void main()
{
import std.stdio;
On 09/04/2015 09:39 PM, Paul wrote:
I discovered the other day (during a cut and paste malfunction!) that
it's possible to have code before the first case in a switch. Google
tells me that it's legal C code and something I read said it could be
used for initialization but was rather vague.
void
On 09/04/2015 11:12 PM, anonymous wrote:
On Friday 04 September 2015 23:04, Timon Gehr wrote:
DMD never warns about dead code.
It warns here:
import std.stdio;
void main()
{
return;
writeln("hi"); /* Warning: statement is not reachable */
}
You are right, it does.
On Saturday 05 September 2015 03:43, Prudence wrote:
> Standard and Win32 apps are so old school!
>
> I'd like to hide WinMain by wrapping it in an application
> class(more or less).
>
> Essentially I have an Application class
>
> class Application
> {
> public static Application New(void
On Saturday, 5 September 2015 at 02:29:05 UTC, Prudence wrote:
If I use functions instead of delegates it works.
I suppose the problem then is that the delegate can't create a
fat pointer when used in a static context. (i.e., why the
functions work)
The question is, then, Can I construct a
On Friday, 4 September 2015 at 05:51:02 UTC, Mike Parker wrote:
* What was previously said *
DMD is not currently compatible with VS 2015. You'll have
trouble if you try to use it. That will hopefully be fixed in a
not-too-distant release.
* What was previously said *
Based on this
Standard and Win32 apps are so old school!
I'd like to hide WinMain by wrapping it in an application
class(more or less).
Essentially I have an Application class
class Application
{
public static Application New(void delegate() entry)
{
}
}
Another module
extern (Windows)
On Saturday, 5 September 2015 at 01:49:22 UTC, Adam D. Ruppe
wrote:
On Saturday, 5 September 2015 at 01:43:43 UTC, Prudence wrote:
extern (Windows) int WinMain(...)
If you use WinMain in D, you'll also have to initialize the D
runtime yourself, which will call static constructors and such.
If I use functions instead of delegates it works.
I suppose the problem then is that the delegate can't create a
fat pointer when used in a static context. (i.e., why the
functions work)
The question is, then, Can I construct a delegate manually and
supply my own context pointer?
e.g.,
On Saturday, 5 September 2015 at 01:43:43 UTC, Prudence wrote:
extern (Windows) int WinMain(...)
If you use WinMain in D, you'll also have to initialize the D
runtime yourself, which will call static constructors and such.
You'd be better off just using a regular main() function, then
On Friday, 4 September 2015 at 01:55:13 UTC, deed wrote:
On Friday, 4 September 2015 at 01:31:28 UTC, Namal wrote:
How can I get just the maximum element? Do I need to give a
range for it?
Use max?
http://dlang.org/phobos/std_algorithm_comparison.html#max
Sorry, I don't understand the
On 2015-09-03 17:46, Andre Polykanine via Digitalmars-d-learn wrote:
Hi everyone,
Does anyone of you work with a Windows GUI library with native
controls in order to write desktop apps in D?
Here is why I'm asking: actually, there are quite a number of GUI
libraries listed at
On Thursday, 3 September 2015 at 15:46:28 UTC, Andre Polykanine
wrote:
So my question is: is there any reliable GUI library
implementing native Windows controls?
Yes, DFL!
https://github.com/Rayerd/dfl
It's a thin wrapper over WinAPI so all controls are native. I've
built several apps
https://github.com/etcimon/windows-headers
On Thursday, 3 September 2015 at 21:20:59 UTC, Matt Kline wrote:
TDPL suggests that calls to std.concurrency.send will fail with
an "OwnedTerminated" or "OwnedFailed" exception if the
destination thread has exited, but neither the docs nor the
current Phobos implementation make any mention of
On Wednesday, 2 September 2015 at 04:04:54 UTC, Sergei Degtiarev
wrote:
I seems a little bit too easy to to shoot yourself in the foot.
Yes, cast is a little not fool-proof in this scenario.
On Thursday, 3 September 2015 at 13:28:54 UTC, Sergei Degtiarev
wrote:
Agree, however, memory
41 matches
Mail list logo
