Re: string-int[] array
On Sun, 08 Mar 2015 18:57:37 +, Kagamin wrote: > http://dpaste.dzfl.pl/2c8d4a7d9ef0 like this. i hate annoying beginners too, but not to SUCH extent. signature.asc Description: PGP signature
Re: how to read some in vibe.d tcpconnection?
On Sunday, 8 March 2015 at 13:56:37 UTC, Kagamin wrote: On Sunday, 8 March 2015 at 03:09:00 UTC, zhmt wrote: Yes, this a good idea, if the author of vibe.d do this, will be better, it is used frequently in many scenes. You can do it too, unlike in C++, in D you can write extension methods to any type, as long as they are visible, you can call them on the first argument, it's called UFCS: http://dlang.org/function.html#pseudo-member This is a good idea. I take it. Thank u very much, you are so kind.
Re: Dub + Optlink == ???
On Sunday, 8 March 2015 at 23:05:53 UTC, David Held wrote:
On 3/8/2015 3:55 PM, David Held wrote:
Since DDT (Eclipse plugin) uses Dub, I am trying to convert
the DWT
build instructions into Dub. Here is my current attempt:
{
"name" : "foo",
"description" : "foo",
"importPaths" : [ "d:/workspace/dwt/imp" ],
"stringImportPaths" : [
"D:/workspace/dwt/org.eclipse.swt.win32.win32.x86/res" ],
"lflags" : [
"-L+D:/workspace/dwt/lib",
"-L/SUBSYSTEM:WINDOWS:4.0"
],
"libs" : [
"org.eclipse.swt.win32.win32.x86",
"dwt-base"
]
}
[...]
Figured it out. Even though lflags is a string[], the strings
get concatenated with no spaces. :/ This works:
"lflags" : [
"-L+..\\dwt\\lib\\ -L/SUBSYSTEM:WINDOWS:4.0"
],
Dave
Seems like a bug on dubs part?
Re: Derelict Assimp not loading mesh properly? (Maybe index buffer)
On Friday, 6 March 2015 at 02:41:19 UTC, Bennet wrote:
I wrote a custom OBJ file importer which worked fairly well
however was not robust enough to support everything. I've
decided to give AssImp a shot. I followed some tutorials and
have set up my code to read in the vertices, tex coords,
normals, and indices of an OBJ cube model that I have had
success loading with my custom importer. The cube model's faces
do not render properly, instead only rendering a few tri's of
the cube. The way AssImp handles the data is obviously a bit
different than my solution because the normals,
positions/vertices, tex coords, and indices do not match my
custom solution. I would very much appreciate some insight into
why I'm having issues as all of the tutorials I've found have
matched my approach. If a picture of the faulty rendered cube
would be helpful I can work on getting a screenshot up. Thank
you.
My Asset importing class is at:
http://codebin.org/view/4d2ec4d3
The rest of my code is at (Mesh Class is in source/graphics):
https://github.com/BennetLeff/PhySim
Imagine a square mesh made up of two triangles, the un-indexed
version has 6 vertices, but the indexed version that you would be
using has 4 vertices because a side is shared by the two
triangles (which is managed by the index array). This is why you
can't assume each face has 3 vertices.
I have been trying to learn opengl and D recently together and
this is the simple code I have been using to load models from
assimp.
for(int i = 0; i < mesh.mNumVertices; i++)
{
aiVector3D vert = mesh.mVertices[i];
verts ~= vec3(vert.x, vert.y, vert.z);
aiVector3D uvw = mesh.mTextureCoords[0][i];
uvs ~= vec2(uvw.x, uvw.y);
aiVector3D n = mesh.mNormals[i];
normals ~= vec3(n.x, n.y, n.z);
}
for(int i = 0; i < mesh.mNumFaces; i++)
{
const aiFace face = mesh.mFaces[i];
indices ~= face.mIndices[0];
indices ~= face.mIndices[1];
indices ~= face.mIndices[2];
}
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
Please confirm or deny that this is a real bug, as its getting in the way of a genuine project. How should I proceed? I'm working on a 64-bit Windows port of the following. http://www.cs.arizona.edu/icon/ Here's the 32-bit Windows port. http://www.cs.arizona.edu/icon/v95w.htm Among other things I'm using D to implement Icon's coexpressions portably using core.thread.Fiber which works fine at 32 bits. They are implemented using pthreads on other platforms, though historically there used to be a platform dependent assembly code context switch, close to the way that core.thread.Fiber is implemented. The Fiber implementation is 20 times faster at 32 bits.
Re: std.stdio.writeln
On Monday, 9 March 2015 at 14:38:41 UTC, Dennis Ritchie wrote: (1, 2, 3).writeln; // prints 3 that's not an array, use [1,2,3] for that. What you wrote is a parenthesis expression with comma expressions inside. The comma operator is a bit weird: it works like a semicolon, but in different contexts. So 1,2,3, in this context, means "calculate 1, then calculate 2, then calculate 3, the result is the final one: 3". The 1 and 2 are just discarded because their calculations don't save anything outside.
std.stdio.writeln
Hi.
Why prints only the last element?
import std.stdio;
void main() {
(1, 2, 3).writeln; // prints 3
}
Re: std.stdio.writeln
On Monday, 9 March 2015 at 14:38:41 UTC, Dennis Ritchie wrote:
Hi.
Why prints only the last element?
import std.stdio;
void main() {
(1, 2, 3).writeln; // prints 3
}
I think this is a misunderstanding about UFCS.
1.writeln(2, 3);
is the same as
writeln(1, 2, 3);
and the same as
(1).writeln(2, 3);
but
(1, 2, 3).writeln;
is completely different. UFCS is only for the first argument.
Yet another excellent example of why we should abolish the comma
operator in D.
Re: std.stdio.writeln
On Monday, 9 March 2015 at 14:42:35 UTC, Adam D. Ruppe wrote: On Monday, 9 March 2015 at 14:38:41 UTC, Dennis Ritchie wrote: (1, 2, 3).writeln; // prints 3 that's not an array, use [1,2,3] for that. What you wrote is a parenthesis expression with comma expressions inside. The comma operator is a bit weird: it works like a semicolon, but in different contexts. So 1,2,3, in this context, means "calculate 1, then calculate 2, then calculate 3, the result is the final one: 3". The 1 and 2 are just discarded because their calculations don't save anything outside. Thanks. On Monday, 9 March 2015 at 14:48:20 UTC, John Colvin wrote: I think this is a misunderstanding about UFCS. Yes.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Monday, 9 March 2015 at 14:39:34 UTC, Carl Sturtivant wrote: Please confirm or deny that this is a real bug, as its getting in the way of a genuine project. How should I proceed? I'm working on a 64-bit Windows port of the following. http://www.cs.arizona.edu/icon/ Here's the 32-bit Windows port. http://www.cs.arizona.edu/icon/v95w.htm Among other things I'm using D to implement Icon's coexpressions portably using core.thread.Fiber which works fine at 32 bits. They are implemented using pthreads on other platforms, though historically there used to be a platform dependent assembly code context switch, close to the way that core.thread.Fiber is implemented. The Fiber implementation is 20 times faster at 32 bits. I can reproduce this issue with dmd 2.066.1, please go forward and open a issue on https://issues.dlang.org/ Kind Regards Benjamin Thaut
Re: std.stdio.writeln
On Mon, 09 Mar 2015 14:48:19 +, John Colvin wrote: > Yet another excellent example of why we should abolish the comma > operator in D. or at least warn about it. producing a warning for such expression will ring a bell in programmers head: "compiler is unhappy. i definitely doing something wrong here!" signature.asc Description: PGP signature
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
I can reproduce this issue with dmd 2.066.1, please go forward and open a issue on https://issues.dlang.org/ Kind Regards Benjamin Thaut Thank you; will do.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Sunday, 8 March 2015 at 18:18:49 UTC, Carl Sturtivant wrote: Should I be doing something special with linkage so this works? What is going on? IIRC there are some fixes to the Win64 context switching code in the 2.067 or master druntime. You might want to try those first before spending more time tracking this down. — David
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
With the newest beta everything seems to work fine. http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
On Monday, 9 March 2015 at 17:00:38 UTC, Jacques Müller wrote: With the newest beta everything seems to work fine. http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com That's great news! Thank you.
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
IIRC there are some fixes to the Win64 context switching code in the 2.067 or master druntime. You might want to try those first before spending more time tracking this down. Great, and thanks.
Re: std.stdio.writeln
On Monday, March 09, 2015 15:45:58 ketmar via Digitalmars-d-learn wrote: > On Mon, 09 Mar 2015 14:48:19 +, John Colvin wrote: > > > Yet another excellent example of why we should abolish the comma > > operator in D. > > or at least warn about it. producing a warning for such expression will > ring a bell in programmers head: "compiler is unhappy. i definitely doing > something wrong here!" There's not much point in that. If someone is using the comma operator correctly, then the warnings would be incredibly annoying. And if we value avoiding comma operator-related bugs over letting folks take advantage of its usefulness enough to consider such a warning, we might as well just deprecate the comma operator and move towards removing it from the language. Either it's there and useful but error-prone, or it's gone. In between just annoys both groups. - Jonathan M Davis
Re: Seems core.thread.Fiber is broken dmd windows 64-bit build
http://forum.dlang.org/thread/md5kq0$8au$1...@digitalmars.com Got a working build at 64 bits using the 2.067 beta 3. Delighted.
Re: std.stdio.writeln
On Mon, 09 Mar 2015 13:18:58 -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > On Monday, March 09, 2015 15:45:58 ketmar via Digitalmars-d-learn wrote: >> On Mon, 09 Mar 2015 14:48:19 +, John Colvin wrote: >> >> > Yet another excellent example of why we should abolish the comma >> > operator in D. >> >> or at least warn about it. producing a warning for such expression will >> ring a bell in programmers head: "compiler is unhappy. i definitely >> doing something wrong here!" > > There's not much point in that. If someone is using the comma operator > correctly, then the warnings would be incredibly annoying. And if we > value avoiding comma operator-related bugs over letting folks take > advantage of its usefulness enough to consider such a warning, we might > as well just deprecate the comma operator and move towards removing it > from the language. > Either it's there and useful but error-prone, or it's gone. In between > just annoys both groups. i remember that deprecation was rejected. maybe this is false memory, though. btw, there are legit uses of comma, in c-style `for`, for example. this should be left intact, i think (oh, can c-style `for` be deprecated too?! ). signature.asc Description: PGP signature
How does laziness and UFCS interact?
I just became aware of
http://dlang.org/phobos/std_exception.html#.ifThrown . It's neat,
but it seems non-obvious to me how lazy + UFCS should work in
general.
consider
void lazily(T)(lazy T expression)
{
expression();
}
It's clear when saying lazily(a.b().c()); that the whole of
"a.b().c()" is going to be evaluated lazily. With UFCS though,
I'm more unsure:
is a.b().c().lazily() -> lazily(a.b().c()) or is it more akin to
auto tmp = a.b();
lazily(tmp.c());
If the later is it possible to force the former while still using
UFCS, ie is (a.b().c()).lazily() different than
a.b().c().lazily()?
Re: How does laziness and UFCS interact?
On 03/09/2015 03:03 PM, Logan Capaldo wrote:
I just became aware of
http://dlang.org/phobos/std_exception.html#.ifThrown . It's neat, but it
seems non-obvious to me how lazy + UFCS should work in general.
consider
void lazily(T)(lazy T expression)
{
expression();
}
It's clear when saying lazily(a.b().c()); that the whole of "a.b().c()"
is going to be evaluated lazily. With UFCS though, I'm more unsure:
is a.b().c().lazily() -> lazily(a.b().c()) or is it more akin to
auto tmp = a.b();
lazily(tmp.c());
If the later is it possible to force the former while still using UFCS,
ie is (a.b().c()).lazily() different than a.b().c().lazily()?
You are right. I had the same observation at minute 11:27 below, where I
warn against UFCS with assumeWontThrow:
http://www.youtube.com/watch?feature=player_detailpage&v=oF8K4-bieaw#t=687
Ali
Re: std.stdio.writeln
On Monday, 9 March 2015 at 22:00:46 UTC, ketmar wrote: i remember that deprecation was rejected. maybe this is false memory, though. btw, there are legit uses of comma, in c-style `for`, for example. this should be left intact, i think (oh, can c-style `for` be deprecated too?! ). I think the last time there was a big discussion about this everyone agreed that the comma operator in a for loop was acceptable.
