Hello,
I have a few methods that I want to put into a library but I'm
having some trouble figuring out how to go about doing it...
Here is my "library":
// world.d
module world;
import std.traits;
T hello(T)(T name) /* probably want a string constraint here...
*/ {
return "hello " ~ name;
On Saturday, 28 April 2012 at 00:04:05 UTC, Joseph Rushton
Wakeling wrote:
On 28/04/12 00:29, Era Scarecrow wrote:
At the off chance it's shallow copying, this should remove
that.
Ahhh, that works. Thank you!
... because I found I got about a 2s speedup. It's exactly the
speedup which was
On 4/27/12, Andrej Mitrovic wrote:
>
I am such an idiot, I've already asked this before. And Vlad gave me a
perfectly good answer the last time:
if (!GetConsoleWindow()) {
stdout.open("stdout.log", "w");
stderr.open("stderr.log", "w");
}
On Saturday, April 28, 2012 01:26:38 Era Scarecrow wrote:
> On Friday, 27 April 2012 at 22:40:46 UTC, H. S. Teoh wrote:
> > I recommend the opposite, actually. Most D code by default
> > should be @safe (don't know about nothrow though). It's good to
> > mark most things as @safe and pure, and let
On 28/04/12 00:29, Era Scarecrow wrote:
Last try adding ref after const; At the off chance it's shallow copying, this
should remove that.
Ahhh, that works. Thank you!
Back story: originally the reputation() function just took the array ratings and
made an internal copy, ratings_, which was u
On Friday, 27 April 2012 at 22:40:46 UTC, H. S. Teoh wrote:
I recommend the opposite, actually. Most D code by default
should be @safe (don't know about nothrow though). It's good to
mark most things as @safe and pure, and let the compiler catch
careless mistakes.
Your probably right..
Dyna
On Sat, Apr 28, 2012 at 12:29:24AM +0200, Era Scarecrow wrote:
> On Friday, 27 April 2012 at 16:02:00 UTC, Steven Schveighoffer
> wrote:
[...]
> >Hm.. you have marked all your functions pure as well. I don't think
> >this will affect anything in the current implementation, but it
> >might. Howeve
Mariusz Gliwiński:
could You recommend me some books / materials explaining
different concepts in functional programming from *practical
point of view*?
Most preferably not requiring me to understand Haskell or other
classical functional language.
It's not easy to answer this question. Maybe
On Friday, 27 April 2012 at 16:02:00 UTC, Steven Schveighoffer
wrote:
On Fri, 27 Apr 2012 11:33:39 -0400, Joseph Rushton Wakeling
On 27/04/12 17:18, Steven Schveighoffer wrote:
const should not affect code generation *at all*, except for
name mangling
(const MyStruct is a different type from
On Friday, April 27, 2012 14:00:13 H. S. Teoh wrote:
> In -release mode, array bounds checking is turned off for speed reasons.
> The idea being that before you compile with -release you've already
> extensively tested your program and are sure that simple bugs like array
> overruns have been weede
On Fri, Apr 27, 2012 at 08:29:40PM +0200, Joseph Rushton Wakeling wrote:
> On 27/04/12 20:25, H. S. Teoh wrote:
> >On Fri, Apr 27, 2012 at 07:25:30PM +0200, Joseph Rushton Wakeling wrote:
> >>I was more concerned that the compiler wasn't identifying what to me
> >>was a violation of purity. I'm fa
Hello,
could You recommend me some books / materials explaining different
concepts in functional programming from *practical point of view*?
Most preferably not requiring me to understand Haskell or other
classical functional language.
I'd like to try it with D.
I'm using more functional styl
On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis wrote:
Access violations / segfaults aren't exceptions. They're OS
signals. You can't catch them.
Actually, on Windows, access violation is a thrown Error.
I don't think you should catch it, but you can.
See druntime's src/rt/deh.d fo
On Fri, 27 Apr 2012 15:28:48 -0400, Joseph Rushton Wakeling
wrote:
On 27/04/12 20:39, Steven Schveighoffer wrote:
No, just make sure all the parameters and the result are either
immutable or
implicitly castable to immutable (hard to explain this better).
Hm... gives me a thought that unit
On 27/04/12 20:39, Steven Schveighoffer wrote:
No, just make sure all the parameters and the result are either immutable or
implicitly castable to immutable (hard to explain this better).
Hm... gives me a thought that unit tests should have a helper that allows
ensuring this:
static assert(isSt
On Friday, April 27, 2012 14:26:52 Steven Schveighoffer wrote:
> On Fri, 27 Apr 2012 13:23:46 -0400, Jonathan M Davis
>
> wrote:
> > On Friday, April 27, 2012 11:18:26 Steven Schveighoffer wrote:
> >> const should not affect code generation *at all*, except for name
> >> mangling
> >> (const MySt
On Fri, 27 Apr 2012 14:29:40 -0400, Joseph Rushton Wakeling
wrote:
On 27/04/12 20:25, H. S. Teoh wrote:
On Fri, Apr 27, 2012 at 07:25:30PM +0200, Joseph Rushton Wakeling wrote:
I was more concerned that the compiler wasn't identifying what to me
was a violation of purity. I'm fairly sure I
On 27/04/12 20:25, H. S. Teoh wrote:
On Fri, Apr 27, 2012 at 07:25:30PM +0200, Joseph Rushton Wakeling wrote:
I was more concerned that the compiler wasn't identifying what to me
was a violation of purity. I'm fairly sure I can also find a way to
make some of those "nothrow" functions throw an
On Fri, 27 Apr 2012 13:25:30 -0400, Joseph Rushton Wakeling
wrote:
On 27/04/12 19:08, Steven Schveighoffer wrote:
weak purity, I think, is one of the most revolutionary ideas to come
from D.
Essentially, we get compiler-checked pure functions that can be written
imperatively instead of fun
On Fri, 27 Apr 2012 13:23:46 -0400, Jonathan M Davis
wrote:
On Friday, April 27, 2012 11:18:26 Steven Schveighoffer wrote:
const should not affect code generation *at all*, except for name
mangling
(const MyStruct is a different type from MyStruct), and generating an
extra TypeInfo for con
On Friday, 27 April 2012 at 18:19:33 UTC, Jonathan M Davis wrote:
On Friday, April 27, 2012 18:49:48 Simen Kjaeraas wrote:
On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
> By the following code i get a normal Access Violation.
> My question is: why? Even if "f0" is null, the object m
On Fri, Apr 27, 2012 at 07:25:30PM +0200, Joseph Rushton Wakeling wrote:
> On 27/04/12 19:08, Steven Schveighoffer wrote:
> >weak purity, I think, is one of the most revolutionary ideas to come
> >from D. Essentially, we get compiler-checked pure functions that can
> >be written imperatively inste
On Friday, April 27, 2012 18:49:48 Simen Kjaeraas wrote:
> On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
> > By the following code i get a normal Access Violation.
> > My question is: why? Even if "f0" is null, the object must be
> > converted to Ref and there i check if the given obje
On Friday, 27 April 2012 at 18:01:55 UTC, Namespace wrote:
On Friday, 27 April 2012 at 17:51:13 UTC, Namespace wrote:
On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis
wrote:
On Friday, April 27, 2012 19:38:34 Namespace wrote:
I read about "collectExceptionMsg". Maybe that is a possib
On Friday, 27 April 2012 at 17:51:13 UTC, Namespace wrote:
On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis
wrote:
On Friday, April 27, 2012 19:38:34 Namespace wrote:
I read about "collectExceptionMsg". Maybe that is a possible
solution to catch Access Violations?
Access violations
Thanks for you help:)
On Friday, 27 April 2012 at 09:20:04 UTC, Dejan Lekic wrote:
On Friday, 27 April 2012 at 09:05:12 UTC, Marcin wrote:
Hi!
I find code:
[code]
import c.stdlib;
import c.stdlib;
import std.outofmemory;
class Foo{
static void[] buffer;
static int bufindex;
On Friday, 27 April 2012 at 17:47:48 UTC, Jonathan M Davis wrote:
On Friday, April 27, 2012 19:38:34 Namespace wrote:
I read about "collectExceptionMsg". Maybe that is a possible
solution to catch Access Violations?
Access violations / segfaults aren't exceptions. They're OS
signals. You can'
On Friday, April 27, 2012 19:38:34 Namespace wrote:
> I read about "collectExceptionMsg". Maybe that is a possible
> solution to catch Access Violations?
Access violations / segfaults aren't exceptions. They're OS signals. You can't
catch them.
- Jonathan M Davis
I read about "collectExceptionMsg". Maybe that is a possible
solution to catch Access Violations?
On 27/04/12 19:23, Jonathan M Davis wrote:
Thanks to the fact that const is transitive and that it's illegal to cast it
away to use mutation, const _can_ affect code optimizations, but I don't know
exactly under what circumstances it does in the current compiler.
I should add that I'm using GDC
On 27/04/12 19:08, Steven Schveighoffer wrote:
weak purity, I think, is one of the most revolutionary ideas to come from D.
Essentially, we get compiler-checked pure functions that can be written
imperatively instead of functionally.
I do agree with that; it's a very attractive aspect of D that
On Friday, April 27, 2012 11:18:26 Steven Schveighoffer wrote:
> const should not affect code generation *at all*, except for name mangling
> (const MyStruct is a different type from MyStruct), and generating an
> extra TypeInfo for const MyStruct and const MyStruct[]. Const is purely a
> compile-t
On 27/04/12 18:37, Joseph Rushton Wakeling wrote:
I suppose I could get reputation() to _return_ reputationObject and
reputationUser instead of having them called via functions; but I'd be worried
it would slow everything down substantially.
... well what do I know. I tweaked it to do just tha
On Friday, 27 April 2012 at 17:08:43 UTC, Simen Kjaeraas wrote:
On Friday, 27 April 2012 at 16:57:52 UTC, Namespace wrote:
On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
By the following code i get a normal Access Viol
On Fri, 27 Apr 2012 12:16:46 -0400, Rene Zwanenburg
wrote:
I've run a few times in the 'dtor allocating memory' problem, but it's
usually easy enough to work around. One more question: Is that a
limitation of the current GC implementation, or something intrinsic to
garbage collection in
On Fri, 27 Apr 2012 12:37:41 -0400, Joseph Rushton Wakeling
wrote:
I have to say I'm somewhat confused about whether the pure markings are
really accurate. The reputation() modifies the reputationUser_ and
reputationObject_ internal arrays and hence the returned values of
reputationUser
On Friday, 27 April 2012 at 16:57:52 UTC, Namespace wrote:
On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
By the following code i get a normal Access Violation.
My question is: why? Even if "f0" is null, the object must
On Friday, 27 April 2012 at 16:49:49 UTC, Simen Kjaeraas wrote:
On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
By the following code i get a normal Access Violation.
My question is: why? Even if "f0" is null, the object must be
converted to Ref and there i check if the given object i
On Friday, 27 April 2012 at 16:36:04 UTC, Namespace wrote:
By the following code i get a normal Access Violation.
My question is: why? Even if "f0" is null, the object must be
converted to Ref and there i check if the given object is null.
When trying to convert f0 to Ref, the compiler has to l
On Fri, 27 Apr 2012 17:55:02 +0200, Rene Zwanenburg
wrote:
I _could_ modify the system to use ref counting everywhere, but I'm
reluctant to do that.
You wouldn't really need to. Only the texture struct would need that.
Look to std.typecons's RefCounted[1] for inspiration. One could easily
i
By the following code i get a normal Access Violation.
My question is: why? Even if "f0" is null, the object must be
converted to Ref and there i check if the given object is null.
Here is the Code:
[code]
// Ref.d
struct Ref(T : Object) {
private:
T _val;
public:
@disable
On 27/04/12 18:02, Steven Schveighoffer wrote:
Hm.. you have marked all your functions pure as well. I don't think this will
affect anything in the current implementation, but it might. However, I'd expect
the opposite (const version is faster) if anything.
Yes, me too, hence confusion.
I have
On Friday, 27 April 2012 at 15:59:50 UTC, Steven Schveighoffer
wrote:
On Fri, 27 Apr 2012 11:55:02 -0400, Rene Zwanenburg
wrote:
Which reminds me, does the GC actually block all threads while
calling the destructors on garbage? I'm far from an expert on
GC's, but I believe the mark needs to
On Fri, 27 Apr 2012 11:33:39 -0400, Joseph Rushton Wakeling
wrote:
On 27/04/12 17:18, Steven Schveighoffer wrote:
const should not affect code generation *at all*, except for name
mangling
(const MyStruct is a different type from MyStruct), and generating an
extra
TypeInfo for const MyStr
On Fri, 27 Apr 2012 11:55:02 -0400, Rene Zwanenburg
wrote:
Which reminds me, does the GC actually block all threads while calling
the destructors on garbage? I'm far from an expert on GC's, but I
believe the mark needs to stop the world, but the sweep can be done
concurrently. If the GC
On Friday, 27 April 2012 at 13:04:32 UTC, Dmitry Olshansky wrote:
Don't. If I still worth anything in GL texture is bound to an
opaque uint of sorts. There is no problem copying this number
around.
There is no point in holding multiple references to 42 ;) Just
copy the number.
That's correct.
On Friday, 27 April 2012 at 14:14:37 UTC, Steven Schveighoffer
wrote:
Have you tried measuring the code timings just inside main
instead of the full execution of the program including runtime
startup and shutdown?
-Steve
OK, it seems you are right. It turns out using
Measure-Command{...} wa
On 27/04/12 17:18, Steven Schveighoffer wrote:
const should not affect code generation *at all*, except for name mangling
(const MyStruct is a different type from MyStruct), and generating an extra
TypeInfo for const MyStruct and const MyStruct[]. Const is purely a compile-time
concept.
This can
On 27/04/12 17:12, Joseph Rushton Wakeling wrote:
So, in pseudocode, it's something like this:
... should add: if anyone wants to see the _real_ code, it's here:
https://github.com/WebDrake/Dregs/blob/master/dregs/codetermine.d
With the passed array being the Rating!()[] that gets passed to th
On Fri, 27 Apr 2012 11:12:07 -0400, Joseph Rushton Wakeling
wrote:
Hello all,
A surprise today when tweaking some code.
I have a function which takes as input an array of values (the values
are a custom struct). So, in pseudocode, it's something like this:
struct MyStruct
{
On Friday, 27 April 2012 at 13:13:20 UTC, Steven Schveighoffer
wrote:
Yes it's hard. The GC has no access to compile-time type
information. It relies on runtime information. The GC is able
to call the dtor for classes because classes store a pointer to
their typeinfo in the class instance it
Hello all,
A surprise today when tweaking some code.
I have a function which takes as input an array of values (the values are a
custom struct). So, in pseudocode, it's something like this:
struct MyStruct
{
size_t x;
size_t y;
double z;
}
void foo(My
On 27/04/12 15:40, Simen Kjaeraas wrote:
std.typecons has a type called Tuple, which is probably what you want:
... !
Can't believe I missed that. Works perfectly, thanks so much! :-)
On Fri, 27 Apr 2012 10:09:18 -0400, SomeDude
wrote:
On Wednesday, 25 April 2012 at 17:37:33 UTC, H. S. Teoh wrote:
First of all, differences as small as 20ms really should be considered
as background noise. The exact measurements depend on a lot of
system-specific and environment-specific f
On Wednesday, 25 April 2012 at 17:37:33 UTC, H. S. Teoh wrote:
First of all, differences as small as 20ms really should be
considered
as background noise. The exact measurements depend on a lot of
system-specific and environment-specific factors, such as OS
memory
usage, CPU cache behaviour,
On Fri, 27 Apr 2012 14:52:08 +0200, Joseph Rushton Wakeling
wrote:
Hello all,
Just recently I tried returning a Tuple from a function and received an
error message about this not being allowed.
Reading up a bit on the D site I'm not clear -- is it a determined
policy for the language t
On Fri, 27 Apr 2012 14:57:52 +0200, Rene Zwanenburg
wrote:
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
Am Fri, 27 Apr 2012 04:18:47 + (UTC)
schrieb David Brown :
> On 2012-04-25, SomeDude wrote:
> > On Wednesday, 25 April 2012 at 15:35:44 UTC, Steven Schveighoffer
> > wrote:
> >> On Wed, 25 Apr 2012 07:27:29 -0400, SomeDude
> >> wrote:
> >>
> >>> On Wednesday, 25 April 2012 at 08:34:40 UTC,
On Fri, 27 Apr 2012 08:57:52 -0400, Rene Zwanenburg
wrote:
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
On 27.04.2012 16:54, Rene Zwanenburg wrote:
[snip]
True, but what would using structs do to fix the problem?
The reason I'm using (final) classes is because a resource can be used
by multiple objects. If two meshes use the same texture, I don't want to
load that texture twice.
Don't. If I sti
On Friday, 27 April 2012 at 12:03:18 UTC, Dmitry Olshansky wrote:
Boom! Just LOL...
Use manual memory management or ref-counting. If
std.container.Array was not so bogus I'd recommend it for
arrays.
Yeah, I already have a few different types of smart pointer which
can work with custom alloc
On Friday, 27 April 2012 at 11:53:37 UTC, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
calls made
from other threads will fail. I've wrapped OpenGL 'obj
On Friday, 27 April 2012 at 11:23:06 UTC, Dmitry Olshansky wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL
calls made
from other threads will fail. I've wrapped OpenGL 'objects' in
D classes
to automate destruction of the underlying
Hello all,
Just recently I tried returning a Tuple from a function and received an error
message about this not being allowed.
Reading up a bit on the D site I'm not clear -- is it a determined policy for
the language that it's not possible to return a tuple, or is it just something
that has
On 27.04.2012 15:53, Simen Kjaeraas wrote:
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to
On Fri, 27 Apr 2012 13:23:00 +0200, Dmitry Olshansky
wrote:
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to automate destruction of the underlying obj
On 27.04.2012 15:15, Rene Zwanenburg wrote:
Since an OpenGL context is owned by one thread, any OpenGL calls made
from other threads will fail. I've wrapped OpenGL 'objects' in D classes
to automate destruction of the underlying object:
How about using structs for GL objects? It's not like you h
Since an OpenGL context is owned by one thread, any OpenGL calls
made from other threads will fail. I've wrapped OpenGL 'objects'
in D classes to automate destruction of the underlying object:
this() {
// Init texture
}
~this() {
glDeleteTextures(1, &_handle);
}
This will blow up if t
On Friday, 27 April 2012 at 09:05:12 UTC, Marcin wrote:
Hi!
I find code:
[code]
import c.stdlib;
import c.stdlib;
import std.outofmemory;
class Foo{
static void[] buffer;
static int bufindex;
static const int bufsize = 100;
static this(){
void *p;
Hi!
I find code:
[code]
import c.stdlib;
import c.stdlib;
import std.outofmemory;
class Foo{
static void[] buffer;
static int bufindex;
static const int bufsize = 100;
static this(){
void *p;
p = malloc(bufsize);
if (
dcoder wrote:
> Hello.
>
> I'm probably not looking hard enough, but Do we have any
> standard d-library for serializing an object/object tree into
> -for example- an xml file?
>
> thanks.
You have following
- Orange
- Thrift implementation
- BSON (http://vibed.org)
Probably wrappers or bi
Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=7995
72 matches
Mail list logo
