Re: Matching with std.concurrency receive
Hrm... that's a bit problematic. If I do use the exact match, it seems to hang / lock up (probably the lack of support for classes?). However, that's pretty much never the case of what I want to do, since what I'm trying to do involves passing / accepting an interface and its implementations. I guess I can manage this with a static table of operation IDs pointing to function delegates. Sadness. Haha Alright, thankee!
Re: Matching with std.concurrency receive
On Saturday, December 10, 2011 17:30:50 Adam wrote: > Hrm... that's a bit problematic. If I do use the exact match, it seems > to hang / lock up (probably the lack of support for classes?). > However, that's pretty much never the case of what I want to do, since > what I'm trying to do involves passing / accepting an interface and > its implementations. > > I guess I can manage this with a static table of operation IDs > pointing to function delegates. Sadness. Haha It probably _should_ accept interfaces for classes and the like, but I don't think that it works properly for classes at the moment (due to issues with Variant), and in my experience, I've had use the _exact_ type, as annoying as that may be. For instance, if IIRC, I tried to pass a string which happened to be immutable, and when I tried to receive string on the other end, it wouldn't work until I changed it to receive an immutable string. If you have a type A which you think definitely should be receivable as type B on the other side, and it doesn't work, please submit a bug report: d.puremagic.com/issues . It's possible that you're misunderstanding something, but it's also definitely a possibility that receive just doesn't work right in some cases (e.g. far too strict). A bug report increases the chances of it getting fixed. - Jonathan M Davis
Re: Matching with std.concurrency receive
On Sat, Dec 10, 2011 at 1:38 PM, Jonathan M Davis wrote: > On Saturday, December 10, 2011 17:30:50 Adam wrote: >> Hrm... that's a bit problematic. If I do use the exact match, it seems >> to hang / lock up (probably the lack of support for classes?). >> However, that's pretty much never the case of what I want to do, since >> what I'm trying to do involves passing / accepting an interface and >> its implementations. >> >> I guess I can manage this with a static table of operation IDs >> pointing to function delegates. Sadness. Haha > > It probably _should_ accept interfaces for classes and the like, but I don't > think that it works properly for classes at the moment (due to issues with > Variant), and in my experience, I've had use the _exact_ type, as annoying as > that may be. For instance, if IIRC, I tried to pass a string which happened to > be immutable, and when I tried to receive string on the other end, it wouldn't > work until I changed it to receive an immutable string. > > If you have a type A which you think definitely should be receivable as type B > on the other side, and it doesn't work, please submit a bug report: > d.puremagic.com/issues . It's possible that you're misunderstanding something, > but it's also definitely a possibility that receive just doesn't work right in > some cases (e.g. far too strict). A bug report increases the chances of it > getting fixed. > > - Jonathan M Davis With classes, Variant currently can't handle immutability. Passing shared objects is fine, and casting works as a workaround. The bug report also has a workaround that's fairly easy to add to std.variant, but it sounds like the current std.variant isn't going to get fixed (just the replacement that's in development). The thing that seems to be confusing about message passing is that we have no dynamic pattern matching (and that's not because of receive, it's because of Variant), so all type matching comes from templates and checking types for equality. If you pass in a reference of type Object, it doesn't matter what type the actual object is, you can only match it as Object when receiving it. This may or may not be unavoidable - if we can implement dynamic type matching, classes will need to special cased in the Variant code (because you can't dynamically typecheck a struct or primitive). This is probably worth asking Rob Jacques about, since he's developing the std.variant replacement.
strip and dmd 2.056
dear,
it seem now we can not use this:
";;blah".stripLeft(";");
Error: template std.string.stripl(String) cannot deduce template
function from argument types !()(string,string)
they are another way ?
Re: strip and dmd 2.056
bioinfornatics:
> it seem now we can not use this:
> ";;blah".stripLeft(";");
> Error: template std.string.stripl(String) cannot deduce template
> function from argument types !()(string,string)
>
>
> they are another way ?
In Python str.lstrip accepts an optional argument:
>>> ";;blah".lstrip(";")
'blah'
But I think with the current Phobos you need to use something like this:
import std.stdio, std.string;
void main() {
string s = ";;blah";
munch(s, ";");
writeln(s);
}
Bye,
bearophile
Re: Matching with std.concurrency receive
Hm.. so I tried another approach, which would be to send the type
name as a string, then use Object.factory to instantiate that (ugly,
but whatever). Had a few problems with that, then just reduced it to
a non-thread case:
import std.stdio;
immutable interface BasicType {
}
immutable class SubType : BasicType {
}
immutable class A(T : BasicType) {
}
void main() {
immutable A!(SubType) instance = new immutable(A!(SubType))();
writeln("Type name is " ~ instance.classinfo.name);
Object object = Object.factory(instance.classinfo.name);
if (object) {
writeln("Created");
} else {
writeln("Failed");
}
}
This returns "Failed." So, I thought I'd just provide Object.factory
"hello.A" (since hello is the module name and is what is printed
from the writeln). Still no good.
Any thoughts?
Re: strip and dmd 2.056
On Saturday, December 10, 2011 16:18:22 bearophile wrote:
> bioinfornatics:
> > it seem now we can not use this:
> > ";;blah".stripLeft(";");
> > Error: template std.string.stripl(String) cannot deduce template
> >
> > function from argument types !()(string,string)
> >
> >
> > they are another way ?
>
> In Python str.lstrip accepts an optional argument:
> >>> ";;blah".lstrip(";")
>
> 'blah'
>
>
> But I think with the current Phobos you need to use something like this:
>
> import std.stdio, std.string;
> void main() {
> string s = ";;blah";
> munch(s, ";");
> writeln(s);
> }
None of the strip or split functions in Phobos deal with anything other than
whitespace. splitter is more general, but there is no stripper (which would
arguably be a horrible name for a function anyway). However, that's
essentially what find does, albeit with the predicate effectively being
reversed. e.g.
find!"a != ';'"(";blah");
- Jonathan M Davis
