Re: D for web?
On Tuesday, 14 January 2014 at 16:30:10 UTC, ProgrammingGhost wrote: Is it possible to build websites using D? I know the website is written in D but there isn't a library for web that handles http request, parsing the page, query string etc? If you want a framework built on top of Vibe check out Cmsed[0]. Not yet ready for announcement but it basically comes down to write the odata support. [0] https://github.com/rikkimax/Cmsed
Re: Another purity question
Timon Gehr: Yes, it should. https://d.puremagic.com/issues/show_bug.cgi?id=9148 Thank you. I have added my (probably redundant) test case to that issue. Bye, bearophile
Re: Another purity question
On 01/14/2014 09:41 PM, David Nadlinger wrote: On Tuesday, 14 January 2014 at 20:36:43 UTC, Timon Gehr wrote: Yes, it should. https://d.puremagic.com/issues/show_bug.cgi?id=9148 And, of course, you are right. ;) I missed the analogy to member functions w.r.t. the implicit context parameter. Shame on me. David Well, if it wasn't easy to fall into this trap (and this is mostly due to terminology), DMD would actually behave correctly. :o)
Re: Another purity question
On Tuesday, 14 January 2014 at 20:36:43 UTC, Timon Gehr wrote: Yes, it should. https://d.puremagic.com/issues/show_bug.cgi?id=9148 And, of course, you are right. ;) I missed the analogy to member functions w.r.t. the implicit context parameter. Shame on me. David
Re: Another purity question
On 01/14/2014 08:50 PM, bearophile wrote:
Currently D refuses code like this:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
}
void main() {}
With two repeated error messages:
test1.d(3): Error: pure nested function 'bar' cannot access mutable data
'a'
test1.d(3): Error: pure nested function 'bar' cannot access mutable data
'a'
But is it possible for D to see that bar function as pure?
Bye,
bearophile
Yes, it should.
https://d.puremagic.com/issues/show_bug.cgi?id=9148
Re: Another purity question
On 01/14/2014 09:21 PM, David Nadlinger wrote:
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return &bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
---
David
int delegate()pure foo(const int[] a)pure{
struct S{
const int[] a;
int bar()pure{
return a[0];
}
}
auto s=S(a);
return &s.bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
Re: Another purity question
On Tuesday, 14 January 2014 at 20:21:25 UTC, David Nadlinger
wrote:
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return &bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
---
David
Isn't this okay in the context of weak purity?
Re: Another purity question
On Tuesday, 14 January 2014 at 20:21:25 UTC, David Nadlinger
wrote:
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return &bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
---
David
It's pure in the sense that it only modifies data passed to it?
Re: Another purity question
On Tuesday, 14 January 2014 at 19:50:10 UTC, bearophile wrote:
But is it possible for D to see that bar function as pure?
In the general case, no:
---
auto foo(const int[] a) {
int bar() {
return a[0];
}
return &bar;
}
void main() {
int[3] a;
auto dg = foo(a[]);
assert(dg() == 0);
a[0] = 1;
assert(dg() == 1);
}
---
David
Another purity question
Currently D refuses code like this:
void foo(const int[] a) {
int bar() pure {
return a[0];
}
}
void main() {}
With two repeated error messages:
test1.d(3): Error: pure nested function 'bar' cannot access
mutable data 'a'
test1.d(3): Error: pure nested function 'bar' cannot access
mutable data 'a'
But is it possible for D to see that bar function as pure?
Bye,
bearophile
Re: Adding object files to dub build?
On Monday, 13 January 2014 at 20:48:11 UTC, Jesse Phillips wrote: I have a pre-built sqlite3 object file which I'd like to include as part of the linking for the final executable. I have been unable to find a way to do this with dub. I have attempted adding: "sourceFiles": ["csqlite3.obj"], Utilizing sourceFiles works in 0.9.20 and newer.
Re: D for web?
On Tuesday, 14 January 2014 at 16:30:10 UTC, ProgrammingGhost wrote: Is it possible to build websites using D? I know the website is written in D but there isn't a library for web that handles http request, parsing the page, query string etc? http://vibed.org does such stuff and much more on top of it. Vladimir's talk from last DConf mentions it : http://dconf.org/2013/talks/panteleev.html
Re: D for web?
ProgrammingGhost: Is it possible to build websites using D? I know the website is written in D but there isn't a library for web that handles http request, parsing the page, query string etc? Take a look here: http://vibed.org/ Bye, bearophile
Re: D for web?
you were faster :D
D for web?
Is it possible to build websites using D? I know the website is written in D but there isn't a library for web that handles http request, parsing the page, query string etc?
Re: D for web?
there is vibe.d! look at the dconf2013 for a presentation about it and get it at vibed.org
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 12:58:04 UTC, Mike Parker wrote: On 1/14/2014 9:55 PM, Mike Parker wrote: That way, initGL does not depend on the window already being created. Actually, scratch that. DerelictGL3.reload does depend on the context already being created. However, the call to glfwMakeContextCurrent still should be in the same spot you create the window. Ahhh thank you, I'm currently away from my computer so I couldn't do much as far as my code goes, but I'll certainly do all of that, I always have trouble with functions and function pointers haha. :P
Re: Shared library string safety?
On 1/14/2014 9:55 PM, Mike Parker wrote: That way, initGL does not depend on the window already being created. Actually, scratch that. DerelictGL3.reload does depend on the context already being created. However, the call to glfwMakeContextCurrent still should be in the same spot you create the window.
Re: Shared library string safety?
On 1/14/2014 9:10 PM, Mineko wrote:
Perhaps I should be using () with GLFW3.load and glfwInit?
Yes, please do this. For DerelictGLFW3.load, it's just a matter of style
and doesn't make a difference. However, glfwInit is a *function
pointer*, not a function.. So what you're effectively doing there is
testing if the function pointer is null or not. You aren't actually
calling the function. Since you already called DerelictGLFW3.load, then
it obviously isn't null, so your method completes and returns true. Then
later, when you call glfwCreateWindow, since the library was never
initialized, it returns null.
You could have saved yourself a lot of time by using an error callback
as recommended earlier in this thread. And you should set the callback
between DerelictGLFW3.load and glfwInit.
extern(C) nothrow void onErr(int code, const(char)* msg)
{
// log the message, but be aware that you may need to wrap
// it in a try...catch block, since the callback has to be
// nothrow.
}
auto initGLFW()
{
import breaker.main : timer;
DerelictGLFW3.load;
glfwSetErrorCallback( &onErr );
// Add the parens here
if ( !glfwInit() )
return false;
timer.time = 0.0001;
return true;
}
Do this and you'll get an error message if any glfw function call fails.
And always keep in mind that when using Derelict, the library functions
you call are all function pointers. That means this function:
auto glfwTerm() {return glfwTerminate;}
Is returning a function pointer. It isn't calling anything. You need to
add parens here, too. In fact, I strongly recommend you use parens
everywhere unless you are calling properties. Speaking of which, why
would you make glfwTerm a property?
One more bit of advice. In initGL, you have this:
DerelictGL3.load;
glfwMakeContextCurrent(window.get);
DerelictGL3.reload;
The call to glfwMakeContextCurrent doesn't need to be there. For ease of
maintenance, I suggest you move it to the method where you call
glfwCreateWindow. That way, initGL does not depend on the window already
being created. You don't need to load DerelictGL3 before calling it.
I'll try a static loading though, sure.
This won't make a difference.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 09:35:11 UTC, evilrat wrote:
On Tuesday, 14 January 2014 at 07:44:21 UTC, Mineko wrote:
this.get = glfwCreateWindow(settings.width, settings.height,
toStringz(settings.title), this.monitor, this.share);
writeln(this.get);
That writeln will give me null, is it related to all this
stuff?
i've looked up in your sources on github and not found derelict
initiliazation. i recommend loading glfw in relevant module
with module ctor. most if non all derelict bindings has dynamic
loading, don't forget to load and init derelict 'plugins' if
necessary.
module window;
static this()
{
DerelictGLFW.load();
}
class Window
{
... using GLFW here ...
}
--
I'm pretty sure it's initialized here:
https://github.com/MinekoRox/Breaker-Engine/blob/master/src/breaker/utility/belt.d
/** Initialize GLFW */
auto initGLFW()
{
import breaker.main : timer;
DerelictGLFW3.load;
if (!glfwInit)
return false;
timer.time = 0.0001;
return true;
}
Perhaps I should be using () with GLFW3.load and glfwInit?
I'll try a static loading though, sure.
Re: Why is string.front dchar?
On Monday, 13 January 2014 at 23:10:04 UTC, TheFlyingFiddle wrote: I'm curious, why is the .front property of narrow strings of type dchar? And not the underlying character type for the string. The root of the issue is that string literals containing characters which do not fit into signle byte are still converted to char[] array. This is strictly speaking not type safe because it allows to reinterpret 2 or 4 byte code unit as sequence of characters of 1 byte size. The string type is in some sense problematic in D. That's why the fact that .front returns dhcar is a way to correct the problem, it is not an attempt to introduce confusion.
Re: std.xml
On 2014-01-14 09:57, "Ola Fosheim Grøstad" " wrote: I want to read XML files and replace the nodes I care about (shapes and transforms) with my own version so that I more easily can manipulate it (using a more efficient internal representation). The kxml library appears have a node class, so maybe that is the better option. The Tango XML parser is one of the fastest XML parser available: http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/ -- /Jacob Carlborg
Re: Why is string.front dchar?
And a short overview over Unicode in D: http://qznc.github.io/d-tut/unicode.html
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 07:44:21 UTC, Mineko wrote:
this.get = glfwCreateWindow(settings.width, settings.height,
toStringz(settings.title), this.monitor, this.share);
writeln(this.get);
That writeln will give me null, is it related to all this stuff?
i've looked up in your sources on github and not found derelict
initiliazation. i recommend loading glfw in relevant module with
module ctor. most if non all derelict bindings has dynamic
loading, don't forget to load and init derelict 'plugins' if
necessary.
module window;
static this()
{
DerelictGLFW.load();
}
class Window
{
... using GLFW here ...
}
--
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 07:44:21 UTC, Mineko wrote:
I see, I'll have to look more into that, on a slightly
unrelated note, any idea what's going on with glfwCreateWindow,
it keeps wanting to be null while it's supposed to be an
adddress.
this.get = glfwCreateWindow(settings.width, settings.height,
toStringz(settings.title), this.monitor, this.share);
writeln(this.get);
glfwCreateWindow returns a null ptr if something is wrong with
it's parameters or os driver or anything it can detect really. To
get error information you can use glfwSetErrorCallback with a
custom function and handle the errors with it.
Something like this:
extern(C) void errorFunc(int error_code, const(char)*
errorMessage)
{
//Do something here like wrilteln.
}
void main()
{
//Load libs and setup stuff.
glfwSetErrorCallback(&errorFunc);
//Now anything that gives an error will forward it to
//errorFunc.
}
That writeln will give me null, is it related to all this stuff?
I doubt it.
Re: std.xml
On Monday, 13 January 2014 at 19:54:22 UTC, Jacob Carlborg wrote: I'm not sure what you're trying to do but the implementation in Tango uses structs for the nodes so you cannot subclass that. I want to read XML files and replace the nodes I care about (shapes and transforms) with my own version so that I more easily can manipulate it (using a more efficient internal representation). The kxml library appears have a node class, so maybe that is the better option.
Re: Shared library string safety?
On Tuesday, 14 January 2014 at 07:44:21 UTC, Mineko wrote: I see, I'll have to look more into that, on a slightly unrelated note, any idea what's going on with glfwCreateWindow, it keeps wanting to be null while it's supposed to be an adddress. this.get = glfwCreateWindow(settings.width, settings.height, toStringz(settings.title), this.monitor, this.share); writeln(this.get); That writeln will give me null, is it related to all this stuff? are you using derelict for this? do you really need fullscreen and sharing contexts? try to call this to get non-fullscreen window without sharing (just peronal, but also it may be a bit more readeble using UFCS on toStringz) this.get = glfwCreateWindow(settings.width, settings.height, settings.title.toStringz(), null, null); if that work for you then problem is due to sharing which may require context(which you probably don't have or trying to share with itself), or due to driver issues related to fullscreen mode if on linux, but i'm unsure about the later.
