On Sat, 2013-12-21 at 11:29 -0800, Walter Bright wrote:
> On 12/21/2013 6:44 AM, Russel Winder wrote:
> > Inline assembly means you have to have the assembly code for each
> > supported platform in the code with all the conditionals to the
> > compiler. Having separate files is often much easier to
On Sun, 2013-12-22 at 04:48 +, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
[…]
> Depends, it allows you to add support for locking-mechanisms/SIMD
> instructions/etc before getting language support. You want that
> inlined and the compiler to do register assignment. I believe
> LLVM just pass it o
On Sunday, 22 December 2013 at 01:56:10 UTC, Kelet wrote:
On Sunday, 22 December 2013 at 00:18:51 UTC, Lars T. Kyllingstad
wrote:
I've tried to stay as close as possible to the design of the C
library, while adding a distinct D "feel". Details are in the
documentation.
After reviewing the AP
On Sunday, 22 December 2013 at 01:49:59 UTC, Kelet wrote:
Hi Lars, I've actually never used ZeroMQ but it seems
interesting. There exists a binding called dzmq[1], but there
are
no immediate examples.
I looked for something like this before I started, so I wouldn't
duplicate any pre-existin
The more I use D, the more I like it.
Is there a way to get cpu usage to dynamically set the parallel
options ?
E.g : I have a dual core, if cpu usage is superior than x, then
blah.
It would be interesting to :
- to be able to set the execution logic based on the cpu
capability
- as a con
22-Dec-2013 08:23, Andrei Alexandrescu пишет:
On 12/21/13 1:38 PM, Dmitry Olshansky wrote:
As it stands the only thing lazy buys us is "pay as you touch" contrary
to "pay as you name the intent to touch". The problem is that the
payment is for the whole stock of the said "shop". I see second pro
Is there a specialist GtkD mailing list?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK
On Saturday, 21 December 2013 at 22:16:13 UTC, monarch_dodra
wrote:
We should also keep in mind that as we split up modules and
split apart dependencies, it also means that *as* we import a
specific package, we are increasing our "use/import" ratio,
further diminishing the issue of "import thin
On Sunday, 22 December 2013 at 09:04:18 UTC, Larry wrote:
The more I use D, the more I like it.
Is there a way to get cpu usage to dynamically set the parallel
options ?
E.g : I have a dual core, if cpu usage is superior than x, then
blah.
It would be interesting to :
- to be able to set
On Sunday, 22 December 2013 at 10:21:31 UTC, Russel Winder wrote:
Is there a specialist GtkD mailing list?
http://forum.gtkd.org/groups/GtkD/
On Sun, 2013-12-22 at 10:33 +, John Colvin wrote:
> On Sunday, 22 December 2013 at 10:21:31 UTC, Russel Winder wrote:
> > Is there a specialist GtkD mailing list?
>
> http://forum.gtkd.org/groups/GtkD/
But that's a forum not a mailing list.
(I will avoid saying "forums are evil" because I kn
On Sunday, 22 December 2013 at 10:40:12 UTC, Russel Winder wrote:
On Sun, 2013-12-22 at 10:33 +, John Colvin wrote:
On Sunday, 22 December 2013 at 10:21:31 UTC, Russel Winder
wrote:
> Is there a specialist GtkD mailing list?
http://forum.gtkd.org/groups/GtkD/
But that's a forum not a mai
On Sunday, 22 December 2013 at 10:40:12 UTC, Russel Winder wrote:
On Sun, 2013-12-22 at 10:33 +, John Colvin wrote:
On Sunday, 22 December 2013 at 10:21:31 UTC, Russel Winder
wrote:
> Is there a specialist GtkD mailing list?
http://forum.gtkd.org/groups/GtkD/
But that's a forum not a mai
On 2013-12-22 05:19, Andrei Alexandrescu wrote:
Sounds good. I have no idea where to login though :o).
Perhaps forum.dlang.org ;)
--
/Jacob Carlborg
On Sunday, 22 December 2013 at 01:49:59 UTC, Kelet wrote:
* Create a package.json and add it to the DUB registry[2].
The "zmqd" package is now available through the DUB registry.
>> After reviewing the API and comparing it to the C API, I think
>> you did a fine job accomplishing this.
I concur. zmqd user code looks much cleaner than the original C code.
Kudos to you!
I also like the docs. I see you used your own ddoc file
(https://github.com/kyllingstad/ltkdoc). Clean an
> Is there a way to get cpu usage to dynamically set the parallel options ?
> Conclusion :
> So it would be useful to have a "std" way to set the nice of the pid, and
> get the cpu usage and eventually deciding on which core -obviously the least
> busy- the parallel will start on and then, eventua
When working with C-libraries in D I often wish for a equivalent of the
C++11 unique_ptr. Unfortunately this is not possible in D. Consider the
following source code:
http://dpaste.dzfl.pl/6e71c815
Is error 1 a bug? Because there should cleary not be any copy at this point.
Should we implemen
On Sunday, 22 December 2013 at 13:19:48 UTC, Benjamin Thaut wrote:
When working with C-libraries in D I often wish for a
equivalent of the C++11 unique_ptr. Unfortunately this is not
possible in D. Consider the following source code:
http://dpaste.dzfl.pl/6e71c815
Is error 1 a bug? Because th
Am 22.12.2013 14:24, schrieb Kelet:
On Sunday, 22 December 2013 at 13:19:48 UTC, Benjamin Thaut wrote:
When working with C-libraries in D I often wish for a equivalent of
the C++11 unique_ptr. Unfortunately this is not possible in D.
Consider the following source code:
http://dpaste.dzfl.pl/6e7
I also just noticed that std.typecons.Unique does not disable the copy
constructor. That doesn't seem very safe to me. The source code for it
is also littered with tons of "Doens't work yet" comments.
On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
Well yes, but I'm more interrested in moving around the
ownership between functions, which works in c++11 because of
the move semantics they implemented. This doesn't work in D for
the shown reasons.
http://dpaste.dzfl.pl/d1a6
Am 22.12.2013 14:36, schrieb Sergei Nosov:
On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
Well yes, but I'm more interrested in moving around the ownership
between functions, which works in c++11 because of the move semantics
they implemented. This doesn't work in D for the s
Am 16.12.2013 19:21, schrieb Andrei Alexandrescu:
What parts of the book support that opinion?
Generally I think it is a good idea to think about tracing and identify
all problems the language still has with propper tracing. Because it
seems that this has not been done in the past.
Tracing al
Yes,
The Queue seems to manage that.
I will use Python to check all the processes and see if one is
going wild to nice it.
Solved I think :)
Thanks
On 12/22/2013 02:36 PM, Sergei Nosov wrote:
On Sunday, 22 December 2013 at 13:28:05 UTC, Benjamin Thaut wrote:
Well yes, but I'm more interrested in moving around the ownership
between functions, which works in c++11 because of the move semantics
they implemented. This doesn't work in D for the
On 12/22/2013 02:19 PM, Benjamin Thaut wrote:
When working with C-libraries in D I often wish for a equivalent of the
C++11 unique_ptr. Unfortunately this is not possible in D. Consider the
following source code:
http://dpaste.dzfl.pl/6e71c815
Is error 1 a bug? Because there should cleary not b
On Sunday, 22 December 2013 at 03:08:49 UTC, John J wrote:
Thank you! It's pretty fast now!! :)
Btw, I have been using Thunderbird and I frequently see the
already read threads (mostly messages of the existing threads)
suddenly appear as unread (in bold). Is this happening from
your end? If s
On 12/22/2013 03:13 PM, Timon Gehr wrote:
Is error 1 a bug? Because there should cleary not be any copy at this
point.
...
I don't think the conditions when a struct is moved are actually
documented beyond the NRVO case. I think it ideally would be a bug, but
this would require some kind of DI
On 12/22/2013 03:19 PM, Timon Gehr wrote:
On 12/22/2013 03:13 PM, Timon Gehr wrote:
Is error 1 a bug? Because there should cleary not be any copy at this
point.
...
I don't think the conditions when a struct is moved are actually
documented beyond the NRVO case. I think it ideally would be a
On Sun, 2013-12-22 at 10:44 +, John Colvin wrote:
[…]
> I assumed by "mailing list" you meant "mailing list / forum /
> newsgroup / golden font of topical chatter"
Or whatever :-)
> I get that you have a workflow, but surely if you need some
> information it's not too hard to use a forum e
On Sun, 2013-12-22 at 11:28 +, Tourist wrote:
[…]
> See footer:
> This forum is powered by VibeNews and can also be accessed using
> a news reader pointed to nntp://forum.gtkd.org/.
I had missed that, but even then NNTP is not email delivered, and email
injected: unless there is a gateway tha
On Sunday, 22 December 2013 at 12:22:04 UTC, Jacob Carlborg wrote:
On 2013-12-22 05:19, Andrei Alexandrescu wrote:
Sounds good. I have no idea where to login though :o).
Perhaps forum.dlang.org ;)
Correct :) The address remains df...@forum.dlang.org as before.
On Sunday, 22 December 2013 at 12:52:23 UTC, Philippe Sigaud
wrote:
After reviewing the API and comparing it to the C API, I think
you did a fine job accomplishing this.
I concur. zmqd user code looks much cleaner than the original C
code.
Kudos to you!
Thanks!
I also like the docs. I see
On Sunday, 22 December 2013 at 08:11:05 UTC, Russel Winder wrote:
Historically, and anecdotally, I found that as soon as the
assembly
language was a function, it was better as a separate entity,
Well, you can usually get what you want by first writing the code
in C, then generate asm and opti
On 12/22/2013 12:10 AM, Russel Winder wrote:
Historically, and anecdotally, I found that as soon as the assembly
language was a function, it was better as a separate entity, that inline
assembler only worked for accessing a processor instruction that the
code generator could not generate. So I th
On 12/22/2013 12:05 AM, Russel Winder wrote:
There is no case where D's support for intel inline assembler is worse than
forcing you to use a separate assembler.
My point is really that D needs to support ARM pdq to have any chance of
getting traction in an increasingly bi-partisan (Intel/AMD a
On 12/22/13 5:50 AM, Benjamin Thaut wrote:
In my opinion we should first decide on the type of collector to be
implemented and then implement the subsystems needed by that collector,
in a way that optimally serves that collector. If someone wants to
implement another type of collector, they will
Walter Bright:
Apparently nobody writing an assembler ever had the obvious
idea of tacking on a C front end so it could at least pull the
struct declarations out of the .h files.
In D you can do the opposite: write the asm files, import them
statically from D and parse and convert them with
On 12/22/2013 03:12 PM, Vladimir Panteleev wrote:
I suppose that DFeed could have its own NNTP server (similarly to what
Vibe.news does), allow logging in with the forum username/password, and
mark messages downloaded via NNTP as "read" in the web interface...
Don't forget to extend the NNTP pr
On Sunday, 22 December 2013 at 17:21:59 UTC, Walter Bright wrote:
There's nothing tricky about an assembler or its syntax. There
may be issues with supporting an inline assembler and the GDC
or LDC back end interfaces, that I don't know about.
Both GCC and LLVM actually support more extensive
On 20/12/13 02:40, Francesco Cattoglio wrote:
I don't know, I feel like I would be more useful if I only sticked with working
on the standard library when needed and writing software that others might find
interesting (I'm planning on "resurrecting" SciD btw)
Nice to know -- anything in particu
On 12/22/2013 12:05 AM, Timon Gehr wrote:
How is this going to work?
Ah sorry, I misread your example.
The call template function is in module a, so it has access too.
> Are you arguing for creating multiple instances of 'call'?
So this is indeed not necessary, the function is called withi
On 12/22/2013 09:34 AM, Lars T. Kyllingstad wrote:
* Create a package.json and add it to the DUB registry[2]. I have
taken the liberty at making a simple package.json that may work
but is untested[3].
I've never used DUB myself, but I will try to use your package file.
Thanks!
Add a CI tester
On 21/12/13 15:44, Russel Winder wrote:
Inline assembly means you have to have the assembly code for each
supported platform in the code with all the conditionals to the
compiler. Having separate files is often much easier to manage and to
build from.
OK so D only support Intel processors just n
+1 The API surface feels fantastic! This is EXACTLY the kind of D
bindings I would wish for when we bind to existing C libraries.
It adds just enough D flavor to soften the edges of the client
implementation; while not substantially changing the core library
surface (which helps when you have t
Isn't there a problem using Microsoft's visual studio to link for
64 bit in that visual studio 2013 is free only for enrolled
students?
On 12/22/2013 1:14 PM, Stephen Jones wrote:
Isn't there a problem using Microsoft's visual studio to link for 64 bit in that
visual studio 2013 is free only for enrolled students?
Yes, there is. If you want to gen 64 bit Windows code for dmd you'll need a VS
license of one sort or another.
H
On 21 December 2013 06:26, Paulo Pinto wrote:
> On 20.12.2013 22:05, Jacob Carlborg wrote:
>>
>> On 2013-12-20 08:03, Paulo Pinto wrote:
>>
>>> Even though I rather use D than Go, every time I read that, I am tempted
>>> to prove people wrong. If I had the time for it, that is.
>>>
>>> Go offers t
On Sunday, 22 December 2013 at 21:14:54 UTC, Stephen Jones wrote:
Isn't there a problem using Microsoft's visual studio to link
for 64 bit in that visual studio 2013 is free only for enrolled
students?
Recent versions of Visual Studio Express (which is free for
everyone) should work fine.
On 12/22/2013 08:48 PM, Martin Nowak wrote:
On 12/22/2013 12:05 AM, Timon Gehr wrote:
How is this going to work?
Ah sorry, I misread your example.
The call template function is in module a, so it has access too.
> Are you arguing for creating multiple instances of 'call'?
So this is inde
On Sunday, 22 December 2013 at 21:43:17 UTC, Brad Anderson wrote:
On Sunday, 22 December 2013 at 21:14:54 UTC, Stephen Jones
wrote:
Isn't there a problem using Microsoft's visual studio to link
for 64 bit in that visual studio 2013 is free only for
enrolled students?
Recent versions of Visual
Iain Buclaw:
That same support is never going to happen. Not because of
disagreement, but because our backends are designed to work most
naturally in conflicting ways.
I think this means that working to make DMD better is a good
idea, because every compiler has different strengths, like Walt
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have
happened several months ago. It has become pretty clear that
there is no good way out of existing situation and least bad
needs to be picked just to move forward (because it still be
better than current
On 12/23/2013 02:39 AM, Dicebot wrote:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have happened
several months ago. It has become pretty clear that there is no good way
out of existing situation and least bad needs to be picked just to move
forward (beca
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `alias this` part (that would destroy "no auto expansion"
part unless I miss something). Also I am still u
On 12/23/2013 03:28 AM, Dicebot wrote:
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `alias this` part (that would destroy "no auto expansion" part
No
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
Are you seriously suggesting we change the auto-expanding
behaviour of template argument lists? This is going to cause the
biggest code breakage since D2, for the niche benefit of having
lists that don't
On Mon, Dec 23, 2013 at 01:39:24AM +, Dicebot wrote:
> http://wiki.dlang.org/DIP54
>
> This is follow-up of several hot discussion threads that have
> happened several months ago. It has become pretty clear that there
> is no good way out of existing situation and least bad needs to be
> picke
On 12/22/2013 09:12 AM, Vladimir Panteleev wrote:
On Sunday, 22 December 2013 at 03:08:49 UTC, John J wrote:
Thank you! It's pretty fast now!! :)
Btw, I have been using Thunderbird and I frequently see the already
read threads (mostly messages of the existing threads) suddenly appear
as unread
On Mon, Dec 23, 2013 at 02:46:38AM +, Jakob Ovrum wrote:
> On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
> >http://wiki.dlang.org/DIP54
>
> Are you seriously suggesting we change the auto-expanding behaviour
> of template argument lists? This is going to cause the biggest code
>
On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
People who want auto-expanding template argument lists can
still do
this:
It's not perfectly clear, but it looks to me that the DIP
suggests removing the auto-expand
On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
People who want auto-expanding template argument lists can
still do
this:
It's not perfectly clear, but it looks to me that the DIP
suggests removing the auto-expanding property of template
argument lists.
On Monday, 23 December 2013 at 02:42:01 UTC, Timon Gehr wrote:
On 12/23/2013 03:28 AM, Dicebot wrote:
On Monday, 23 December 2013 at 01:53:57 UTC, Timon Gehr wrote:
How is this going to be implemented? In a similar way as
this?:
https://d.puremagic.com/issues/show_bug.cgi?id=11804
Without `a
On Mon, Dec 23, 2013 at 03:02:48AM +, Dicebot wrote:
> On Monday, 23 December 2013 at 03:00:11 UTC, Jakob Ovrum wrote:
> >On Monday, 23 December 2013 at 02:55:57 UTC, H. S. Teoh wrote:
> >>People who want auto-expanding template argument lists can still do
> >>this:
> >
> >It's not perfectly cl
On Monday, 23 December 2013 at 02:46:40 UTC, Jakob Ovrum wrote:
This DIP makes several unfounded assumptions. It assumes that
the semantics of template argument lists are inherently hard to
learn,
Hard? No. Complicated - yes, I see wrong assumptions being made
all the time. But this is langua
On Monday, 23 December 2013 at 03:17:27 UTC, Dicebot wrote:
Hard? No. Complicated - yes, I see wrong assumptions being made
all the time. But this is language failure and is not directly
related to this DIP.
I don't think it's obvious that it's a language failure.
I don't say that. I say that
Am Sat, 21 Dec 2013 22:43:58 +0100
schrieb Andrej Mitrovic :
> I could think of more optimizations, for example if we had a way of
> exporting a list of module-level symbols into some kind of
> intermediary format (say JSON), the compiler could look up this list
> rather than to have to eagerly lo
On Monday, 23 December 2013 at 01:39:26 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP54
This is follow-up of several hot discussion threads that have
happened several months ago. It has become pretty clear that
there is no good way out of existing situation and least bad
needs to be picked ju
On Dec 23, 2013 12:00 AM, "bearophile" wrote:
>
> Iain Buclaw:
>
>
>> That same support is never going to happen. Not because of
>> disagreement, but because our backends are designed to work most
>> naturally in conflicting ways.
>
>
> I think this means that working to make DMD better is a good
On Sunday, 22 December 2013 at 13:40:30 UTC, Benjamin Thaut wrote:
Uh, this looks a lot better then std.typecons.Unique
Did you try doing a pull request to replace std.typecons.Unique
with your implementation?
No, I didn't.
I'm kind of thinking, that the "unique" concept currently can't
be fu
I am guessing I will need to raise issues in the various issue trackers
but:
I am finding that GtkD highlights some issues for GDC and LDC2. One of
the moment relates to gtk.Builder.connectSignals. My code compiles and
runs as expected with DMD, but with GDC and LDC2 the signals fail to
connect.
No, he tells they had pure by default, but because most code is
impure, annotations became a noise.
73 matches
Mail list logo
