>> I was curious too, so found in Section 7.1.5.1 the description of
>> opAssign using a swap. That explains it I think.
Section 7.1.5.1 does not apply because it concerns the case where you define
your own
overload of the assignment operator. In my example the default assignment is
used.
The
yOn Sat, 9 Apr 2011 14:54:55 -0700
Jonathan M Davis wrote:
> So, yeah, it sucks that dmd is only a 32-bit binary, and there are
> currently no plans for it become a 64-bit binary,
It's really strange to have 32bit executable on 64bit OS these days
and I?m running 64bit OS for years.
> Most 64-
bearophile wrote:
> More little tasks for your module:
> http://rosettacode.org/wiki/Fractal_tree#Python
This one's use of recursion caused me to hit what I think is a
compiler bug. Not in the recursion itself, but in a struct's
copy constructor when it had a significant mixin.
I worked around it
Jonathan M Davis Wrote:
> How stable is SQLite's API? If they put out SQLite 3.7.6, will any of the
> bindings then be invalid?
Well, from 3.7.3 to 3.7.5 I added a few enum values and a couple functions. I'd
say SQLite has a fairly stable API.
That said, I did what zlib did and included the s
One thing to consider, since I was impacted by this when writing a WPF app a
while back, is the difference between a 2-Vector and a Point. In
particular, Vectors typically have some very useful methods on them, like
addition, rotation, transformations, etc. which frequently are not
associated with
bearophile wrote:
> The length=150 too is better to be set as immutable.
Yeah, I made that change after copy/pasting the code into my
newsgroup post. win, painter, angle, and angular velocity were
the only things left mutable in the end.
> The delegate inside eventLoop doesn't need the ().
I put
On 09/04/2011 22:58, Jonathan M Davis wrote:
So how, exactly, does the runtime get at data that doesn't exist?
Every time that you use an enum, it's replaced with the enum's value. So, it's
like you put a literal there which was identtical to the enum's value. So,
That's what I'd made out p
On 4/9/2011 2:54 PM, Jonathan M Davis wrote:
>> On Sat, 9 Apr 2011 01:26:49 + (UTC)
>>
>> Jesse Phillips wrote:
>>> There is not plan to have dmd a 64bit executable. There have been
>>> reports that you can get it to build but support for it does not
>>> exist. However if you are interested in
Adam D. Ruppe:
> Here's the D version using the direct to screen functions.
More little tasks for your module:
http://rosettacode.org/wiki/Fractal_tree#Python
http://rosettacode.org/wiki/Brownian_tree
The JavaScript processing port site has some more examples in the Demos section:
http://process
Adam D. Ruppe:
> Here's the D version using the direct to screen functions.
On Windows Vista the window often doesn't close when I hit the close window
click at the top right.
Probably quite more people will have to comment and think about this module and
its API before adopting it.
The lengt
Couldn't you also just have your mixin define a function which - as a nested
function - would have access to the stack of the enclosing block? Slightly
less pretty, and slightly different (since variables declared in the mixin
wouldn't exist in the enclosing scope)... ok, yeah, rather different.
> I have a branch of Phobos which includes SQLite 3.7.5 and its bindings
> for D. I have updated the posix.mak to include this when building.
>
> I am posting here at this time to prevent duplicate effort and give a
> heads up that I won't be able to test this for Mac or BSD. I would also
> like t
> Sorry. It was late and I forgot to mention some things. A) My code is
> dependent on patch 5155, and B) I forgot about
changes, etc, that I had to make to go from DMD 2.051 to DMD 2.052. I've
uploaded my current working copy and remade the
docs. Let me know if you have any issues with this. (An
> If they're evaluated at the instantiation scope, and not in the point of
> definition, then why are statements disallowed?
>
> Where does the limitation come from?
Probably because statements are only valid in functions, and a template is a
set of declarations. It certainly wouldn't make any s
> On 06/04/2011 16:24, Don wrote:
>
>
> > No. NONE exist at run time. That is the whole point. No enum should ever
> > exist in the compiler. That's the only difference between immutable and
> > enum.
>
>
>
> So how, exactly, does the runtime get at data that doesn't exist?
Every time that yo
> On Sat, 9 Apr 2011 01:26:49 + (UTC)
>
> Jesse Phillips wrote:
> > There is not plan to have dmd a 64bit executable. There have been
> > reports that you can get it to build but support for it does not
> > exist. However if you are interested in writing 64bit programs the
> > 32bit version c
bearophile wrote:
> http://rosettacode.org/wiki/Animate_a_pendulum
Here's the D version using the direct to screen functions. I
ported the C# version, since the APIs were most alike. (Not
really surprising... C# and I both thinly wrapped GDI.)
===
import std.math;
import simpledisplay;
void mai
Hmm, I'm getting an error compiling dmd for Windows in wine. And 2.053 is
needed to build druntime/phobos...
make -fwin32.mak C=backend TK=tk ROOT=root OPT= "DEBUG=-D -g -DUNITTEST"
LFLAGS=-L/ma/co dmd.exe
C:\dm\bin\dmc -c -Ibackend;tk -DMARS -cpp -D -g -DUNITTEST -e -wx -D_DH -
I. backend\cg
It's the same with GDC as is with DMD, just checked.
"Andrej Mitrovic" wrote in message
news:mailman.3303.1302360951.4748.digitalmar...@puremagic.com...
> On 4/9/11, spir wrote:
>> I prefere structs to tuples /everywhere/. They have 2 big advantages:
>> * explicite: color.red versus color[0]
>
> But Tuples _are_ structs. And you _can_ use explicit
I have a branch of Phobos which includes SQLite 3.7.5 and its bindings
for D. I have updated the posix.mak to include this when building.
I am posting here at this time to prevent duplicate effort and give a
heads up that I won't be able to test this for Mac or BSD. I would also
like to know wh
The next version of dmd will contain a number of bug fixes for struct ctor/dtor
and lifetime management issues. Unless
you're testing with the most current dmd code in git, I'd hold off.
On 4/9/2011 8:01 AM, Jason House wrote:
> I agree that the output ordering does not make sense. Try altering
If they're evaluated at the instantiation scope, and not in the point of
definition, then why are statements disallowed?
Where does the limitation come from?
No I was wondering if a different compiler would treat the assignment of &g
to f as needing to generate a conversion from int* to int internally (which
I think is what Timon was expecting?), or if it would generate an error
because the signature of f does not match the signature of g (which is what
I'm using DMD 2.052. Why, are you allowed to declare delegates with ref returns?
Which compiler are you using? Have you tried a different one?
On Sat, Apr 9, 2011 at 10:55 AM, Andrej Mitrovic wrote:
> Interesting. The problem I think is that the delegate is declared as
> returning int, not ref int. I don't even think we can specify ref as
> the return value of a delegate. B
Interesting. The problem I think is that the delegate is declared as
returning int, not ref int. I don't even think we can specify ref as
the return value of a delegate. But if you try to declare the delegate
as returning an int*, you get this nice error:
Error: cannot implicitly convert expressio
It looks like in the absence of an assignment of the output of g() to some
value (say int b = g()) which the compiler would insert conversion code for,
the ref is retaining some pointer semantics. I'm guessing that because
writeln is variadic the compiler doesn't do anything with g's output (like
Morlan writes:
> It sounds reasonable. But I cannot find information about this
> behaviour in the Language Reference or TDPL book. Can you point to a
> relevant source?
I was curious too, so found in Section 7.1.5.1 the description of
opAssign using a swap. That explains it I think.
Whats the output of the following code supposed to be?
import std.stdio;
int a=0;
ref int g(){
writeln("called g");
return ++a;
}
void main(){
int function() f=&g;
writeln(cast(int)&a);
writeln(f());
writeln(f());
writeln(f());
}
The output using dmd 2.052
-144918776
On Sat, 09 Apr 2011 04:07:11 -0400, %u wrote:
Thanks for the link!
I tried compiling the file, and I got these errors:
variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(634): Wa
Yeah, I'm certainly not suggesting you necessarily rip off implementation,
just possibly API design. But to be fair it has been a while since I used
that API - maybe the design is crap by comparison to others these days.
OpenGL or DirectX for quick rendering is definitely the way to go under the
I thought a lot about the project, the possibility to switch to
other topics and why I really want to work on containers. So I wrote
to Ishan (I don’t know the other students) and we discussed all day
long. It was a fulfilling and positiv conversation with a clear
result:
We both would like to work
We have three more mentors joining: David Simcha, Tomek Sowiński, and
Jens Mueller.
(I'd already mentioned David's approval but only as a reply to another
message, an oversight that this attempts to fix.)
David, Tomek, and Jens bring tremendous value and broad expertise to our
mentor ranks.
On 4/9/11 9:24 AM, Andrei Alexandrescu wrote:
http://www.youtube.com/watch?v=QXJB7TXhbHc
Andrei
Thanks for posting to reddit:
http://www.reddit.com/r/programming/comments/gm6p2/interview_with_andrei_alexandrescu_on_the_d/
Andrei
On 4/9/11 10:02 AM, Andrej Mitrovic wrote:
I've added an interviews section:
http://prowiki.org/wiki4d/wiki.cgi?Videos#Interviews
Speaking of which, has anyone else been interviewed on video? What about Walter?
I have one more interview:
http://www.youtube.com/watch?v=WZqWGfv7bxw
Andrei
Matthias Pleh:
> I hope, I will find time this weekend, clean it up and post it here.
> Maybe Adam then could add it to his source.
Cool!
On 06/04/2011 16:24, Don wrote:
No. NONE exist at run time. That is the whole point. No enum should ever exist
in the
compiler. That's the only difference between immutable and enum.
So how, exactly, does the runtime get at data that doesn't exist?
Stewart.
On Fri, Apr 08, 2011 at 09:50:11PM -0700, Cliff Hudson wrote:
> So is the objective to create a windowing library, or a drawing library for
> (for example) games?
Drawing. I have a windowing library in the works too, but it's much much
more effort (even building off existing ones!) so it won't be
I've added an interviews section:
http://prowiki.org/wiki4d/wiki.cgi?Videos#Interviews
Speaking of which, has anyone else been interviewed on video? What about Walter?
I agree that the output ordering does not make sense. Try altering your example
slightly so the program will segfault or do some other nonsensical thing if
that is truly the order of operations. Once you have that, it'd make a great
bugzilla entry! It definitely looks like a bug to me.
Morlan W
On 4/9/11, spir wrote:
> I prefere structs to tuples /everywhere/. They have 2 big advantages:
> * explicite: color.red versus color[0]
But Tuples _are_ structs. And you _can_ use explicit names:
http://codepad.org/0ZWAtcL1
On 4/9/2011 9:49 AM, Andrei Alexandrescu wrote:
On 4/9/11 7:02 AM, Jens Mueller wrote:
4. Is each mentor supposed to review all of the proposals, or just
the ones in his/her domain that he/she feels qualified to evaluate?
For example, I feel very comfortable reviewing a proposal about
garbage co
It sounds reasonable. But I cannot find information about this behaviour in the
Language Reference or TDPL book. Can you point to a relevant source?
http://www.youtube.com/watch?v=QXJB7TXhbHc
Andrei
On 04/09/2011 11:07 AM, Caligo wrote:
There is no such thing as base 1 number system. Stop wasting your time.
lol!
--
_
vita es estrany
spir.wikidot.com
On 04/09/2011 06:50 AM, Cliff Hudson wrote:
So is the objective to create a windowing library, or a drawing library for
(for example) games? The two are rather different - though you can build a
windowing library on top of a drawing library, doing so is pointless given
the plethora of GUI librar
On 04/09/2011 02:42 AM, Adam D. Ruppe wrote:
OK. (But for this module I think usage simplicity is more
> important than raw speed.
The struct is at least equal in simplicity:
image[x, y] = Color(r, g, b);
vs
image[x, y] = tuple(r, g, b);
Indeed; and then:
image[x, y].g
versus
image
On 4/9/11 7:02 AM, Jens Mueller wrote:
4. Is each mentor supposed to review all of the proposals, or just
the ones in his/her domain that he/she feels qualified to evaluate?
For example, I feel very comfortable reviewing a proposal about
garbage collection or containers, but I would have little
== Quote from dsimcha (dsim...@yahoo.com)'s article
> == Quote from Iain Buclaw (ibuc...@ubuntu.com)'s article
> > On top of that, GCC targets will (*WIP*) be using builtin atomic load/cas
> > routines
> > for architectures that support. And I'm pretty certain LDC does the same (I
> > believe it's
On 04/09/2011 12:42 PM, Morlan wrote:
The essence of my problem is why is the destructor called as a
result of the assignment in the first place? There is no
information about this behaviour in the language reference. Can
anyone explain this?
Because you assign a copy of s2 to s1 the struct tha
Am 09.04.2011 13:11, schrieb Michel Fortin:
On 2011-04-08 22:31:11 -0400, Matthias Pleh said:
For the drawingt part. I'm currently working on a rednerer with
scanline algorithm. This will be completly OS-independent. It's in a
single file with 2kLOC, and rather low level drawing. I just render
dsimcha wrote:
> On 4/8/2011 2:43 PM, Andrei Alexandrescu wrote:
> >On 4/8/11 11:35 AM, Luca Boasso wrote:
> >>Who is going to interview the students?
> >>Will the mentor interested in the student be the interviewer or a
> >>selected group of the community?
> >
> >I plan to interview qualified cand
On 2011-04-08 22:31:11 -0400, Matthias Pleh said:
For the drawingt part. I'm currently working on a rednerer with
scanline algorithm. This will be completly OS-independent. It's in a
single file with 2kLOC, and rather low level drawing. I just render on
a simple ubyte-array, but it already su
The essence of my problem is why is the destructor called as a
result of the assignment in the first place? There is no
information about this behaviour in the language reference. Can
anyone explain this?
Am 09.04.2011 11:47, schrieb spir:
On 04/09/2011 10:00 AM, Morlan wrote:
The following code:
//***
import std.conv, std.stdio;
struct Slice {
int[] buff;
this(size_t len) {
buff = new int[len];
}
this(this) {
buff = buff.dup;
writeln("postblit");
On 04/09/2011 10:00 AM, Morlan wrote:
The following code:
//***
import std.conv, std.stdio;
struct Slice {
int[] buff;
this(size_t len) {
buff = new int[len];
}
this(this) {
buff = bu
On 04/09/2011 03:30 AM, Adam D. Ruppe wrote:
bearophile wrote:
> With Color is becomes something like:
> foreach (col; zip(reds, greens, blues))
> image[x, y] = Color(col.tupleof);
That looks perfectly acceptable to me.
I might add an overload so opIndex can take a tuple too though,
so
There is no such thing as base 1 number system. Stop wasting your time.
Thanks for the link!
I tried compiling the file, and I got these errors:
variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(454): Warning: statement is not reachable
variant.d(634): Warning: statement is not reachable
variant.d(660):
The following code:
//***
import std.conv, std.stdio;
struct Slice {
int[] buff;
this(size_t len) {
buff = new int[len];
}
this(this) {
buff = buff.dup;
writeln("postbli
Am 09.04.2011 09:34, schrieb Gour-Gadadhara Dasa:
> On Sat, 9 Apr 2011 01:26:49 + (UTC)
> Jesse Phillips wrote:
>
>> There is not plan to have dmd a 64bit executable. There have been
>> reports that you can get it to build but support for it does not
>> exist. However if you are interested in
On Sat, 9 Apr 2011 01:26:49 + (UTC)
Jesse Phillips wrote:
> There is not plan to have dmd a 64bit executable. There have been
> reports that you can get it to build but support for it does not
> exist. However if you are interested in writing 64bit programs the
> 32bit version can still produ
63 matches
Mail list logo
