Seems like there are several levels of "wrong" actually: What
do you expect "scope(failure)continue" to do exactly?
I was reading an array of files (Document[string]).
Stuck the scope(failure)continue in late at night apparently to
skip reading files that no longer exist.
Forgot about it
On 06/28/2013 06:19 AM, Joseph Rushton Wakeling wrote:
Consider the following equivalent code using zip and lockstep respectively to
iterate over the entries in an array and set their values:
auto arr1 = new double[10];
foreach(i, ref x; zip(iota(10), arr1))
{
x = i;
On 06/29/2013 02:26 PM, monarch_dodra wrote:
DMD is on to something, because if you replace failure with "exit" or
"success", then it complains with: "Error: continue is not inside a loop".
Hmmm... 'continue' and others are disallowed only for scope(exit) and
scope(success):
http://dlang.
On 06/29/2013 07:52 AM, monarch_dodra wrote:
> This is strange to me because ordering is (usually) tied to a norm,
> where basically, opCmp returns whoever has the smallest norm. Yet this
> ordering isn't really tied to any norm.
Agreed. The opCmp that I have written makes sense when there is a
On 06/29/2013 01:35 PM, Gary Willoughby wrote:
I want to spawn a few worker threads to do some processing but i want
the spawned function to have access to a shared object. How do i
accomplish this?
I'm currently passing it as a parameter and getting the error: "Aliases
to mutable thread-local d
Jonathan M Davis:
I thought that there was a bug report on that (probably
suggesting that the
compiler make such a continue illegal), but I can't find it
right now.
If you can't find it, it's better to file it because it's better
to have a bug two times in Bugzilla than no times.
Bye,
bear
On Saturday, June 29, 2013 23:26:33 monarch_dodra wrote:
> Which is wrong, since a scope(failure) is not supposed to "catch"
> the exception. In this case, the "continue" short-circuits the
> compiler generated "rethrow".
I thought that there was a bug report on that (probably suggesting that the
On Saturday, 29 June 2013 at 20:45:12 UTC, Anthony Goins wrote:
Is this known?
I've heard there are many problems with associative arrays.
dmd 2.063
---
module scopefailtest;
int[char] AAarray;
void main(string[] args)
{
AAarray = ['a':1, 'b':2, 'c':3];
foreach(aa; AAarray)
{
Is this known?
I've heard there are many problems with associative arrays.
dmd 2.063
---
module scopefailtest;
int[char] AAarray;
void main(string[] args)
{
AAarray = ['a':1, 'b':2, 'c':3];
foreach(aa; AAarray)
{
scope(failure)continue;
aa = 32;
}
}
---
I want to spawn a few worker threads to do some processing but i
want the spawned function to have access to a shared object. How
do i accomplish this?
I'm currently passing it as a parameter and getting the error:
"Aliases to mutable thread-local data not allowed."
Please explain why this error happens in the following code:
import std.algorithm;
struct S
{
void foo ()
{
int f1 (int a) { return conv(a); }
int delegate (int) f2 = &conv;
int[] x = [1, 2, 3];
x.map!conv;// ERROR
x.map!f1; // fine
x.map!f2; // also fi
On Saturday, 29 June 2013 at 07:45:01 UTC, yaz wrote:
On Saturday, 29 June 2013 at 06:08:28 UTC, Jeremy DeHaan wrote:
I've been toying around with the idea of working on an IDE,
mostly because I think it would be an interesting/fun project
to work on. In any case, the only thing I cannot seem t
On Saturday, 29 June 2013 at 15:15:49 UTC, Andrej Mitrovic wrote:
On Saturday, 29 June 2013 at 15:15:08 UTC, Andrej Mitrovic
wrote:
On Saturday, 29 June 2013 at 15:14:19 UTC, Andrej Mitrovic
wrote:
On Saturday, 29 June 2013 at 15:03:05 UTC, Geod24 wrote:
Hi folks,
As I'm learning phobos, I wan
On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote:
Shouldn't doing anything value-related on
an empty struct be invalid anyway?
Why ?
The fact that the struct has no members is an implementation
detail which should have no impact on the user of the struct.
On Saturday, 29 June 2013 at 14:54:13 UTC, snow wrote:
On Saturday, 29 June 2013 at 14:20:05 UTC, Ali Çehreli wrote:
Not knowing whether it applies to your case, the following is
one almost correct way of writing opCmp:
int opCmp(ref const Vector3D vec) {
return cast(int)(x != vec.x
On Saturday, 29 June 2013 at 15:14:19 UTC, Andrej Mitrovic wrote:
On Saturday, 29 June 2013 at 15:03:05 UTC, Geod24 wrote:
Hi folks,
As I'm learning phobos, I wanted a more inside look and did a
co of the libs + dmd.
Try getting the latest druntime from git-head, since these
symbols were mov
On Saturday, 29 June 2013 at 15:15:08 UTC, Andrej Mitrovic wrote:
On Saturday, 29 June 2013 at 15:14:19 UTC, Andrej Mitrovic
wrote:
On Saturday, 29 June 2013 at 15:03:05 UTC, Geod24 wrote:
Hi folks,
As I'm learning phobos, I wanted a more inside look and did a
co of the libs + dmd.
Try getti
On Saturday, 29 June 2013 at 15:03:05 UTC, Geod24 wrote:
Hi folks,
As I'm learning phobos, I wanted a more inside look and did a
co of the libs + dmd.
Try getting the latest druntime from git-head, since these
symbols were moved from phobos into druntime a few pull requests
ago.
Hi folks,
As I'm learning phobos, I wanted a more inside look and did a co
of the libs + dmd.
DMD compiles fine (using dmc), as well as druntime.
But when it comes to phobos, I'm not able to compile, I get:
[...]
DMD v2.064-devel-42b668b-dirty DEBUG
std.md5 is scheduled for deprecation. Please
On Saturday, 29 June 2013 at 14:20:05 UTC, Ali Çehreli wrote:
Not knowing whether it applies to your case, the following is
one almost correct way of writing opCmp:
int opCmp(ref const Vector3D vec) {
return cast(int)(x != vec.x
? x - vec.x
On Saturday, 29 June 2013 at 14:20:05 UTC, Ali Çehreli wrote:
On 06/29/2013 05:46 AM, snow wrote:
> On Friday, 28 June 2013 at 17:07:22 UTC, Ali Çehreli wrote:
>> Your opCmp does not provide a complete ordering of objects:
>>
>> int opCmp(ref const Vector3D vec) {
>> if (this.x > ve
On Saturday, 29 June 2013 at 12:58:51 UTC, Johannes Pfau wrote:
Am Sat, 29 Jun 2013 10:54:32 +0200
schrieb "Maxim Fomin" :
On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote:
> Am Fri, 28 Jun 2013 22:16:33 +0200
> schrieb Andrej Mitrovic :
>
>> On 6/28/13, Johannes Pfau wrote:
>> >
On 6/29/13, Johannes Pfau wrote:
> Shouldn't doing anything value-related on
> an empty struct be invalid anyway?
Maybe, maybe not. I could imagine it would cause problems if we simply
disallowed it, e.g. if you want to copy attributes from one
declaration to another.
On 06/29/2013 05:46 AM, snow wrote:
> On Friday, 28 June 2013 at 17:07:22 UTC, Ali Çehreli wrote:
>> Your opCmp does not provide a complete ordering of objects:
>>
>> int opCmp(ref const Vector3D vec) {
>> if (this.x > vec.x && this.y > vec.y && this.z > vec.z)
>> return
On Saturday, 29 June 2013 at 12:57:07 UTC, Namespace wrote:
I get this with -wi:
bug.d(5): Warning: explicit element-wise assignment
(test[0u])[] = false is bett
er than test[0u] = false
That helps a bit. But I thought that D dereferences
automatically? ;)
Only when making a function call (
monarch_dodra:
Related: I think this might actually give you a compiler
warning about doing a range assign without slicing? Bearophile
had suggested this shouldn't work unless you actually type:
"test[0][] = false;"
But I prefer:
"test[0] []= false;"
I can't test right now: Does your code emi
On Saturday, 29 June 2013 at 13:11:10 UTC, bearophile wrote:
monarch_dodra:
Related: I think this might actually give you a compiler
warning about doing a range assign without slicing? Bearophile
had suggested this shouldn't work unless you actually type:
"test[0][] = false;"
But I prefer:
"t
Am Sat, 29 Jun 2013 10:54:32 +0200
schrieb "Maxim Fomin" :
> On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote:
> > Am Fri, 28 Jun 2013 22:16:33 +0200
> > schrieb Andrej Mitrovic :
> >
> >> On 6/28/13, Johannes Pfau wrote:
> >> > A naive question: Why isn't struct S {} enough? This s
I get this with -wi:
bug.d(5): Warning: explicit element-wise assignment (test[0u])[]
= false is bett
er than test[0u] = false
That helps a bit. But I thought that D dereferences
automatically? ;)
On Saturday, 29 June 2013 at 12:41:12 UTC, Namespace wrote:
Is this a bug or is it just me? It seems that the compiler
dereference wrong.
import std.stdio;
void foo(bool[1]* test) {
if (test[0])
test[0] = false;
}
void main()
{
bool[1] test = false;
On Friday, 28 June 2013 at 17:07:22 UTC, Ali Çehreli wrote:
On 06/28/2013 07:00 AM, snow wrote:> Hello there,
> Ive got the following code
>
> http://dpaste.dzfl.pl/e391a268
>
> This code throws me a "Range Exception" in Algorithm.d.
>
> If I use a lower number of random vectors, like 100, the co
Is this a bug or is it just me? It seems that the compiler
dereference wrong.
import std.stdio;
void foo(bool[1]* test) {
if (test[0])
test[0] = false;
}
void main()
{
bool[1] test = false;
foo(&test);
}
prints: Error: expression test[0u] of typ
Could someone read over http://stackoverflow.com/a/17379444/969534
and tell me if I missed something and point out any grammatical mistakes
and fix them (if you have enough reputation to edit posts) or point them
out to me?
Thanks
Jacob Carlborg:
I remember someone someone modified DMD and added a .codeof
property or similar. It was fairly easy.
If there are enough use cases for it, then perhaps it's worth
putting both the enhancement request for ".codeof" and its
relative patch in Bugzilla.
Bye,
bearophile
On 2013-06-28 14:46, John Colvin wrote:
Is there any way of getting the body of a function as a string?
(Obviously only when the source code is available to the compiler)
I remember someone someone modified DMD and added a .codeof property or
similar. It was fairly easy.
--
/Jacob Carlborg
On 06/29/2013 11:42 AM, Joseph Rushton Wakeling wrote:
> I should add that bearophile has been fantastic in suggesting alternative
> design
> patterns that don't require either lockstep _or_ zip, but I still think this
> lockstep/zip discrepancy needs resolving.
According to the docs: zip "offers
On 06/28/2013 03:19 PM, Joseph Rushton Wakeling wrote:
> Consider the following equivalent code using zip and lockstep respectively to
> iterate over the entries in an array and set their values:
>
> auto arr1 = new double[10];
> foreach(i, ref x; zip(iota(10), arr1))
> {
> x =
On Saturday, 29 June 2013 at 08:01:17 UTC, Johannes Pfau wrote:
Am Fri, 28 Jun 2013 22:16:33 +0200
schrieb Andrej Mitrovic :
On 6/28/13, Johannes Pfau wrote:
> A naive question: Why isn't struct S {} enough? This should
> be a
> struct with size 0 so why do we need to disable the
> construct
Am Fri, 28 Jun 2013 22:16:33 +0200
schrieb Andrej Mitrovic :
> On 6/28/13, Johannes Pfau wrote:
> > A naive question: Why isn't struct S {} enough? This should be a
> > struct with size 0 so why do we need to disable the constructor and
> > postblit explicitly?
>
> Because the user should never
On Saturday, 29 June 2013 at 06:08:28 UTC, Jeremy DeHaan wrote:
I've been toying around with the idea of working on an IDE,
mostly because I think it would be an interesting/fun project
to work on. In any case, the only thing I cannot seem to wrap
my head around is how programs like Code Blocks
On Saturday, 29 June 2013 at 06:08:28 UTC, Jeremy DeHaan wrote:
I've been toying around with the idea of working on an IDE,
mostly because I think it would be an interesting/fun project
to work on. In any case, the only thing I cannot seem to wrap
my head around is how programs like Code Blocks
Oh, hey! I remember participating in writing some of that :)
Only Involved? You've written it. I've added only a few things. :)
42 matches
Mail list logo
