Re: Pacikage level access broken?
On 2012-04-23 01:21, Era Scarecrow wrote:
I think I have a misunderstanding of how 'package' is suppose to work.
How I understand it, you will give access to the directory, unlike
private which will hide it outside of the same file.
This problem comes up since a struct is declared inside a package (and
even instantiated), however access to it is lacking. Here's my two
sources. Using DMD v2.059 (Win32)
--- t1.d
module t1;
import std.stdio;
class Priv { //private by default
int i;
struct S {
int s_i;
}
public is the default access level.
--
/Jacob Carlborg
Re: Keyword to avoid not null references
I made several tests with NotNull yesterday and actually they all
passed.
In special cases i didn't get a compiler error but then a runtime
error is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must exist a way that both
NotNull!(Foo) nf = new Foo();
foo(nf);
bar(nf);
and furhtermore
Foo f = new Foo();
foo(f);
bar(f);
compiles.
We need some hack, implicit cast or compiler cast that cast or
passes Foo to NotNull!(Foo).
Any suggestions?
Re: Keyword to avoid not null references
On 23.04.2012 12:06, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 09:14:12 +0200, Namespace rswhi...@googlemail.com
wrote:
I made several tests with NotNull yesterday and actually they all passed.
In special cases i didn't get a compiler error but then a runtime
error is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must exist a way that both
NotNull!(Foo) nf = new Foo();
foo(nf);
bar(nf);
and furhtermore
Foo f = new Foo();
foo(f);
bar(f);
compiles.
We need some hack, implicit cast or compiler cast that cast or passes
Foo to NotNull!(Foo).
Any suggestions?
No. The whole point of NotNull is that it should enforce not being null.
Allowing implicit casting from PossiblyNull to NotNull would break this.
Just include obligatory run-time check when crossing null-NotNull
boundaries.
--
Dmitry Olshansky
Re: Keyword to avoid not null references
No. The whole point of NotNull is that it should enforce not being null. Allowing implicit casting from PossiblyNull to NotNull would break this. Then i'm further for a keyword that checks an object for not null. Or you check at runtime to avoid null, e.g. with assert or enforce.
Re: Keyword to avoid not null references
On Monday, 23 April 2012 at 08:47:22 UTC, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 10:38:27 +0200, Dmitry Olshansky
dmitry.o...@gmail.com wrote:
On 23.04.2012 12:06, Simen Kjaeraas wrote:
On Mon, 23 Apr 2012 09:14:12 +0200, Namespace
rswhi...@googlemail.com
wrote:
I made several tests with NotNull yesterday and actually
they all passed.
In special cases i didn't get a compiler error but then a
runtime
error is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must exist a way that both
NotNull!(Foo) nf = new Foo();
foo(nf);
bar(nf);
and furhtermore
Foo f = new Foo();
foo(f);
bar(f);
compiles.
We need some hack, implicit cast or compiler cast that cast
or passes
Foo to NotNull!(Foo).
Any suggestions?
No. The whole point of NotNull is that it should enforce not
being null.
Allowing implicit casting from PossiblyNull to NotNull would
break this.
Just include obligatory run-time check when crossing
null-NotNull boundaries.
Which carries with it hidden runtime costs that are
unacceptable to some.
The point of NotNull is twofold - safety (you know it's not
null) and speed
(you don't need to check if it's null). The latter goes out the
window if
implicit casting were allowed.
Allow both: a type for explicit not null which cannot be changed
to null and a keyword or some other construct which can check any
possible object at compile time if it's null.
Re: Keyword to avoid not null references
Am 23.04.2012 09:14, schrieb Namespace:
I made several tests with NotNull yesterday and actually they all passed.
In special cases i didn't get a compiler error but then a runtime error
is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must exist a way that both
NotNull!(Foo) nf = new Foo();
foo(nf);
bar(nf);
and furhtermore
Foo f = new Foo();
foo(f);
bar(f);
compiles.
We need some hack, implicit cast or compiler cast that cast or passes
Foo to NotNull!(Foo).
Any suggestions?
If you replace
alias _notNullData this;
with
@property T _notNullDataHelper()
{
assert(_notNullData !is null);
return _notNullData;
}
alias _notNullDataHelper this;
It will not be possible to assign to _notNullData
It will still be possbile to use from other modules
NotNull!T will implicitly convert to T (your first case)
However T will not implicitly convert to NotNull!T (as far as I know
such a implict conversion is not possible in D, i suggested a @implicit
modifier for a constructor to allow such implicit type conversions, but
it was rejected)
Kind Regards
Benjamin Thaut
Re: Question about arrays
On Sat, 21 Apr 2012 18:25:44 -0400, Ali Çehreli acehr...@yahoo.com wrote:
In D, arrays are what they should have been in C :). A pointer and a
size. Something the equivalent of the following (for the int type):
struct int_Array
{
int * elements;
size_t number_of_elements;
}
Technically speaking, the number of elements comes first in the memory
layout. The fact that even seasoned D coders get it wrong (in fact, I had
to look it up in druntime to be sure!) is a testament to how
well-encapsulated D slices actually are.
-Steve
Re: Pacikage level access broken?
On Mon, 23 Apr 2012 01:32:25 +0200, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday, April 23, 2012 01:21:21 Era Scarecrow wrote: I think I have a misunderstanding of how 'package' is suppose to work. How I understand it, you will give access to the directory, unlike private which will hide it outside of the same file. 1. Package access is _very_ broken: http://d.puremagic.com/issues/show_bug.cgi?id=143 2. I'm not sure that your code is even using package properly. Note that t1 and t2 arguably don't _have_ a package. They're not pkg.t1 and pkg.t2, they're just straight t1 and t2. So, even if package were working properly, I'm not sure that t1 and t2 would ever be considered to be in the same package. - Jonathan M Davis These things comes up quite often: shared is broken, alias this is broken, package is broken, scope is broken, X is broken, Y is broken. I believe this should be addressed in a very visible place to avoid getting the impression that everything in D is horribly broken. The frontpage on the wiki could list incomplete features that you should steer away to avoid hitting compiler bugs. http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel#DMDCompilerStability includes some of these issues, but it's hidden and doesn't show it in an easy to grasp way for beginners. It shouldn't be necessary to be following the development of D intimately to know what features are implemented and considered production ready. I think it gives a better impression to list the features still under development than to let (new) users hit bugs within the first hours (read: minutes) of hacking around.
Re: avoid toLower in std.algorithm.sort compare alias
On Sat, 21 Apr 2012 19:24:56 -0400, Jay Norwood j...@prismnet.com wrote: While playing with sorting the unzip archive entries I tried use of the last example in http://dlang.org/phobos/std_algorithm.html#sort std.algorithm.sort!(toLower(a.name) toLower(b.name),std.algorithm.SwapStrategy.stable)(entries); It was terribly slow for sorting the 34k entries in my test case. I'd guess it is doing the toLower call on both strings for every compare. It was much, much faster to add an entries.lowerCaseName = std.string.toLower(entries.name) foreach entry prior to the sort execution and then use std.algorithm.sort!(a.lowerCaseName b.lowerCaseName ,std.algorithm.SwapStrategy.stable)(entries); The difference was on the order of 10 secs vs no noticeable delay when executing the sort operation in the debugger. I'll point out what I haven't seen yet: the issue is not so much toLower being called on every comparison, but more that toLower allocates (and then throws away!). I think using std.string.icmp is the best solution. I would expect it to outperform even schwartz sort. Note, to answer your question elsewhere, the comment is accurate, std.uni.toLower(a) is a function that accepts a dchar, not a string. What the comment is saying is that for the ranges (i.e. strings) given, it runs the given comparison on the std.uni.toLower() result for each element (i.e. dchar). -Steve
Re: Pacikage level access broken?
On 2012-04-23 10:26, Era Scarecrow wrote: On Monday, 23 April 2012 at 06:19:12 UTC, Jacob Carlborg wrote: public is the default access level. So it is... That explains why the tests came out backwards on the results Wasn't it private by default in C++? I honestly don't know sometimes. I think so. If you use class it's private by default. If use struct it's public by default. That's basically the only difference between class and struct in C++, if I recall correctly. -- /Jacob Carlborg
Range of random numbers
For some reason this got lost in the ether, so I'm resending.
Related to my earlier question on passing a function -- I was wondering if
there's a trivial way of generating a lazily-evaluated range of random numbers
according to a given distribution and parameters.
I wrote up the code below to generate a range of uniformly-distributed
numbers, but am not sure how to generalize it for arbitrary distribution and/or
parameters, and I'm also not sure that I'm overcomplicating what might be more
easily achieved with existing D functionality.
The larger goal here is that I want some way to pass an _arbitrary_ number
source (may be deterministic, may be stochastic) to a function. A range seemed
a good way to do that (after all, in the deterministic case I can just pass an
array, no?).
... but I couldn't work out how to generalize the stochastic case beyond what's
shown here.
///
import std.array, std.random, std.range, std.stdio;
struct UniformRange(T1, T2)
{
T1 _lower;
T2 _upper;
@property enum bool empty = false;
this(T1 a, T2 b)
{
_lower = a;
_upper = b;
}
@property auto ref front()
{
assert(!empty);
return uniform(_lower, _upper);
}
void popFront()
{
}
}
auto uniformRange(T1, T2)(T1 a, T2 b)
{
return UniformRange!(T1, T2)(a, b);
}
auto uniformRange(T1, T2)(size_t n, T1 a, T2 b)
{
return take(UniformRange!(T1, T2)(a, b), n);
}
void main()
{
auto ur = uniformRange!(double, double)(5, 10.0, 20.0);
double[] x = array( take(uniformRange(1.0, 2.0), 5) );
double[] y = array(x);
foreach(r; ur)
writeln(r);
writeln;
foreach(r; ur)
writeln(r);
writeln;
foreach(r; x)
writeln(r);
writeln;
foreach(r; y)
writeln(r);
writeln;
}
Re: avoid toLower in std.algorithm.sort compare alias
On Monday, 23 April 2012 at 11:27:40 UTC, Steven Schveighoffer
wrote:
I think using std.string.icmp is the best solution. I would
expect it to outperform even schwartz sort.
-Steve
icmp took longer... added about 1 sec vs 0.3 sec (for
schwartzSort ) to the program execution time.
bool myComp(string x, string y) { return std.string.icmp(x,y)0; }
std.algorithm.sort!(myComp)(dirs);
finished! time:1396 ms
Re: Range of random numbers
Joseph Rushton Wakeling:
struct UniformRange(T1, T2)
{
T1 _lower;
T2 _upper;
@property enum bool empty = false;
this(T1 a, T2 b)
{
_lower = a;
_upper = b;
}
@property auto ref front()
{
assert(!empty);
return uniform(_lower, _upper);
}
void popFront()
{
}
}
What about (untested):
auto uniformRange(T1 lower, T2 upper) {
return count().map!(_ = uniform(lower, upper))();
}
Where count() is just:
http://d.puremagic.com/issues/show_bug.cgi?id=7839
In the meantime cycle([0]) is acceptable but slower (untested):
return cycle([0]).map!(_ = uniform(lower, upper))();
Bye,
bearophile
Re: Keyword to avoid not null references
On Sunday, 22 April 2012 at 16:59:05 UTC, Jesse Phillips wrote:
As such checkNotNull shoud be more than throwing an exception.
I have tried this, but it should get some constraints. Also
wouldn't the new lambda syntax look nice with null here: null
= unsafe(a)?
Yeah, I like this idea, though a lot of what I do
is more like
if(x !is null) use(x);
h, the default could be to simply do nothing on
the other side. I think we can work with the lambda idea.
The other null related things on my mind are:
1) if we could make new return NotNull!T. I guess
we could offer an alternative:
NotNull!T create(T, Args...)(Args) {
return assumeNotNull(new T(Args));
}
Though new is so well entrenched that I don't think
it is going anywhere, and having a language construct
depend on a library structure is pretty meh.
So meh.
2) When doing chained calls, have it simply ignore the
rest when it hits null.
suppose:
if(a) if(auto b = a.something) b.more();
I guess some languages would call that
a?.something?.more();
but I wonder if we can do it in a library somehow.
ifNotNull(a).something.more();
Suppose it returns a wrapper of a that has an opDispatch
or something that includes the if check, and wraps
the rest of the return values.
I'm pretty sure we can do that!
Re: Keyword to avoid not null references
On Sunday, 22 April 2012 at 10:58:10 UTC, Namespace wrote:
If i got you right on git, you wouldn't allow something like
this:
NotNull!(Foo) f = new Foo(); and instead you want that
everybody writes
NotNull!(Foo) f = assumeNotNull(new Foo);
Is that correct?
No, I think that's too annoying, though I also think
it is more correct.
But my plan is to allow NotNull!Foo f = new Foo().
(This is a constructor, so removing opAssign doesn't change
this.)
there because of the explicit conversion constraint from Foo
into NotNull!(Foo) which i described in my post above.
That explicit conversion is one of the features of the
type - it means the compiler will remind you when you
missed something.
There's really little benefit to checking at a function
automatically. If you need that, you can always assert for
it in an in{} contract.
Or just use it and let the debugger take care of the rest.
I think a debug build on Windows even gives a stack trace
on null deref, but I'm not sure.
The big benefit with not null types is making sure you don't
store a null somewhere, since that's a lot harder to track
down.
Re: Keyword to avoid not null references
On Monday, 23 April 2012 at 11:04:24 UTC, Benjamin Thaut wrote:
Am 23.04.2012 09:14, schrieb Namespace:
I made several tests with NotNull yesterday and actually they
all passed.
In special cases i didn't get a compiler error but then a
runtime error
is better then nothing. :)
But there is still my problem with this:
void foo(NotNull!(Foo) n) {
}
void bar(Foo n) {
}
in my optinion it must exist a way that both
NotNull!(Foo) nf = new Foo();
foo(nf);
bar(nf);
and furhtermore
Foo f = new Foo();
foo(f);
bar(f);
compiles.
We need some hack, implicit cast or compiler cast that cast or
passes
Foo to NotNull!(Foo).
Any suggestions?
If you replace
alias _notNullData this;
with
@property T _notNullDataHelper()
{
assert(_notNullData !is null);
return _notNullData;
}
alias _notNullDataHelper this;
It will not be possible to assign to _notNullData
It will still be possbile to use from other modules
Yes, that's what i wrote a site before. Otherwise you couldn't
use it in other modules, that's right.
NotNull!T will implicitly convert to T (your first case)
However T will not implicitly convert to NotNull!T (as far as I
know such a implict conversion is not possible in D, i
suggested a @implicit modifier for a constructor to allow such
implicit type conversions, but it was rejected)
Kind Regards
Benjamin Thaut
That is bad. Without the possibility of such implicit constructs
NotNull isn't usefull at all.
I wouldn't write for all the objects which i would check
method_with_not_null_object(ConvertToNotNull(f_obj)); That
isn't helpfull, that makes more work as a sugesstion in the
method with assert(obj !is null); and that was what i wanted
avoid.
Why this reluctance against a keyword to check a normal Object
which is passed as parameter, e.g. @notNull Foo f?
I didn't understood it. Please explain that to me.
My previous language was C++ and so my first thoughts were that
only pointer types can be null but not references. And then i've
learned that D allows this behavoiur for both: refernces e.g.
objects that passes as parameter and even for pointer types.
That's a point which i will never understand.
Re: Keyword to avoid not null references
On Monday, 23 April 2012 at 14:31:05 UTC, Namespace wrote: Yes, that's what i wrote a site before. Otherwise you couldn't use it in other modules, that's right. yeah i'll fix that next time i work on it. I wouldn't write for all the objects which i would check method_with_not_null_object(ConvertToNotNull(f_obj)); The idea is to use NotNull!T to store your stuff, so there's no need to convert. Why this reluctance against a keyword to check a normal Object which is passed as parameter, e.g. @notNull Foo f? Because the hardware already does that, for the most part. That's what access violation means. The hard part is figuring out /why/ it is null, and the not null type helps that by catching it when you store it instead of when you use it.
Are there any mixin tutorials?
Or any other appropriate methods to achieve things like:
Loop unrolling
foreach(i;0..12)
//stuff involving the value
And making multiple functions with different values:
func1(int a) {//stuff}
func2(int a) {//stuff}
func3(int a) {//stuff}
where func 1 to 3 are all generated at compile time using the
same template and different values in their function bodies. I'm
trying to make sense of the docs for this but it's not very clear.
Re: Range of random numbers
On 23.04.2012 17:52, bearophile wrote:
Joseph Rushton Wakeling:
struct UniformRange(T1, T2)
{
T1 _lower;
T2 _upper;
@property enum bool empty = false;
this(T1 a, T2 b)
{
_lower = a;
_upper = b;
}
@property auto ref front()
{
assert(!empty);
return uniform(_lower, _upper);
}
void popFront()
{
}
}
What about (untested):
auto uniformRange(T1 lower, T2 upper) {
return count().map!(_ = uniform(lower, upper))();
}
Where count() is just:
http://d.puremagic.com/issues/show_bug.cgi?id=7839
What's wrong with:
http://dlang.org/phobos/std_algorithm.html#count
In the meantime cycle([0]) is acceptable but slower (untested):
return cycle([0]).map!(_ = uniform(lower, upper))();
Bye,
bearophile
--
Dmitry Olshansky
Re: Keyword to avoid not null references
On Monday, 23 April 2012 at 14:50:14 UTC, Adam D. Ruppe wrote: On Monday, 23 April 2012 at 14:31:05 UTC, Namespace wrote: Yes, that's what i wrote a site before. Otherwise you couldn't use it in other modules, that's right. yeah i'll fix that next time i work on it. I wouldn't write for all the objects which i would check method_with_not_null_object(ConvertToNotNull(f_obj)); The idea is to use NotNull!T to store your stuff, so there's no need to convert. Why this reluctance against a keyword to check a normal Object which is passed as parameter, e.g. @notNull Foo f? Because the hardware already does that, for the most part. That's what access violation means. The hard part is figuring out /why/ it is null, and the not null type helps that by catching it when you store it instead of when you use it. So if i wouldn't want such annoying debugging for a simple error (which gave me no further information), i must catch this stupid access violation by myself with assert/enforce or i use for all relevant objects NotNull? That is very inconvenient... And all that because NullPointer Exceptions or checks to assume not null (even with a explicit keyword!) would decrease the speed?
Confused about git state
Not really specific to D, but since there are git experts here: recently while trying to determine when a D bug was introduced, I checked out old revisions of druntime/phobos (detached HEAD state). This morning, I ran git pull on both repos with --ff-only, and now git insists that I'm ahead of upstream/master by 67 commits, but I don't understand where these commits are coming from, because git log shows everything is up-to-date and all the hashes match. So I'm confused about what git status means by ahead of upstream/master by 67 commits, because AFAIK I should be in sync? What's going on here? T -- Long, long ago, the ancient Chinese invented a device that lets them see through walls. It was called the window.
Re: avoid toLower in std.algorithm.sort compare alias
On Mon, 23 Apr 2012 09:49:50 -0400, Jay Norwood j...@prismnet.com wrote:
On Monday, 23 April 2012 at 11:27:40 UTC, Steven Schveighoffer
wrote:
I think using std.string.icmp is the best solution. I would expect it
to outperform even schwartz sort.
-Steve
icmp took longer... added about 1 sec vs 0.3 sec (for
schwartzSort ) to the program execution time.
bool myComp(string x, string y) { return std.string.icmp(x,y)0; }
std.algorithm.sort!(myComp)(dirs);
finished! time:1396 ms
Well, that's surprising :) Perhaps there's some room for improvement in
icmp or std.uni.toLower. There may be some constructs that are preventing
inlining (enforce is the worst offender).
While dealing with unicode in my std.stream rewrite, I've found that
hand-decoding dchars is way faster than using library calls.
-Steve
Re: using ntfs write_through option to create an efficient unzipped layout
I think, WRITE_THROUGH would cause problems on many small files.
Re: Range of random numbers
jerro: return repeat(0).map!(_ = uniform(lower, upper))(); repeat(0) returns the same sequence as cycle([0]) and is as fast as it gets, since popFront does nothing and empty is an enum. Good idea. --- Dmitry Olshansky: What's wrong with: http://dlang.org/phobos/std_algorithm.html#count It's for a different purpose. So the count() I was proposing will need a different name. Bye, bearophile
Re: Are there any mixin tutorials?
ixid: Or any other appropriate methods to achieve things like: Loop unrolling foreach(i;0..12) //stuff involving the value See Iota!() I've written here: http://d.puremagic.com/issues/show_bug.cgi?id=4085 Bye, bearophile
Re: Keyword to avoid not null references
I thought that something like this
// not_null_struct.d
NotNull!(T) assumeNotNull(T : Object)(T t) {
return NotNull!(T)(t);
}
@property
NotNull!(T) makeNotNull(T : Object)() {
T t = new T();
return assumeNotNull(t);
}
// not_null.d which import not_null_struct.d
NotNull!(Foo) _convert() {
//return NotNull!(Foo)(this); // prints: Stack overflow
return assumeNotNull(this);
}
alias _convert this;
would allow me to convert Foo to NotNull!(Foo) implicit. But it
doesn't work. I get this error:
not_null.d(37): Error: template instance
not_null_struct.assumeNotNull!(Foo) recursive expansion
Line 37 is the return in the _convert method.
Does anybody know why? I thought that would a smart idea...
Re: Pacikage level access broken?
On Monday, April 23, 2012 13:42:36 Jacob Carlborg wrote: On 2012-04-23 10:26, Era Scarecrow wrote: On Monday, 23 April 2012 at 06:19:12 UTC, Jacob Carlborg wrote: public is the default access level. So it is... That explains why the tests came out backwards on the results Wasn't it private by default in C++? I honestly don't know sometimes. I think so. If you use class it's private by default. If use struct it's public by default. That's basically the only difference between class and struct in C++, if I recall correctly. That's correct. In C++, struct and class are identical except that a class' members are private by default and a struct's members are public by default. - Jonathan M Davis
Re: Range of random numbers
On 23/04/12 18:56, bearophile wrote: jerro: return repeat(0).map!(_ = uniform(lower, upper))(); repeat(0) returns the same sequence as cycle([0]) and is as fast as it gets, since popFront does nothing and empty is an enum. Good idea. Yes, this works nicely. Thanks very much!
Re: Keyword to avoid not null references
On Monday, 23 April 2012 at 17:18:30 UTC, Namespace wrote:
I thought that something like this
// not_null_struct.d
NotNull!(T) assumeNotNull(T : Object)(T t) {
return NotNull!(T)(t);
}
@property
NotNull!(T) makeNotNull(T : Object)() {
T t = new T();
return assumeNotNull(t);
}
// not_null.d which import not_null_struct.d
NotNull!(Foo) _convert() {
//return NotNull!(Foo)(this); // prints: Stack overflow
return assumeNotNull(this);
}
alias _convert this;
would allow me to convert Foo to NotNull!(Foo) implicit. But it
doesn't work. I get this error:
not_null.d(37): Error: template instance
not_null_struct.assumeNotNull!(Foo) recursive expansion
Line 37 is the return in the _convert method.
Does anybody know why? I thought that would a smart idea...
I see, if i comment out alias _get this; in NotNull it works
fine and i can implicit convert Foo to NotNull!(Foo).
But why doesn't it work shareable? In that case it would be
nearly perfect for me.
Does anyone know how it could work? In my opinion both variants
have to work shareable. Don't they?
Re: Range of random numbers
On 23/04/12 19:46, Joseph Rushton Wakeling wrote: On 23/04/12 18:56, bearophile wrote: jerro: return repeat(0).map!(_ = uniform(lower, upper))(); Yes, this works nicely. Thanks very much! Is this a new addition? With GDC I get a compiler error: expression expected, not '' ... suggesting = isn't supported.
Re: Range of random numbers
On 04/23/2012 10:56 AM, Joseph Rushton Wakeling wrote: On 23/04/12 19:46, Joseph Rushton Wakeling wrote: On 23/04/12 18:56, bearophile wrote: jerro: return repeat(0).map!(_ = uniform(lower, upper))(); Yes, this works nicely. Thanks very much! Is this a new addition? With GDC I get a compiler error: expression expected, not '' ... suggesting = isn't supported. The lambda syntax was added in 2.058: http://dlang.org/changelog.html Ali
Re: Issue calling methods using std.concurrency
On Monday, 23 April 2012 at 02:34:19 UTC, Ali Çehreli wrote:
This works at least with 2.059 on 64-bit Linux:
import std.stdio;
import std.concurrency;
import core.thread;
class Foo
{
int i;
}
void workerFunc(Tid owner)
{
receive(
(shared(Foo) foo) {
writeln(Before: , foo.i);
foo.i = 42;
});
owner.send(42);
}
void main (string[] args)
{
shared foo = new shared(Foo);
auto worker = spawn(workerFunc, thisTid);
worker.send(foo);
receiveOnly!int();
writeln(After: , foo.i);
}
The output:
Before: 0
After: 42
Ali
Ali,
I actually did print out the value being passed successfully.
It's just that when I used the queue methods (enqueue and
dequeue), it get this error. The queue itself is shared, but
none of the methods are expecting a shared value nor do I believe
they should.
Casey
Re: Issue calling methods using std.concurrency
On 04/23/2012 11:44 AM, Casey wrote: I actually did print out the value being passed successfully. It's just that when I used the queue methods (enqueue and dequeue), it get this error. The queue itself is shared, but none of the methods are expecting a shared value nor do I believe they should. Casey Could you please show a short program having the same problem. I am not familiar with enqueue or dequeue. Ali
Re: Range of random numbers
It's for a different purpose. So the count() I was proposing will need a different name. Couldn't it just be iota with no parameters?
Re: Range of random numbers
jerro:
Couldn't it just be iota with no parameters?
The Count range has a helper count() function similar to this,
that's meant to have an argument that defaults to zero:
Count!T count(T)(T start=0) if (isIntegral!T) { return
Count!T(start); }
The argument allows it to start from another starting point, and
it allows you to specify the type of the numbers it yields, while
in iota() without arguments it's less easy to specify the type of
the numbers it yields.
Count(5) is easy to replace with iota(5, int.max), but
count(BigInt(0)) is less easy to replace with iota, because it
doesn't give you a way to denote a right-open BigInt interval.
And using iota(BigInt(0), BigInt(ulong.max)) is not that good.
Currently using BigInt in iota seems to not even being
supported...
Bye,
bearophile
Re: Range of random numbers
Count(5) is easy to replace with iota(5, int.max), This also means that for the OP problem, using repeat(0) is more correct than using count(), because count on default yields ints, that are limited to about 2 milliards. Bye, bearophile
Re: Issue calling methods using std.concurrency
On Monday, 23 April 2012 at 18:44:37 UTC, Casey wrote:
I actually did print out the value being passed successfully.
It's just that when I used the queue methods (enqueue and
dequeue), it get this error. The queue itself is shared, but
none of the methods are expecting a shared value nor do I
believe they should.
From what I can gather from error messages, you have a shared
reference to a non-shared class:
---
class Queue {
void enqueue(int v) { /*...*/ }
int dequeue() { /*...*/ }
}
// ...
auto queue = new shared(Queue);
// ...
---
If that is the case, then it's not that the methods are expecting
a shared value, it's that methods are not 'expecting' a shared
'this'. And indeed there is what seems to be a quirk in the
design of 'shared' in that it won't allow such calls. But it is
actually not a quirk, but means for the compiler to discard
incorrect code. If you want your methods to be called for shared
reference, the whole your class or at least those methods should
be shared as well. Just like with const: if you have a const
reference, you can only call const methods.
Whenever you encounter such issue, you should carefully think
about what's going on. If the class you use is not designed to be
shared, you shouldn't just start calling its methods from
different threads, since it is by definition not safe, no matter
what its documentation may state (remember, shared is there to
enforce such guarantees). If it is actually made thread-safe
(via, e.g. synchronized blocks), then the reference really
shouldn't be shared.
All that said, your best bets are either to rethink your design
(do you really need a shared queue if you are using message
passing anyway?), or to provide an implementation for shared
queue. If anything, consider that shared queue is very different
from non-shared one: are you satisfied with locking queue, or do
you need lockless one? Is your queue mostly read or written
thread-wise, or maybe it's only one provider and one consumer?
I'm sure experts in asynchronous programming can provide a dozen
more questions that should be answered and then coded into the
implementation of a queue that you want to share among threads.
I understand the desire to have one neat implementation that
'just works', no matter the conditions, but unfortunately, with
asynchronous programming that is not an option.
