Re: DConf Reception sponsored by the HipHop team at Facebook
On Friday, 1 March 2013 at 11:12:02 UTC, Andrei Alexandrescu wrote: (details to follow) So, are there any details? Like, e.g. is there a dress code? :)
Re: D compile time algorithms implementation
But, I'm sorry, I do not have the ability to work with the code itself, now. I take a few other things. Regards, Khursid. Oh,god !!!
Re: rvalue references
On Tuesday, 23 April 2013 at 19:45:39 UTC, Zach the Mystic wrote:
ref T func(ref T x, @noreturn ref T y) {
return x; // pass
return y; // error
static T* t = y; // pass!?
}
Sorry about the static definition. It should be: 'static T* t; t
= y;' instead, and for all subsequent definitions.
Re: Twitter widget cut on dconf.org on Chrome/OSX
On 2013-04-24 01:42, Nick Sabalausky wrote: I consider HTML-tables-for-layout one of my not-so-secret weapons. It's immensely useful, simple, powerful and easy, they work right on freaking everything, and ever since PalmOS browsers disappeared (ie no nested tables) it has no real downsides aside from some goofy hand-wavy ideology. I love HTML layout tables :) Or one can just use Bootstrap and all this is already done for you. http://twitter.github.io/bootstrap/ And no, you don't have to use the JavaScript stuff. -- /Jacob Carlborg
Re: RES file not linking anymore with DMD v2.052
On 23.04.2013 09:48, Ettienne wrote: On Monday, 22 April 2013 at 22:19:39 UTC, Rainer Schuetze wrote: Yes, it should be fixed in the rc for the next version: http://www.dsource.org/projects/visuald/browser/downloads/VisualD-v0.3.36rc5.exe Hi Rainer, With VisualD-v0.3.36rc5 (Win XP 32bit, VS 2008) I get an install error: Error loading C:\Program Files\VisualD\visuald.dll. Invalid access to memory location I tried also with VisualD-v0.3.36rc4 - but get the same error. If I re-install VisualD-v0.3.35 it installs fine. XP support for DLLs seems to have been broken between rc3 and rc4 ;-( I'll have to investigate... The fix for the command line is in rc1.
Re: rvalue references
On Wednesday, 24 April 2013 at 03:41:17 UTC, Manu wrote:
scope ref a(scope ref int x) { return x; }
One thing to bear in mind about this usage is that 'scope' could
apply to the implicit 'this' reference, in addition to describing
the return type, which might make it unfeasible. I don't know how
often you'd want to tag the 'this' with 'scope' but not the
return, and the other way around.
struct S {
scope ref a(scope ref int x) { return x; }
}
Re: Official D Grammar
On 2013-04-24 03:40, Jonathan M Davis wrote: That would mean creating more keywords, which would break code. By using @, we avoid having to create new keywords, which I believe was the whole point in the first place. Which attributes got @ on them was fairly arbitrary, but they do definitely serve a purpose. And any new attributes in the future will probably have @ on them for the same reason. You can't use the same reasoning anymore since we have UDA. Those will conflict with new keywords starting with an @. -- /Jacob Carlborg
Re: DIP 36: Rvalue References
On Tuesday, 23 April 2013 at 18:41:07 UTC, Andrei Alexandrescu wrote: Making 'safe' ref the default is a major breaking change. How do you assess the size of the breakage? I think it's fairly well-understood, probably with the same meaning that you used in your own post somewhere else: http://forum.dlang.org/thread/hlh4g2$1tn0$2...@digitalmars.com#post-hlh753:24270m:241:40digitalmars.com
Re: [ gtkD ] Question about mouse press event in Notebook ...
Sorry, you don't understand me. I want something like this: /--Frameless Window--\ |*First Reordalable tab* | *Second ...* || Rest - drag this to begin move window | |*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*--*-*-*| | | | | | Tab content - not this ! | | | | | | | \/ I know that function addOnButtonPressd() prevents change the order of the tabs ... Did you have any idea ? Thanks for your time.
Re: [ gtkD ] Question about mouse press event in Notebook ...
And sorry for bad ASCI sample ... You should copy it to your favorite text editor. Sorry ...
Re: rvalue references
On 4/23/2013 8:32 PM, Manu wrote: Is it actually complicated? It's a lot more complicated than simply destructing them at the end of a function. You have to define what happens for conditionally executed expressions || ?:, what happens at the end of a statement, what happens at a }, what happens to for statement initializers, etc., for each statement type. Enclosing scope seems fine too. Can you suggest a case where it could escalate to an outer scope via a scope-ref argument? So let's say then, that lifetime should be identical to a local declared in the same location. No change of any rules is required, it will work as expected. You cannot declare locals in conditionally compiled expressions. So it isn't as simple as that.
Re: rvalue references
On 4/23/2013 6:02 PM, Diggory wrote: Why does the temporary need to exist any longer than the current statement? And it doesn't in C++.
Re: rvalue references
On Wednesday, 24 April 2013 at 02:56:42 UTC, Jonathan M Davis
wrote:
So, probably the best route at this point is to come up with a
new attribute
which is replace with ref in the function definition and
When you say replace with ref, does that mean 'ref' won't
appear in the common case?
ref T fc(scope int a) {}
The problem would be that 'scope' would behave differently,
implying 'ref' with a value type, from with a reference type, in
which it shouldn't imply 'ref'. I don't know if it makes sense to
automatically promote the meaning of 'scope' to include 'ref' for
value types while leaving it alone for reference types. This was
objected to by others, but if it were provably harmless to allow,
it would be an appearance improvement.
Re: rvalue references
On 4/23/2013 8:44 PM, Manu wrote: The important distinction is that with scope ref, a temps life can be prolonged and cascaded via return values. This is very important behaviour, I couldn't write an efficientconvenient matrix library for instance without this, i would have to choose one or the other. Dealing with this issue, one way or another, is critical for any rvalue ref design.
Re: RES file not linking anymore with DMD v2.052
On Wednesday, 24 April 2013 at 06:33:22 UTC, Rainer Schuetze wrote: XP support for DLLs seems to have been broken between rc3 and rc4 ;-( I'll have to investigate... The fix for the command line is in rc1. Hi Rainer, OK, that's no problem - I'll just stick to rc3 for now then. Thanks for analyzing the problem. Cheers, Ettienne
Re: rvalue references
On 24 April 2013 16:52, Walter Bright newshou...@digitalmars.com wrote: On 4/23/2013 8:32 PM, Manu wrote: Is it actually complicated? It's a lot more complicated than simply destructing them at the end of a function. You have to define what happens for conditionally executed expressions || ?:, what happens at the end of a statement, what happens at a }, what happens to for statement initializers, etc., for each statement type. Enclosing scope seems fine too. Can you suggest a case where it could escalate to an outer scope via a scope-ref argument? So let's say then, that lifetime should be identical to a local declared in the same location. No change of any rules is required, it will work as expected. You cannot declare locals in conditionally compiled expressions. So it isn't as simple as that. Okay, I understand the problem now. I'm sure it's possible to address these issues, but I see the complexity in that case. Is it worth doing so? Will it be taken seriously, or will another reason to dismiss it appear?
Re: Is there any plans to make working signals in D?
19.04.2013 11:45, deadalnix пишет: On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote: Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. How does using an object solve that ? Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), onDelegateDisposed); --- -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Official D Grammar
On Wednesday, 24 April 2013 at 01:40:52 UTC, Jonathan M Davis wrote: On Tuesday, April 23, 2013 21:51:54 Stewart Gordon wrote: Er, do away with the meaningless @? Since nobody seems to have succeeded in explaining how the @-attributes differ from the rest, it seems the right way to go. That would mean creating more keywords, which would break code. By using @, we avoid having to create new keywords, which I believe was the whole point in the first place. Which attributes got @ on them was fairly arbitrary, but they do definitely serve a purpose. And any new attributes in the future will probably have @ on them for the same reason. - Jonathan M Davis Please don't. This was the approach taken by Java with the @overload and friends, which leads to ugly code in my opinion. Once I worked in a project which took a similar approach, we would have annotations as a way to extend the core grammar. Each team eventually grew its own set of annotations, to the point the amount of annotations became bigger than the core grammar itself, with overlapping meaning. -- Paulo
Re: rvalue references
On 4/24/2013 1:23 AM, Manu wrote: Okay, I understand the problem now. I'm sure it's possible to address these issues, but I see the complexity in that case. Is it worth doing so? Will it be taken seriously, or will another reason to dismiss it appear? Yes, it's worth doing in whatever the final proposal will be.
Re: rvalue references
On Wednesday, 24 April 2013 at 08:23:57 UTC, Manu wrote: Okay, I understand the problem now. I'm sure it's possible to address these issues, but I see the complexity in that case. Is it worth doing so? Will it be taken seriously, or will another reason to dismiss it appear? I can't talk for Walter, but let me tell what I'd say if I was him. The issue is worth considering. However, clearly in a 2 step process : - Ensuring lifetime safety. - In a second step, ensuring rvalue ref binding when it is safe (this include many consideration about temporary lifetime that aren't trivial as you can see). I'd give priority to #1 as it seems like a major hole in D right now. But #2, even if truly important, solve a problem that isn't as fundamental, and incurs a fair amount of complexity, so I'd delay it until some core recurring problems are sorted out.
Re: D compile time algorithms implementation
Is this code right?
template templateAnd(Preds...)
{
template templateAnd(T...)
{
static if (Preds.length == 0)
{
enum templateAnd = true;
}
else static if (Preds.length == 1)
{
enum templateAnd = Instantiate!(Preds[0],T);
}
else
{
static if (Instantiate!(.templateAnd(Preds[0..$/2]),T))
{
enum templateAnd =
Instantiate!(.templateAnd(Preds[$/2..$]),T);
}
else
{
enum templateAnd = false;
}
}
}
}
here
template Instantiate(alias P, T...)
{
alias Instantiate = P!(T);
}
Re: Is there any plans to make working signals in D?
On Wednesday, 24 April 2013 at 08:27:15 UTC, Denis Shelomovskij wrote: 19.04.2013 11:45, deadalnix пишет: On Friday, 19 April 2013 at 07:31:16 UTC, Denis Shelomovskij wrote: Another try to describe the problem: When I get a delegate, I'd like to use it unless it become invalid. How does using an object solve that ? Unless this is a struct-member delegate (which is not often used anyway and can be marked as dangerous e.g.): --- T delegate(A) del = ...; rt_attachDisposeEvent(_d_toObject(del.ptr), onDelegateDisposed); --- I still see many possibilities without changing the language. For instance, allowing to attach dispose event to something else than an object.
Re: rvalue references
r-values can NEVER be accepted by a ref argument, they don't
'exist', we're
talking about implicitly generated temporaries (which also
addresses the
issues with receiving _explicit_ temp's).
They may be temporary but why should that mean they don't exist.
(wow that's disturbingly close to a harry potter quote)
Currently temporaries exist as long as they are required to
exist, and their lifetime never exceeds one statement.
If I were to start arguing upon the basis of your proposal, I
would then
start arguing that auto-ref in this context is pointless, and
automatic
creation of a temp to hold any r-value should be the
universal/default
behaviour.
I believe with the exception of literals (which are probably
implemented as global immutable variables) temporaries are
already whenever an rvalue is used...
Why does the temporary need to exist any longer than the
current
statement? (the current lifetime of temporaries are the
statement or
expression). Surely any longer is just wasting stack space.
scope ref a(scope ref int x) { return x; }
void b(scope ref int x);
b(a(10));
The temp produced from '10' needs to last longer than a(),
because it can
be returned to b(). Ie, the temp needs the life of any normal
local
declared within that scope.
How do you describe 'wasting' stack space? Does D attempt to
recycle stack
space from previous short-lived locals within a single function?
I said Why does the temporary need to exist any longer than the
current statement?. In your example the temporary does not exist
longer than the current statement, (the current statement in this
example being b(a(10)) since that is the context in which the
temporary would be created)
I would hope that D reuses the stack space it uses for
temporaries, certainly any decent C++ compiler would...
The important distinction is that with scope ref, a temps life
can be
prolonged and cascaded via return values.
That's simply not true, even if you allow passing rvalues as
normal ref, as long as DIP25A is implemented. The longest a
temp ever needs to exist is until the end of the statement, with
or without rvalue references. This means there is no issue with
conditionals.
Anyway, it seems in general that everyone thinks DIP25A should be
implemented, or am I mistaken?
Reducing the inter-dependencies (in Phobos and at large)
Recently I've struggled again to integrate a module in Phobos and the
amount of curious forward reference bugs made think about a related but
not equivalent problem.
Intro
Basically an import graph of Phobos is a rat's nest of mutual imports.
With the most of modules being template toolkits you shouldn't pay for
what you don't use. Yet it isn't true in general as the module may drag
in other modules and with that all of static constructors and/or globals
related.
Adding even more fun to this stuff - to get a constraint checker you
have to import all other stuff from that module (and transitively from
all imported by it modules, see std.range example below).
One motivating example (though I believe there are much more beyond this
one):
As some might know regular expression engine can be used for both
generating sequences for a known pattern and matching/finding pieces
that do match it in some data.
In fact I have such a functionality in std.regex hidden from public
interface (not yet complete, wasn't sure of the kind of API etc.).
Now the *key* fact:
auto generate(RegEx, rng) (RegEx re, Random rng)
if(isRegex!RegEx isUniformRNG!Random)
{
...
}
Now given that innocent signature you have dependency on the whole of
std.random *including* seeding the default random number generator at
the program start!
And recall that generating strings while neat is arguably more rare need
then pattern matching.
Same thing with std.datetime - to get an ability to accept any kind of
Date as a template parameter (in your API) you have to get the whole
std.datetime *even if the user never ever calls this function* of your
module API.
And everyone and their granny depends on full version of std.range
that in turn depends on std.algorithm that depends on std.conv that
depends on std.format(!) and that incidentally on std.uni.
BTW std.uni turns out to be a kind of sink everybody imports sooner or
later if only for unittests, sadly it's mostly imported unconditionally.
And that skipping a full rat's nest to preserve the brains of the reader.
After a couple of frustrating evenings dealing with it (multiplied by
the bogus dmd) I've come up with the idea below.
Solution
First of all no compiler magic required (phew-ew!) :)
Not to mention the 2 obvious facts - smaller modules might help, as
would guarding by version(unittest) imports used only for unit tests.
What we need is to re-arrange the module hierarchy (and we need that
anyway) so that we split off the concept part of modules to a separate
package.
That would allow modules that need this to use these Duck-typed entities
(IFF the user ever passes such an entity) can stick with importing only
the concept part.
Applying that to the current layout would look like:
std.concept.range
std.concept.random
std.concept.* //every other module with any useful isXYZ constraint
std.* // stays as is
Any module that has concept part then looks like this:
module std.xyz;
import std.concept.xyz;
... //the rest
And then other weakly-dependent modules (i.e. these that are satisfied
with traits and duck-typed interfaces) can safely import std.concept.xyz
instead of std.xyz. E.g. std.regex would import std.concept.random to
get isUniformRNG and rely on duck typing thusly described to use it
correctly.
The change is backwards compatible and introduces no breakage.
Only clean sugar-free interdependence of modules in Phobos.
Later people (mostly library writers) can use e.g. std.concept.range
to avoid pulling full dependency tree in case only constraints are
needed. The technique can be touted as coding guideline for template and
duck-type heavy libraries.
Thoughts? Other ideas?
--
Dmitry Olshansky
Re: rvalue references
On 4/24/13 6:27 AM, Diggory wrote: Anyway, it seems in general that everyone thinks DIP25A should be implemented, or am I mistaken? I'd like to work a bit more on it before a formal review. Andrei
Re: DIP 36: Rvalue References
On 04/24/2013 02:41 AM, kenji hara wrote:
...
1. parameterized-ref is already there with the syntax `auto ref`.
Removing it introduces breaking language change.
2. If we remove parameterized-ref from D, we will lose the ability to
write certain kind of template functions. For example:
auto ref forward(T)(auto ref T arg) { return arg; }
The parameter `arg` is instantiated with both ref/non-ref, and forward
`function` returns also both ref/non-ref value. In such case, you cannot
replace parameterized-ref to rvalue-ref.
These are why DIP36 is necessary. Repeatedly, I think removing current
`auto ref` is not good.
...
We could specify that if there is no influence (to be made more precise)
of the actual ref-ness for the function semantics, the second copy is
elided. It is then illegal for non-templated functions to require
multiple copies.
This would merge the two features under the name auto ref.
Re: rvalue references
On 04/24/2013 04:56 AM, Jonathan M Davis wrote: ... However, the problem with simply making auto ref do this for non-templated functions is that then it functions fundamentally differently for templated and non-templated functions. ... http://forum.dlang.org/thread/ylebrhjnrrcajnvtt...@forum.dlang.org?page=12#post-kl8m2e:24i7g:241:40digitalmars.com
Re: Reducing the inter-dependencies (in Phobos and at large)gei
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky
wrote:
Recently I've struggled again to integrate a module in Phobos
and the amount of curious forward reference bugs made think
about a related but not equivalent problem.
Intro
Basically an import graph of Phobos is a rat's nest of mutual
imports.
With the most of modules being template toolkits you
shouldn't pay for what you don't use. Yet it isn't true in
general as the module may drag in other modules and with that
all of static constructors and/or globals related.
Adding even more fun to this stuff - to get a constraint
checker you have to import all other stuff from that module
(and transitively from all imported by it modules, see
std.range example below).
One motivating example (though I believe there are much more
beyond this one):
As some might know regular expression engine can be used for
both generating sequences for a known pattern and
matching/finding pieces that do match it in some data.
In fact I have such a functionality in std.regex hidden from
public interface (not yet complete, wasn't sure of the kind of
API etc.).
Now the *key* fact:
auto generate(RegEx, rng) (RegEx re, Random rng)
if(isRegex!RegEx isUniformRNG!Random)
{
...
}
Now given that innocent signature you have dependency on the
whole of std.random *including* seeding the default random
number generator at the program start!
And recall that generating strings while neat is arguably more
rare need then pattern matching.
Same thing with std.datetime - to get an ability to accept any
kind of Date as a template parameter (in your API) you have to
get the whole std.datetime *even if the user never ever calls
this function* of your module API.
And everyone and their granny depends on full version of
std.range
that in turn depends on std.algorithm that depends on std.conv
that depends on std.format(!) and that incidentally on std.uni.
BTW std.uni turns out to be a kind of sink everybody imports
sooner or later if only for unittests, sadly it's mostly
imported unconditionally.
And that skipping a full rat's nest to preserve the brains of
the reader.
After a couple of frustrating evenings dealing with it
(multiplied by the bogus dmd) I've come up with the idea below.
Solution
First of all no compiler magic required (phew-ew!) :)
Not to mention the 2 obvious facts - smaller modules might
help, as would guarding by version(unittest) imports used only
for unit tests.
What we need is to re-arrange the module hierarchy (and we need
that anyway) so that we split off the concept part of modules
to a separate package.
That would allow modules that need this to use these Duck-typed
entities (IFF the user ever passes such an entity) can stick
with importing only the concept part.
Applying that to the current layout would look like:
std.concept.range
std.concept.random
std.concept.* //every other module with any useful isXYZ
constraint
std.* // stays as is
Any module that has concept part then looks like this:
module std.xyz;
import std.concept.xyz;
... //the rest
And then other weakly-dependent modules (i.e. these that are
satisfied with traits and duck-typed interfaces) can safely
import std.concept.xyz instead of std.xyz. E.g. std.regex would
import std.concept.random to get isUniformRNG and rely on duck
typing thusly described to use it correctly.
The change is backwards compatible and introduces no breakage.
Only clean sugar-free interdependence of modules in Phobos.
Later people (mostly library writers) can use e.g.
std.concept.range
to avoid pulling full dependency tree in case only constraints
are needed. The technique can be touted as coding guideline for
template and duck-type heavy libraries.
Thoughts? Other ideas?
Re: Reducing the inter-dependencies (in Phobos and at large)
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote: E.g. std.regex would import std.concept.random to get isUniformRNG and rely on duck typing thusly described to use it correctly. Thoughts? Other ideas? how would this be different then limited imports such as: import std.random: isUniformRNG; ?
Re: Reducing the inter-dependencies (in Phobos and at large)
On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote: Basically an import graph of Phobos is a rat's nest of mutual imports. With the most of modules being template toolkits you shouldn't pay for what you don't use. Yet it isn't true in general as the module may drag in other modules and with that all of static constructors and/or globals related. Thoughts? Other ideas? I think your concept idea introduces unnecessary complexity. What are you actually worried about? Compile times? Program size? Startup time? Is compile time a problem? Program size should be handled by the compiler. It is much better at pruning dead code. Startup time should be handled by the modules themselves. For example, std.random could initialize the global RNG only on demand.
Re: Twitter widget cut on dconf.org on Chrome/OSX
On 4/23/13 6:40 PM, Vladimir Panteleev wrote: I was going to send a pull request to https://github.com/D-Programming-Language/dconf.org , but that repository is out of date. Here's some patches and a patched up page to test: http://thecybershadow.net/d/dconf-org-layout/ Yah, we're in the private repo, we should switch back to the public one. I made a bunch of changes based on your patch, still no cigar. On my browser e.g. http://dconf.org/talks/cehreli.html has the likes paragraph overflow. Andrei
Re: DConf 2013 official car/room sharing thread
On Monday, 25 March 2013 at 05:29:39 UTC, Mike Parker wrote: I'll be in the Comfort Inn in Redwood City with a 7-passenger mini-van. I'll be happy to pick people up along the route to FB. Hey, Mike, I could use a ride... legend tells of a great Valley made entirely of Silicon, but I won't believe it until I see it for myself. Anyway, I'm staying only 7 blocks from where you're staying: https://maps.google.com/maps?q=pacific+euro+hotelie=UTF-8ei=Ewd4UdPkJIXC4AOVtoDICwved=0CAsQ_AUoAg You can email me: reach zach at g mail dot com, (no spaces), if you want to exchange info... heck, you can even read my mystical blog if you want to: http://streetshavenoname.wordpress.com/ Hope ta hear frum ya!
Re: Twitter widget cut on dconf.org on Chrome/OSX
On Wednesday, 24 April 2013 at 16:33:37 UTC, Andrei Alexandrescu wrote: On 4/23/13 6:40 PM, Vladimir Panteleev wrote: I was going to send a pull request to https://github.com/D-Programming-Language/dconf.org , but that repository is out of date. Here's some patches and a patched up page to test: http://thecybershadow.net/d/dconf-org-layout/ Yah, we're in the private repo, we should switch back to the public one. I made a bunch of changes based on your patch, still no cigar. On my browser e.g. http://dconf.org/talks/cehreli.html has the likes paragraph overflow. I don't see my changes on that page.
Dmitry Olshansky let us prepare
I'm not locating an email for you so I'm reaching out here. Are you ready? Is there anything one should know to compile and test/use your library? I'll be making an attempt to use it soon so I know how to.
Re: Mixin template parameters / mixin template literals
One way this could be done is by expanding on lazy parameters.
Perhaps you could specify parameters for a lazy argument, so
instead of always getting a delegate of type T delegate(), you
could get one of type T delegate(U a, V b).
For example, a parameter could be:
void f(lazy bool exp(int a, int b)) {
bool result = exp(1, 2);
}
Then when you call that:
f(a b)
The names 'a' and 'b' come from the parameter list for 'f'. I
would definitely vote for this as a feature!
Re: Twitter widget cut on dconf.org on Chrome/OSX
On 4/24/13 12:45 PM, Vladimir Panteleev wrote: On Wednesday, 24 April 2013 at 16:33:37 UTC, Andrei Alexandrescu wrote: On 4/23/13 6:40 PM, Vladimir Panteleev wrote: I was going to send a pull request to https://github.com/D-Programming-Language/dconf.org , but that repository is out of date. Here's some patches and a patched up page to test: http://thecybershadow.net/d/dconf-org-layout/ Yah, we're in the private repo, we should switch back to the public one. I made a bunch of changes based on your patch, still no cigar. On my browser e.g. http://dconf.org/talks/cehreli.html has the likes paragraph overflow. I don't see my changes on that page. I must have missed them; I didn't patch things directly but instead modified the source files by hand. What are the essential changes? Andrei
Re: Twitter widget cut on dconf.org on Chrome/OSX
On Wednesday, 24 April 2013 at 17:17:50 UTC, Andrei Alexandrescu wrote: On 4/24/13 12:45 PM, Vladimir Panteleev wrote: On Wednesday, 24 April 2013 at 16:33:37 UTC, Andrei Alexandrescu wrote: On 4/23/13 6:40 PM, Vladimir Panteleev wrote: I was going to send a pull request to https://github.com/D-Programming-Language/dconf.org , but that repository is out of date. Here's some patches and a patched up page to test: http://thecybershadow.net/d/dconf-org-layout/ Yah, we're in the private repo, we should switch back to the public one. I made a bunch of changes based on your patch, still no cigar. On my browser e.g. http://dconf.org/talks/cehreli.html has the likes paragraph overflow. I don't see my changes on that page. I must have missed them; I didn't patch things directly but instead modified the source files by hand. What are the essential changes? The essential changes are what the second patch is: http://thecybershadow.net/d/dconf-org-layout/0002-Move-vertical-divider-to-right-hand-column.patch
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 02:18:07 UTC, Luís Marques wrote:
Consider:
sort!(a b)(array);
how about?
sort!(q{a b})(array);
http://dlang.org/lex.html#TokenString
Re: Twitter widget cut on dconf.org on Chrome/OSX
On 4/24/13 1:21 PM, Vladimir Panteleev wrote: The essential changes are what the second patch is: http://thecybershadow.net/d/dconf-org-layout/0002-Move-vertical-divider-to-right-hand-column.patch Awesome, that did the trick at least for me. All -- see any issues? Andrei
Re: Reducing the inter-dependencies (in Phobos and at large)
Am Wed, 24 Apr 2013 16:03:47 +0400 schrieb Dmitry Olshansky dmitry.o...@gmail.com: Thoughts? Other ideas? Sounds good to me. We might extend this idea and also add interfaces to the concept modules. Tango did that and IIRC C# does this as well.
Re: Twitter widget cut on dconf.org on Chrome/OSX
On Wednesday, 24 April 2013 at 17:41:20 UTC, Andrei Alexandrescu
wrote:
On 4/24/13 1:21 PM, Vladimir Panteleev wrote:
The essential changes are what the second patch is:
http://thecybershadow.net/d/dconf-org-layout/0002-Move-vertical-divider-to-right-hand-column.patch
Awesome, that did the trick at least for me. All -- see any
issues?
The vertical bar is gone (because my browser saved the image file
to a relative location different from the server one). Change
url('dotted_v.png') to url('../images/dotted_v.png') to fix it.
D folk in London 2013-05-28
I will be doing an In the Brain session at Skills Matter 2013-05-28 18:30+01:00: Are Go and D threats to Python? http://skillsmatter.com/podcast/nosql/are-go-and-d-threats-to-python/mh-7066 http://www.meetup.com/skillsmatter/events/115928192/confirm/ Anyone in London at that time is most welcome to come and heckle. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D folk in London 2013-05-28
I'll look forward to it. (though will have to check my dates). Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0'; On Apr 24, 2013 7:57 PM, Russel Winder rus...@winder.org.uk wrote: I will be doing an In the Brain session at Skills Matter 2013-05-28 18:30+01:00: Are Go and D threats to Python? http://skillsmatter.com/podcast/nosql/are-go-and-d-threats-to-python/mh-7066 http://www.meetup.com/skillsmatter/events/115928192/confirm/ Anyone in London at that time is most welcome to come and heckle. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Reducing the inter-dependencies (in Phobos and at large)
24-Apr-2013 19:56, Joshua Niehus пишет: On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote: E.g. std.regex would import std.concept.random to get isUniformRNG and rely on duck typing thusly described to use it correctly. Thoughts? Other ideas? how would this be different then limited imports such as: import std.random: isUniformRNG; ? No matter how it looks to you this line means: pull in whatever is std.random and make symbol isUniformRNG visible. Since compiler can't know (well that might improve but not anytime soon) that isUniformRNG is independent of static ctors/dtors and globals in that module it has to run both. Strictly speaking what is required is breaking up modules more meaningfully. -- Dmitry Olshansky
Re: rvalue references
On Wednesday, 24 April 2013 at 12:38:19 UTC, Andrei Alexandrescu wrote: On 4/24/13 6:27 AM, Diggory wrote: Anyway, it seems in general that everyone thinks DIP25A should be implemented, or am I mistaken? I'd like to work a bit more on it before a formal review. Andrei If you find the time one day, please revisit the Taking address section. I'm convinced that the goal of DIP25 could be fully realized even with some of the restrictions relaxed/lifted, with less code-breakage as result. In particular: Allowing '' for non-ref parameters and Stack-allocated locals in @system. It encourages bad programming style where heap is preferred over stack, just to silence the compiler. Yes '' is dangerous but it's a separate issue, why conflate a Sealed references DIP with restrictions on normal non ref C-style systems programming? Thanks for reading this far...
Re: DConf 2013 official car/room sharing thread
I don't mind hopping on the early ride, assuming the jet lag has sorted itself. :) Should not be dependent on any specific return journey. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0'; On Apr 22, 2013 5:21 PM, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/22/13 12:10 PM, Andrei Alexandrescu wrote: On 4/21/13 2:23 AM, Lionello Lunesu wrote: Andrei Alexandrescu wrote in message news:kk6llv$29sl$1@**digitalmars.com... I'll stay at Aloft (http://goo.gl/CHmzw) and will drive a compact rental. Will gladly pick up people to and fro that hotel. Andrei Hey Andrei, you still got room in your car? I'm thinking of staying at a hotel nearby. (Aloft is full.) Yup, we should be in good shape. I need to renege on this: as a conference organizer I'll have to leave early and arrive late so being dependent on me would be frustrating. Anyone else with a car staying at Aloft or nearby? Andrei
Re: rvalue references
On 4/24/13 3:08 PM, Tove wrote: On Wednesday, 24 April 2013 at 12:38:19 UTC, Andrei Alexandrescu wrote: On 4/24/13 6:27 AM, Diggory wrote: Anyway, it seems in general that everyone thinks DIP25A should be implemented, or am I mistaken? I'd like to work a bit more on it before a formal review. Andrei If you find the time one day, please revisit the Taking address section. I'm convinced that the goal of DIP25 could be fully realized even with some of the restrictions relaxed/lifted, with less code-breakage as result. In particular: Allowing '' for non-ref parameters and Stack-allocated locals in @system. It encourages bad programming style where heap is preferred over stack, just to silence the compiler. Yes '' is dangerous but it's a separate issue, why conflate a Sealed references DIP with restrictions on normal non ref C-style systems programming? Thanks for reading this far... I agree. At any rate, DIP25 is on the aggressive side right now. I think we should first implement the noncontroversial parts and defer discussion on the breakages. Andrei
Re: Twitter widget cut on dconf.org on Chrome/OSX
On 4/24/13 2:53 PM, Vladimir Panteleev wrote:
On Wednesday, 24 April 2013 at 17:41:20 UTC, Andrei Alexandrescu wrote:
On 4/24/13 1:21 PM, Vladimir Panteleev wrote:
The essential changes are what the second patch is:
http://thecybershadow.net/d/dconf-org-layout/0002-Move-vertical-divider-to-right-hand-column.patch
Awesome, that did the trick at least for me. All -- see any issues?
The vertical bar is gone (because my browser saved the image file to a
relative location different from the server one). Change
url('dotted_v.png') to url('../images/dotted_v.png') to fix it.
Aha, my bad. Thanks, fixed now.
Andrei
Re: D folk in London 2013-05-28
Am 24.04.2013 20:55, schrieb Russel Winder: I will be doing an In the Brain session at Skills Matter 2013-05-28 18:30+01:00: Are Go and D threats to Python? http://skillsmatter.com/podcast/nosql/are-go-and-d-threats-to-python/mh-7066 http://www.meetup.com/skillsmatter/events/115928192/confirm/ Anyone in London at that time is most welcome to come and heckle. What about Julia? :)
Re: D compile time algorithms implementation
On Wednesday, 24 April 2013 at 08:46:03 UTC, khurshid wrote:
Is this code right?
template templateAnd(Preds...)
{ … }
No. templateAnd/templateOr are documented to perform
short-circuit evaluation of the operands.
David
Re: Reducing the inter-dependencies (in Phobos and at large)
24-Apr-2013 20:08, qznc пишет: On Wednesday, 24 April 2013 at 12:03:52 UTC, Dmitry Olshansky wrote: Basically an import graph of Phobos is a rat's nest of mutual imports. With the most of modules being template toolkits you shouldn't pay for what you don't use. Yet it isn't true in general as the module may drag in other modules and with that all of static constructors and/or globals related. Thoughts? Other ideas? I think your concept idea introduces unnecessary complexity. It reduces the complexity of full module imports and helps avoid circular dependencies. Problem is that compiler can't know that all you need that module for is a few isolated templates. If compiler sees this: module abc; import xyz; That means that a) abc depends xyz and thus all of the global state in xyz if there are any. Cue to the idea that globals are bad - you can't easily track the usage of them esp. with separate compilation model. b) if xyz happen to use stuff from abc compiler has to turn on cross module dependency checks and define the order of ctor/dtor evaluation. More importantly in current setting is the fact that it's not good at it and conservative (as it may as well stay forever). c) It may be the case that both modules define ctors and then you have genuine circular dependency. d) Another (bogus) case is that it may as throw up hands in the air and spit a bunch of forward reference bugs. Arguably it could be framed as poor modularity in the Phobos design. A specific problem with templates is that in order to get a duck type you pull the whole innards of module. That's why I see that duck types could and should be peeled off from modules. What are you actually worried about? Compile times? Program size? Startup time? It affects all of it. First and furthermost unnecessary and unavoidable junk that resides in your program. Unnecessary fake dependencies on stuff your module doesn't need. In the end with current setting a single touch of say std.file pulls in a measurable amount of stuff (including ctors/dtors that are run at startup/shutdown) you never wanted. Is compile time a problem? For libraries modularity and minimal dependencies are corner stones of good design. I'd throw among these flexibility and pay and as go principle as other key concerns. The fact that D compiles fast can always be undermined by the way we structure the code and dependencies. Program size should be handled by the compiler. It is much better at pruning dead code. In case it know the code is dead. Throwing bunch of stuff at it that is actually interdependent (the way it's written) doesn't help. The fact that a lot of it is truly independent bears no relation to it partially because of the compilation model. Startup time should be handled by the modules themselves. For example, std.random could initialize the global RNG only on demand. Doesn't help to have gobla data for it. Not to say that the said dead code for lazy initialization would pulled in always. And the other guy that needs global PRGN now has to go through a is-it-inited-yet hook _always_. You suggestion is a net loose on both counts then. To summarize your point - you don't care and/or don't see it as a problem. That's fine but and it then it just doesn't affect you in any way. For Phobos developers to work a bit harder to design a cleaner dependency chain so that you code loads less junk is a net gain. All of that should concern Phobos guys and library writers. Another question - did you ever read C run-time sources? They are carefully modularized by hand so that if you want say printf you get only what you truly need for it. We currently do a very bad job at this kind of thing and it's not entirely the compiler's fault. -- Dmitry Olshansky
Re: Dmitry Olshansky let us prepare
24-Apr-2013 20:56, Jesse Phillips пишет: I'm not locating an email for you so I'm reaching out here. Strange as I believe NG shows the email of a poster. Are you ready? Is there anything one should know to compile and test/use your library? I'll be making an attempt to use it soon so I know how to. Hum. We could review it and such. It works fine as a standalone lib. It doesn't compile yet inside of Phobos even after not a small amount of band-aid workarounds. Thank god recent patches at least stopped it from ICEing on phobos build. See also Reducing the inter-dependencies thread. I'll see what I can do with it during the weekend. Library and benchmarks: https://github.com/blackwhale/gsoc-bench-2012 Docs: http://blackwhale.github.io/phobos/uni.html The module itself is in 2 files - uni.d and the generated unicode_tables.d To use it in place of the current std.uni replace 'std.uni'-'uni' in your programs and compare the results. Make sure that both uni and unicode_tables modules are linked in, rdmd can take care of this dependency. It does require the latest dmd from git master. To sum up - the problem with it ATM is that even if accepted it can't be integrated at whim. It may become possible in the time frame spent on the review though. If that's fine - let's start, otherwise - pick the next module in the queue. -- Dmitry Olshansky
Re: D folk in London 2013-05-28
On Wed, 2013-04-24 at 21:16 +0200, Paulo Pinto wrote: Am 24.04.2013 20:55, schrieb Russel Winder: I will be doing an In the Brain session at Skills Matter 2013-05-28 18:30+01:00: Are Go and D threats to Python? http://skillsmatter.com/podcast/nosql/are-go-and-d-threats-to-python/mh-7066 http://www.meetup.com/skillsmatter/events/115928192/confirm/ Anyone in London at that time is most welcome to come and heckle. What about Julia? :) I will add that if you insist ;-) -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: D compile time algorithms implementation
On 04/24/2013 10:28 PM, Timon Gehr wrote:
On 04/24/2013 09:28 PM, David Nadlinger wrote:
On Wednesday, 24 April 2013 at 08:46:03 UTC, khurshid wrote:
Is this code right?
template templateAnd(Preds...)
{ … }
No. templateAnd/templateOr are documented to perform short-circuit
evaluation of the operands.
David
I think that is what the implementation intends to do. I am more worried
about the expressions reading similar to:
.templateAnd(Preds[0..$/2])
The code appears to be entirely untested.
(Also, the lookup rules have been changed for function calls and
template instantiations on eponymous template symbols, and therefore the
'.' prefix is not needed anymore.)
Re: D compile time algorithms implementation
On 04/24/2013 09:28 PM, David Nadlinger wrote:
On Wednesday, 24 April 2013 at 08:46:03 UTC, khurshid wrote:
Is this code right?
template templateAnd(Preds...)
{ … }
No. templateAnd/templateOr are documented to perform short-circuit
evaluation of the operands.
David
I think that is what the implementation intends to do. I am more worried
about the expressions reading similar to:
.templateAnd(Preds[0..$/2])
The code appears to be entirely untested.
Re: Mixin template parameters / mixin template literals
On 04/24/2013 07:07 PM, Diggory wrote:
One way this could be done is by expanding on lazy parameters. Perhaps
you could specify parameters for a lazy argument, so instead of always
getting a delegate of type T delegate(), you could get one of type T
delegate(U a, V b).
For example, a parameter could be:
void f(lazy bool exp(int a, int b)) {
bool result = exp(1, 2);
}
Then when you call that:
f(a b)
The names 'a' and 'b' come from the parameter list for 'f'. I would
definitely vote for this as a feature!
This is a little dangerous as it looks like an ordinary expression but
has to somehow affect symbol scoping.
Re: Mixin template parameters / mixin template literals
Tove:
how about?
sort!(q{a b})(array);
Today we usually write it this way:
array.sort!q{ a b };
Bye,
bearophile
Re: D folk in London 2013-05-28
Am 24.04.2013 22:27, schrieb Russel Winder: On Wed, 2013-04-24 at 21:16 +0200, Paulo Pinto wrote: Am 24.04.2013 20:55, schrieb Russel Winder: I will be doing an In the Brain session at Skills Matter 2013-05-28 18:30+01:00: Are Go and D threats to Python? http://skillsmatter.com/podcast/nosql/are-go-and-d-threats-to-python/mh-7066 http://www.meetup.com/skillsmatter/events/115928192/confirm/ Anyone in London at that time is most welcome to come and heckle. What about Julia? :) I will add that if you insist ;-) I already saw a few of your recorded talks and they are quite interesting. Sadly I am located in Düsseldorf. As for Julia, I just gave the hint, because from the videos they have available on their site, the language seems to already beat CPython and many in the scientific community are busy porting their R and Python code to Julia. Then again, this might be just Julia PR. -- Paulo
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 20:50:31 UTC, bearophile wrote:
Today we usually write it this way:
array.sort!q{ a b };
Thanks. (I just copied it from the docs)
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 20:32:16 UTC, Timon Gehr wrote:
On 04/24/2013 07:07 PM, Diggory wrote:
One way this could be done is by expanding on lazy parameters.
Perhaps
you could specify parameters for a lazy argument, so instead
of always
getting a delegate of type T delegate(), you could get one of
type T
delegate(U a, V b).
For example, a parameter could be:
void f(lazy bool exp(int a, int b)) {
bool result = exp(1, 2);
}
Then when you call that:
f(a b)
The names 'a' and 'b' come from the parameter list for 'f'. I
would
definitely vote for this as a feature!
This is a little dangerous as it looks like an ordinary
expression but has to somehow affect symbol scoping.
Surely it's no more dangerous than lazy parameters already are.
(they are already converted into a hidden delegate, it just
happens to take no parameters at the moment)
Re: Mixin template parameters / mixin template literals
On 04/24/2013 11:03 PM, Diggory wrote:
On Wednesday, 24 April 2013 at 20:32:16 UTC, Timon Gehr wrote:
On 04/24/2013 07:07 PM, Diggory wrote:
One way this could be done is by expanding on lazy parameters. Perhaps
you could specify parameters for a lazy argument, so instead of always
getting a delegate of type T delegate(), you could get one of type T
delegate(U a, V b).
For example, a parameter could be:
void f(lazy bool exp(int a, int b)) {
bool result = exp(1, 2);
}
Then when you call that:
f(a b)
The names 'a' and 'b' come from the parameter list for 'f'. I would
definitely vote for this as a feature!
This is a little dangerous as it looks like an ordinary expression but
has to somehow affect symbol scoping.
Surely it's no more dangerous than lazy parameters already are. (they
are already converted into a hidden delegate, it just happens to take no
parameters at the moment)
It surely is. 'lazy' parameters do not affect symbol lookup in the
passed expressions.
Re: [ gtkD ] Question about mouse press event in Notebook ...
On 04/24/2013 08:43 AM, Super66Super wrote: Sorry, you don't understand me. I want something like this: ACII ART I know that function addOnButtonPressd() prevents change the order of the tabs ... Did you have any idea ? Thanks for your time. I see what you mean, using the enterNotify and leaveNotify events you can track if the mouse is over an tab and skip the mousePress event. The tab label do need to be wrapped in an EventBox for this to work. http://dpaste.dzfl.pl/3bb9ab78 -- Mike Wey
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 20:32:16 UTC, Timon Gehr wrote:
Then when you call that:
f(a b)
This is a little dangerous as it looks like an ordinary
expression but has to somehow affect symbol scoping.
That's true, and that was one reason I suggested some kind of
template mixin literal. On the other hand, that's just an extreme
version of what happens with lazy, where at the call site you
can't tell that the argument side effects are not produced
immediately. Without experience with features like this it's hard
to tell if their usefulness pays for their cost, but it seems to
me that something like this could make for very powerful macros.
On Wednesday, 24 April 2013 at 17:38:34 UTC, Tove wrote:
how about?
sort!(q{a b})(array);
http://dlang.org/lex.html#TokenString
I was not aware of the token strings, is that new? Boy, I really
should spend more time around here. That's an excellent
suggestion, although I think these mixin parameters we are
discussing are more like mixin template parameters than mixin
string parameters.
Re: [ gtkD ] Question about mouse press event in Notebook ...
It works ! Really, really thanks !
Re: Mixin template parameters / mixin template literals
Consider: sort!(a b)(array); This is almost perfect, except for a b being a string instead of real code. If a b was an actual block of code it could be syntax highlighted by the editor, directly grammar checked by compiler, etc. Is changing the language the right approach to this or would smarter IDEs possibly be a better direction?
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 17:38:34 UTC, Tove wrote:
On Wednesday, 24 April 2013 at 02:18:07 UTC, Luís Marques wrote:
Consider:
sort!(a b)(array);
how about?
sort!(q{a b})(array);
http://dlang.org/lex.html#TokenString
Token strings solve all the problems the OP mentioned, but they
do not solve the one problem he didn't mention - closures:
int[] array = [3, 1, 5, 2, 7];
int x = 4;
writeln(array.filter!(a = a x)()); // works as expected
and prints [3, 1, 2]
writeln(array.filter!q{a x}()); // Error: undefined
identifier x
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 23:04:02 UTC, ixid wrote: Is changing the language the right approach to this or would smarter IDEs possibly be a better direction? A smarter IDE always helps :-) It might not be worth changing the language for this (or it might), but changing the language to have first-class support of constructs like this would allow tighter checking of the mixed-in code, which seems to me to be mainly the role of the compiler, and not of the IDE. For instance, by using token strings, as suggested by Tove, you can have a tighter grip on the mixed-in string, which should lead to smarter error messages (gramatical check), but not as good as first-class support (semantic checks, etc). But I don't think this is only about error checking, it's about creating a better abstraction: I think template mixin are a less brittle abstraction than string mixins, but without the argument type modifiers they can't replace the string mixins. But don't take my opinion too seriously, I'm sure you guys know the language better than I do :-)
Re: Mixin template parameters / mixin template literals
On Wednesday, 24 April 2013 at 23:42:57 UTC, Idan Arye wrote:
Token strings solve all the problems the OP mentioned, but they
do not solve the one problem he didn't mention - closures:
int[] array = [3, 1, 5, 2, 7];
int x = 4;
writeln(array.filter!(a = a x)()); // works as expected
and prints [3, 1, 2]
writeln(array.filter!q{a x}()); // Error: undefined
identifier x
Yeah, it was unfortunate that the problems I exemplified could be
solved by the token strings, without fulling solving the problem,
making the issue seem more superficial than it is. Your example
is better.
Notice that my code worked for your example, if you changed it to
match your scenario:
// we have to move this outside of main,
// because the mixin template cannot be there
int[] array;
int x = 4;
mixin template Greater() {
auto Greater = () = a x;
}
(...)
This seems to work. So, as I said, the infrastructure is there,
we are just lacking the convenience of template mixin literals.
Without that we have this unwieldy code, which otherwise seems
fine.
Re: Dmitry Olshansky let us prepare
The only issue I have is with the git master requirement, but there is a beta coming up so I'll plan around that. As for the NG email thing, the new web interface doesn't provide it and couldn't find an archive from you or want to load up a newsreader. :P
Re: Random double
Tue, 23 Apr 2013 22:59:41 +0200: bearophile wrote qznc: I want to generate a random double value, excluding wierdos like NaN and Infinity. However, std.random.uniform seems to be useless. Can you explain why you need uniform doubles in their whole range? I think I have never had to generate them so far. Maybe for a unittest? Good guess. :) I want to port QuickCheck. The core problem is: Given a type T, generate a random value. https://bitbucket.org/qznc/d-quickcheck/src/ eca58bb97b24cedd6128cdda77bbebeaf1689956/quickcheck.d?at=master Also note by their nature doubles are not equally spread across the line of Reals, so getting a truly uniform distribution is hard or impossible. It also raises the question what uniform means in the context of floating point. Uniform over the numbers or uniform over the bit patterns?
Re: Random double
Tue, 23 Apr 2013 13:49:48 -0700: Ali Çehreli wrote
On 04/23/2013 11:55 AM, qznc wrote: Tue, 23 Apr 2013 16:43:14 +0200:
qznc wrote
I want to generate a random double value, excluding wierdos like
NaN and Infinity. However, std.random.uniform seems to be useless. I
tried things like
std.random.uniform( double.min, double.max);
std.random.uniform(-double.max, double.max);
std.random.uniform(0.0, double.max);
However, I just get Inf values. :(
I assume this is due to floating point computation within uniform,
which easily becomes Inf, if you come near the double.max boundary.
Should that be considered a bug? Nevertheless, any ideas how to work
around that issue?
Using a union seems to be a good workaround:
union foo { ulong input; double output; }
foo val = void;
do {
val.input = uniform(ulong.min, ulong.max);
} while (val.output == double.infinity
|| val.output == -double.infinity || val.output !=
val.output);
return val.output;
Maybe the implementation of uniform should use a similar trick?
Unfortunately, that will not produce a uniform distribution. The results
will mostly be in the range [-0.5, 0.5]. The lower and higher values
will have half the chance of the middle range:
Interesting. Why [-0.5,0.5], though? I would have expected [-1.0,1.0] from
Clugston's article.
http://dlang.org/d-floating-point.html
Re: Random double
On Wednesday, 24 April 2013 at 06:37:50 UTC, qznc wrote: It also raises the question what uniform means in the context of floating point. Uniform over the numbers or uniform over the bit patterns? I'd like to mention that there's no such mathematical object as uniform distribution on [0..+infinity). On the other hand, a (discrete) uniform distribution of the bit pattern, or restricted bit pattern (that is, no special values), is of course valid. A random positive double as a bit pattern most closely resembles exponential distribution I think.
Re: Quadratic time to sort in a simple case?
23-Apr-2013 05:17, Xinok пишет: On Saturday, 20 April 2013 at 16:35:25 UTC, Dmitry Olshansky wrote: And this all is good but TimSort allocates O(N) memory. The constant in front of N is smallish less then 1.0 but it could cause some grief. Worst case is O(n/2), but it starts small and doubles in size as needed. On a partially sorted array, it may only use a small amount of memory. Good to know, still it's something to keep in mind. Especially for allocation-free minded folks. -- Dmitry Olshansky
Re: Quadratic time to sort in a simple case?
24-Apr-2013 01:09, Ivan Kazmenko пишет: And on Tuesday, 23 April 2013 at 01:10:26 UTC, Xinok wrote: I filed a bug report for this issue a year ago: http://d.puremagic.com/issues/show_bug.cgi?id=7767 I've been meaning to fix this issue myself. Time allowing, I'll do it soon. What I wonder now, what would be the goal of such a fix? One possible goal would be to have an O(n log n) worst case sort. And that would perhaps cost some speed and/or memory on average. Besides, such a sort function is already implemented (TimSort), so it's just a matter of setting the default then. A good unstable sort can do the job faster (at the very least not slower) then a good stable sort. I'm looking forward to a version of Introsort that Xinok has in mind as a Q-sort fix. -- Dmitry Olshansky
Re: WinAPI callbacks and GC
On Tue, 23 Apr 2013 22:21:27 +0100, Jack Applegame jappleg...@gmail.com
wrote:
I'm writing Ctrl-C handler for console application for Windows:
extern(Windows) {
int CtrlHandler(uint flag) nothrow {
auto tmp = new SomeClass; // is it safe?
...
return true;
}
}
...
SetConsoleCtrlHandler(CtrlHandler, true);
...
According WinAPI documentation, CtrlHandler will be called in new
additional thread. Is it safe to allocate GC memory in NOT Phobos
threads?
If not, how to make it safe? I'm trying call thread_attachThis() at the
beginning of CtrlHandler fucntion, but it doesn't compile because
thread_attachThis() is not nothrow.
You are correct in that the issue with this handler is that it's likely
called in a thread created by the Win32 runtime which the D GC has no
knowledge of. And, because of this wont get paused when the GC runs a
collection, which is an issue because your allocation above might happen
during a GC collection, and the GC is likely to have an 'issue' with it.
The issue here is a timing window. Lets assume the GC is busy performing
a collection when the handler runs.
If you wrap the thread_attachThis() in a try/catch block as evilrat has
shown this should solve the nothrow issue. But, the GC is unlikely to
then pause your thread - because it's already done the thread pausing and
is busy marking and sweeping so your thread will continue to run and
allocate during collection.
The other idea is to call GC.disable() to disable automatic collection at
the start of the handler, and GC.enable() at the end. But again, if
collection has already started this might not work, might fail horribly,
and wont protect you.
Someone needs to check the GC code, and thread_attachThis to see if it can
handle the situation you've presented.
Until then, I would perform manual memory allocation. I am not sure how
in D, but you need something like placement new to construct a class in
a previously allocated block of memory (allocated with malloc or similar).
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Random double
On Wednesday, 24 April 2013 at 06:56:44 UTC, Ivan Kazmenko wrote: On Wednesday, 24 April 2013 at 06:37:50 UTC, qznc wrote: It also raises the question what uniform means in the context of floating point. Uniform over the numbers or uniform over the bit patterns? I'd like to mention that there's no such mathematical object as uniform distribution on [0..+infinity). ... you neither can choose a random real number in any interval ...
Re: Random double
On Wednesday, 24 April 2013 at 10:26:19 UTC, Andrea Fontana wrote: I'd like to mention that there's no such mathematical object as uniform distribution on [0..+infinity). ... you neither can choose a random real number in any interval ... ... but that is at least valid mathematically, albeit achievable only approximately on a computer. On the other hand, an infinite case, even if it would be possible, won't be practical anyway since with probability 1, the result would require more bits to store than available on any modern hardware.
Re: Random double
On Wednesday, 24 April 2013 at 10:33:49 UTC, Ivan Kazmenko wrote: On Wednesday, 24 April 2013 at 10:26:19 UTC, Andrea Fontana wrote: I'd like to mention that there's no such mathematical object as uniform distribution on [0..+infinity). ... you neither can choose a random real number in any interval ... ... but that is at least valid mathematically, albeit achievable only approximately on a computer. On the other hand, an infinite case, even if it would be possible, won't be practical anyway since with probability 1, the result would require more bits to store than available on any modern hardware. I mean that a random real number is not valid mathematically too. In any given real interval there are infinite numbers, how you can choose a number in an infinite (and non-numerable!) interval? I think you always need some sampling. What's the probability to guess a precise number in [0..1]? I think is 0 as long as you have infinite numbers. What's the probability to guess a interval in [0..1]? I think it's the interval size. Am I wrong?
Re: Random double
On Wednesday, 24 April 2013 at 10:46:57 UTC, Andrea Fontana wrote: What's the probability to guess a precise number in [0..1]? I think is 0 as long as you have infinite numbers. Right. What's the probability to guess a interval in [0..1]? I think it's the interval size. Right again. I mean that a random real number is not valid mathematically too. In any given real interval there are infinite numbers, how you can choose a number in an infinite (and non-numerable!) interval? I think you always need some sampling. Am I wrong? In a sense, yes. A continuous probability distribution is well-defined. In short, as you pointed out, you can coherently define the probabilities to hit each possible segment and get a useful mathematical object, though the probability to hit each single point is zero. It's no less strict than a typical high school definition of an integral. See the link for more info: http://en.wikipedia.org/wiki/Probability_distribution#Continuous_probability_distribution .
Postblit isn't called on rvalue return
For this program:
import std.stdio;
struct S
{
ubyte* b;
ubyte buf[128];
this(this)
{
writeln(postblit);
}
}
auto ref makeS()
{
S s;
s.b = s.buf;
writeln(made S at , cast(void*)s, , s.b == , s.b);
return s;
}
void main()
{
S s = makeS();
writeln(got back S at , cast(void*)s, , s.b == ,
s.b);
}
I get
made S at 18FC64, s.b == 18FC68
got back S at 18FCF4, s.b == 18FC68
as output for dmd 2.062. Patching s.b to point into the newly
allocated struct in postblit is crucial here, but it seems like
the postblit constructor isn't called, nor is there any attempt
to optimize away the temporary in `makeS()` even with -O.
Is this is a bug or am I doing something wrong?
Re: WinAPI callbacks and GC
On Wednesday, 24 April 2013 at 09:51:29 UTC, Regan Heath wrote: Until then, I would perform manual memory allocation. I am not sure how in D, but you need something like placement new to construct a class in a previously allocated block of memory (allocated with malloc or similar). look at __gshared, might be useful for when one need to interop things with non D code. http://dlang.org/attribute.html#gshared
Re: Random double
On Wednesday, 24 April 2013 at 06:56:44 UTC, Ivan Kazmenko wrote: On Wednesday, 24 April 2013 at 06:37:50 UTC, qznc wrote: It also raises the question what uniform means in the context of floating point. Uniform over the numbers or uniform over the bit patterns? I'd like to mention that there's no such mathematical object as uniform distribution on [0..+infinity). On the other hand, a (discrete) uniform distribution of the bit pattern, or restricted bit pattern (that is, no special values), is of course valid. A random positive double as a bit pattern most closely resembles exponential distribution I think. Of course not, since infinity is not a number. However, double.max is not infinity, but 0x1p+1024. See http://dlang.org/d-floating-point.html
Re: Random double
On Tuesday, 23 April 2013 at 14:43:15 UTC, qznc wrote:
I want to generate a random double value, excluding wierdos
like NaN and Infinity. However, std.random.uniform seems to be
useless. I tried things like
std.random.uniform( double.min, double.max);
std.random.uniform(-double.max, double.max);
std.random.uniform(0.0, double.max);
However, I just get Inf values. :(
I've just tried to reproduce that. The first line gives a
deprecation warning, the second gives infinities, but the third
line does give me non-infinities. I've checked that under DMD
2.062 on Windows, and the hardware is Intel Xeon E5450.
Here is an example:
-
import std.random;
import std.stdio;
void main ()
{
foreach (i; 0..5)
{
double x = uniform (-double.max, +double.max);
writefln (%25a %30.20g, x, x);
}
foreach (i; 0..5)
{
double x = uniform ( 0, +double.max);
writefln (%25a %30.20g, x, x);
}
}
-
And an example output is:
-
infinf
infinf
infinf
infinf
infinf
0x1.9d6fad0f9d6f9p+1023 1.4516239851099787345e+308
0x1.b53e4c11b53e3p+1020 1.919017005286872499e+307
0x1.5dc7e6d15dc7dp+1020 1.5351529811186840176e+307
0x1.bd608187bd606p+1023 1.5637717442069522658e+308
0x1.e38d5871e38d4p+1023 1.6978092693521789428e+308
-
Perhaps std.random.uniform(-double.max, double.max); call does
indeed cause overflow. If the example does not work for you, try
double.max / 2 or double.max / 4 boundary instead.
That said, note that the values generated this way will have
exponent close to the maximal possible (1024), and that may be
not the only case you wish to cover. Your suggestion to generate
64-bit patterns instead of real numbers, probably excluding
special values (all-0 or all-1), sounds like the way to go. I'd
include some important cases (like +-0 and +-1) manually too.
Ivan Kazmenko.
Re: Random double
On Wednesday, 24 April 2013 at 13:30:41 UTC, Ivan Kazmenko wrote: probably excluding special values (all-0 or all-1), I meant exponent bits being all 0 or all 1, sorry. That's where the special values reside, at least according to IEEE-754-1985 here: http://en.wikipedia.org/wiki/IEEE_754-1985
Re: Random double
On 04/23/2013 10:59 PM, bearophile wrote: Also note by their nature doubles are not equally spread across the line of Reals, so getting a truly uniform distribution is hard or impossible. More than that -- the number of unique values generated by the underlying RNG should (for Mersenne Twister) be much smaller than the number of unique double values in [-double.max, double.max], because the type used is uint32. I think the infinities probably come from the fact that the returned random value is generated by the following expression: _a + (_b - _a) * cast(NumberType) (urng.front - urng.min) / (urng.max - urng.min); So, you've got a double.max + (double.max - double.min) in there which evaluates to inf.
Internal error: ../ztc/cgcs.c
import std.stdio;
int[2] getSize() {
return [42, 23];
}
int width() {
return getSize()[0];
}
void main()
{
writeln(Hello world!);
}
Compilation output:
Internal error: ../ztc/cgcs.c 343
http://dpaste.1azy.net/a1897e84
I don't know if this should compile (but I think so) or if the
error message is a bit ... in need of improvement.
Thoughts?
Re: Internal error: ../ztc/cgcs.c
On 04/24/2013 10:25 PM, Namespace wrote:
import std.stdio;
int[2] getSize() {
return [42, 23];
}
int width() {
return getSize()[0];
}
void main()
{
writeln(Hello world!);
}
Compilation output:
Internal error: ../ztc/cgcs.c 343
http://dpaste.1azy.net/a1897e84
I don't know if this should compile (but I think so) or if the error
message is a bit ... in need of improvement.
Thoughts?
An Internal error is always a compiler bug.
http://d.puremagic.com/issues/enter_bug.cgi
Re: Internal error: ../ztc/cgcs.c
Namespace:
import std.stdio;
int[2] getSize() {
return [42, 23];
}
int width() {
return getSize()[0];
}
void main()
{
writeln(Hello world!);
}
Compilation output:
Internal error: ../ztc/cgcs.c 343
I think this is already fixed in the current dmd 2.063alpha.
Bye,
bearophile
Re: Postblit isn't called on rvalue return
On Wednesday, 24 April 2013 at 11:42:01 UTC, Sebastian Graf wrote:
For this program:
import std.stdio;
struct S
{
ubyte* b;
ubyte buf[128];
this(this)
{
writeln(postblit);
}
}
auto ref makeS()
{
S s;
s.b = s.buf;
writeln(made S at , cast(void*)s, , s.b == , s.b);
return s;
}
void main()
{
S s = makeS();
writeln(got back S at , cast(void*)s, , s.b == ,
s.b);
}
I get
made S at 18FC64, s.b == 18FC68
got back S at 18FCF4, s.b == 18FC68
as output for dmd 2.062. Patching s.b to point into the newly
allocated struct in postblit is crucial here, but it seems like
the postblit constructor isn't called, nor is there any attempt
to optimize away the temporary in `makeS()` even with -O.
Is this is a bug or am I doing something wrong?
First, as the local 's' in makeS() is local, it cannot be
returned by ref. So, the 'auto ref' return type of makeS()
becomes by-value.
However, rvalues are never copied in D. The compiler
automatically moves the bits of the rvalue to the left-hand side
object, and to be correct, it also elides the destructor
execution on the rvalue. (Note that this is not the RVO and NRVO
optimization that C++ allows. This is a language feature in D.)
For that feature to be available at all, struct objects must not
have references to themselves; D explicitly makes it illegal.
So, unfortunately your S is not a valid type in D because of the
following line (.ptr is added by me):
s.b = s.buf.ptr;
Ali
Re: Internal error: ../ztc/cgcs.c
I think this is already fixed in the current dmd 2.063alpha. Bye, bearophile You walking encyclopedia. ;) Good to know.
Re: Postblit isn't called on rvalue return
On Wednesday, 24 April 2013 at 20:53:11 UTC, Ali Çehreli wrote: First, as the local 's' in makeS() is local, it cannot be returned by ref. So, the 'auto ref' return type of makeS() becomes by-value. However, rvalues are never copied in D. The compiler automatically moves the bits of the rvalue to the left-hand side object, and to be correct, it also elides the destructor execution on the rvalue. (Note that this is not the RVO and NRVO optimization that C++ allows. This is a language feature in D.) For that feature to be available at all, struct objects must not have references to themselves; D explicitly makes it illegal. So, unfortunately your S is not a valid type in D because of the following line (.ptr is added by me): s.b = s.buf.ptr; Ali Thanks, this explains a lot. I was interfacing with a C library when tracing back an error to this. I eagerly submitted a Bug report http://d.puremagic.com/issues/show_bug.cgi?id=9985. Seems to me that dmd doesn't do NRVO (?), see the issue.
Re: Postblit isn't called on rvalue return
On Wednesday, 24 April 2013 at 21:36:48 UTC, Sebastian Graf wrote: Seems to me that dmd doesn't do NRVO (?), see the issue. I can see that NRVO would be faster than the extra bit-copy. Especially the last one of the following set of blog posts is relevant. The posts explain the rationale for this design decision (I don't remember whether they provide an exact answer to your question): http://bartoszmilewski.com/2008/10/18/who-ordered-rvalue-references-part-1/ http://bartoszmilewski.com/2008/10/26/who-ordered-rvalue-references-part-2/ http://bartoszmilewski.com/2008/11/03/who-ordered-rvalue-references-part-3/ Ali
Re: Quadratic time to sort in a simple case?
On Friday, 19 April 2013 at 22:37:45 UTC, Ivan Kazmenko wrote: So, why isn't TimSort the default? I would actually argue for this, not for safety (introsort is an adequate solution) but for different reasons. Timsort is stable and it's faster on data with low entropy, being nearly instantaneous on already sorted lists. I would guess it's the better choice for most cases. Then for those cases where stable sorting isn't necessary and unstable sorting would be faster, the user could choose the second option.
[Issue 9976] Needlessly large instantiation depth in std.typetuple algorithms
http://d.puremagic.com/issues/show_bug.cgi?id=9976 --- Comment #8 from khurshid khurshid.normura...@gmail.com 2013-04-23 23:18:33 PDT --- (In reply to comment #7) (In reply to comment #5) And this :)) template Reverse(TList...) [snip] https://github.com/D-Programming-Language/phobos/pull/1274 Thanks, Kenji Hara. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9931] Mac OS X ABI not followed when returning structs for extern (C)
http://d.puremagic.com/issues/show_bug.cgi?id=9931 --- Comment #20 from Jacob Carlborg d...@me.com 2013-04-23 23:30:49 PDT --- (In reply to comment #19) It doesn't do anything wrong, it just sets EAX to contain the hidden pointer before returning. This is required by the SysV IA-32 ABI but apparently not on OSX. First, Mac OS X uses a modified version of the SysV IA-32 ABI (there's a link a couple of posts up). Second, If an extern (C) function doesn't behave the same as a C function, in regards to ABI and calling conventions, I would say that the compiler is doing something wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8321] std.range.put doesn't work with RefCounted output range
http://d.puremagic.com/issues/show_bug.cgi?id=8321 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-04-23 23:57:53 PDT --- Pull request to enable unittest. https://github.com/D-Programming-Language/phobos/pull/1276 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9963] Absurdly Inefficient Codegen For Adding Boolean Predicates
http://d.puremagic.com/issues/show_bug.cgi?id=9963 --- Comment #5 from Walter Bright bugzi...@digitalmars.com 2013-04-24 00:08:26 PDT --- https://github.com/D-Programming-Language/dmd/pull/1928 brings the code generated to: L2B:mov RBX,-8[RBP] mov CL,[RBX][R8] cmp R9B,CL adc R11,0 cmp R9B,CL sbb RSI,0h inc R8 cmp R8,-010h[RBP] jb L2B -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8597] UFCS fails when used with a pointer to enum and implicit dereferencing
http://d.puremagic.com/issues/show_bug.cgi?id=8597 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Kenji Hara k.hara...@gmail.com 2013-04-24 00:34:21 PDT --- There was a similar issue opened where someone made a rationale, it was about not wanting to accidentally pass structs by value, or something like that. I'll wait for someone to give a better response. Currently automatic pointer dereference is not supported in UFCS name look up. So this is an enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8213] Incorrect error message with pointer to ubyte[] and front
http://d.puremagic.com/issues/show_bug.cgi?id=8213 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-04-24 00:34:19 PDT --- (In reply to comment #2) The error gives the correct type now: --- main.d(12): Error: template std.array.front does not match any function template declaration. Candidates are: phobos path\std\array.d(584):std.array.front(T)(T[] a) if (!isNarrowString!(T[]) !is(T[] == void[])) phobos path\std\array.d(605):std.array.front(T)(T[] a) if (isNarrowString!(T[])) phobos path\std\array.d(584): Error: template std.array.front cannot deduce template function from argument types !()(ubyte[]*) main.d(21): Error: template instance main.S!(ubyte[]) error instantiating main.d(22): Error: not a property s.front --- In 2.063a, error message with UFCS issues are got fixed. So I'll close this. Currently automatic pointer dereference is not supported in UFCS name look up. For the issue, I'll mark issue 8597 as enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9590] UFCS does not work with void lazy expressions
http://d.puremagic.com/issues/show_bug.cgi?id=9590 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-04-24 01:01:53 PDT --- Problem fixed in 2.063a. https://github.com/D-Programming-Language/dmd/pull/1929 The pull request adds only a test in dmd repo. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
