Re: Sending an immutable object to a thread
It is a pitty that although Variant is the default message type in
concurrency, it still has issues:
https://issues.dlang.org/buglist.cgi?quicksearch=variant%20concurrencylist_id=202195
It looks like passing a pointer to an immutable(Message) works as well:
import std.stdio;
import std.concurrency;
class Message
{
int i;
this(int i) immutable
{
this.i = i;
}
}
int do_something_with(immutable(Message) msg)
{
writefln(msg.i is %s, msg.i);
return 0;
}
void threadFunc()
{
receive((Tid cli, immutable(Message) *msg) {
int retCode = do_something_with(*msg);
send(cli, retCode);
});
ownerTid.send(42);
}
void main()
{
auto msg = new immutable(Message)(100);
Tid tid = spawn(threadFunc);
send(tid, thisTid(), msg);// -- POINTER
receiveOnly!int();
}
Ali
static opCall not working?
I tested the code from: http://dlang.org/struct.html
Section: Dynamic Initialization of Structs
struct S
{
int a;
static S opCall(int v)
{
S s;
s.a = v;
return s;
}
static S opCall(S v)
{
S s;
s.a = v.a + 1;
return s;
}
}
S s = 3; // sets s.a to 3
S t = s; // sets t.a to 3, S.opCall(s) is not called
which does not compile (Error: cannot implicitly convert
expression (3) of type int to S).
What is wrong here? Docs or behavior? Tested it on asm.dlang.org
where it fails with all compiler versions.
Can't use toHexString
Hello, I get different results if I either use toHexString or crcHexString. I can't explain this behavior because crcHexString is just an alias of toHexString... Test code: http://pastebin.com/33Ye7yyJ
Re: Can't use toHexString
http://forum.dlang.org/post/ydaeytbyxdnwlbpwk...@forum.dlang.org
Re: Can't use toHexString
On Sunday, 19 July 2015 at 12:08:18 UTC, Adam D. Ruppe wrote: This line is illegal: return toHexString!(Order.decreasing)(crc.finish()); The std.digest.toHexString and variants return a *static array* which is static data and has a scope lifetime. It is horrendous a compiler bug that allows it to implicitly convert to string - it should not compile because it silently gives bad results, escaping a reference to temporary memory while claiming it is immutable. Confusingly though, this line is fine: return crcHexString(crc.finish()); It is an EXTREMELY subtle difference in the function signature (and totally bug prone, yet the documentation doesn't call it out...) ... Thank you very much for the explanation.
static-if cant compile
Pardon me for trivial question, Am new to D.
Why would a statement as below fail to compile. The plan is to do
some computation at compile-time hence considering the static-if
statement which fails to compile. The regular if-statement
compiles but is not useful since it is a runtime construct.
The error message I get is : Error: variable i cannot be read at
compile time
foreach( i; 0..size-1){
static if ( i == -1 ){
//Do something
}
}
Re: static-if cant compile
On Sunday, 19 July 2015 at 12:17:04 UTC, Clayton wrote:
Pardon me for trivial question, Am new to D.
In D, you can run regular runtime code at compile time in a lot
of cases. Just write an ordinary function that returns the data
you need, then use it in a static variable initialization.
// example function, notice regular if and variables inside
int calculate(int i) { if(i 0) return -i; else return i; }
static int value = calculate(5); // this is run at compile time
Ordinary functions will be interpreted if asked for their result
in a context that only can be run at compile time, like a static
variable initialization or inside a static if.
Re: static-if cant compile
On 20/07/2015 12:17 a.m., Clayton wrote:
Pardon me for trivial question, Am new to D.
Why would a statement as below fail to compile. The plan is to do some
computation at compile-time hence considering the static-if statement
which fails to compile. The regular if-statement compiles but is not
useful since it is a runtime construct.
The error message I get is : Error: variable i cannot be read at
compile time
foreach( i; 0..size-1){
static if ( i == -1 ){
//Do something
}
}
static if is for compile time known constants.
if is for runtime variables.
In this case it would be a runtime variable even if it is known at
compile time.
Known at compile time != run at compile time. They overlap yes, just not
the same thing.
Re: Can't use toHexString
On Sunday, 19 July 2015 at 12:00:23 UTC, Kagamin wrote: http://forum.dlang.org/post/ydaeytbyxdnwlbpwk...@forum.dlang.org Argh... must use the search function first... If I understand correctly in my case toHexString is returning a static char[len]. But why it gets silently converted to an immutable(char)[] ? And why crcHexString works fine ? It's an alias to the same function...
Re: Can't use toHexString
This line is illegal: return toHexString!(Order.decreasing)(crc.finish()); The std.digest.toHexString and variants return a *static array* which is static data and has a scope lifetime. It is horrendous a compiler bug that allows it to implicitly convert to string - it should not compile because it silently gives bad results, escaping a reference to temporary memory while claiming it is immutable. Confusingly though, this line is fine: return crcHexString(crc.finish()); It is an EXTREMELY subtle difference in the function signature (and totally bug prone, yet the documentation doesn't call it out...) http://dlang.org/phobos/std_digest_digest.html#.toHexString Notice the first overload there returns a static array, char[num*2], two of them return `auto`, so who knows what the hell they do and one actually returns `string`. Slightly different arguments will give you wildly different results. The safest thing to do is to `import std.conv;` and always `to!string` any of those *HexString return values if you want to return them like this. Or you could also keep them in a local variable and use them before the function returns, then the stack allocated static array is OK too.
Customization of User Defined Logger
When I try co compile next code:
class MyCustomLogger : Logger
{
this(string newName, LogLevel lv) @safe
{
super(newName, lv);
}
override void writeLogMsg(ref LogEntry payload)
{
// log message in my custom way
}
}
auto logger = new MyCustomLogger();
logger.log(Awesome log message);
I am getting error:
logger.d(10): Error: constructor
std.experimental.logger.core.Logger.this (LogLe
vel lv) is not callable using argument types (string, LogLevel)
logger.d(19): Error: undefined identifier lv
it's seems that I need to pass to constructor path with type
string and LogLevel lv. But what it is?
If I am write I think that this example should be extended.
[1] http://dlang.org/library/std/experimental/logger.html
Re: static opCall not working?
On 07/19/2015 03:26 AM, TC wrote:
I tested the code from: http://dlang.org/struct.html
Section: Dynamic Initialization of Structs
struct S
{
int a;
static S opCall(int v)
{
S s;
s.a = v;
return s;
}
static S opCall(S v)
{
S s;
s.a = v.a + 1;
return s;
}
}
S s = 3; // sets s.a to 3
S t = s; // sets t.a to 3, S.opCall(s) is not called
which does not compile (Error: cannot implicitly convert expression (3)
of type int to S).
What is wrong here? Docs or behavior? Tested it on asm.dlang.org where
it fails with all compiler versions.
The docs are not clear: s and t are not meant to be module-scope
variables, which should be initialized in a 'static this()' (or 'shared
static this()'). Put them inside a function like main() and it works fine.
Ali
Re: Can't use toHexString
Am Sun, 19 Jul 2015 12:08:16 + schrieb Adam D. Ruppe destructiona...@gmail.com: This line is illegal: return toHexString!(Order.decreasing)(crc.finish()); The std.digest.toHexString and variants return a *static array* which is static data and has a scope lifetime. It is horrendous a compiler bug that allows it to implicitly convert to string - it should not compile because it silently gives bad results, escaping a reference to temporary memory while claiming it is immutable. Confusingly though, this line is fine: return crcHexString(crc.finish()); It is an EXTREMELY subtle difference in the function signature (and totally bug prone, yet the documentation doesn't call it out...) Good catch. The version returning a string is meant to be used with the interface digest API which produces ubyte[]. As we don't know the length at compile time in that case we can't return a static array. But in hindsight it might have been better to use another function for this and not an overload, especially considering the static array=string conversion bug. Documentation pull request: https://github.com/D-Programming-Language/phobos/pull/3500 The good news is that the coversion bug has finally been fixed: https://issues.dlang.org/show_bug.cgi?id=9279
Dangular - D Rest server + Angular frontend
Hi I have created a personal project that aims to learn myself more about D/vibe.d and to create a simple and easy to grasp example on Mongo - Vibe - Angular. I have been thinking about the possibility of embedding D code in diet templates, as for ex to set api urls. Right now the urls are statically defined in the diet template. Other than that the example app is really not the best example with Angular because it uses root events to signal between controllers, but it works as a bootstrap example. I am thinking to create another view that uses ReactJS because its much much more better than Angular. Project is located here: https://github.com/jarlah/dangular Any comments are appreciated. Especially about the D part, because the Angular part is really just to make it easier for me to test, and it took like half an hour or hour to trash up (not using angular on daily basis)... I want to especially note a problem i have in the D code. Its about deserializing json data for creating a new person. I cant use the same struct for creating a new person as for returning a list of or a single person, because i want to return the ObjectID when I am querying mongo. I thhink the conversion from Document to PersonDoc is an operation that ensures that i am only returning explicitly what I really want to return. Any excess data in the collection is discarded. Nice for example to hide extra details for normal users, for ex. So, there is two structs, but I really only want to have one. Should I use classes for this? Inheritance?
Re: exclude current directory from search path in dmd ?
https://issues.dlang.org/show_bug.cgi?id=14811 On Wed, Jun 17, 2015 at 3:22 AM, Liran Zvibel via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Monday, 8 June 2015 at 04:08:55 UTC, Adam D. Ruppe wrote: The easiest way is to not use search paths, and instead pass all the modules you want compiled to the compiler directly. Then it will look for the module name declaration instead of the directory/filename layout. I think that this should be an explicit decision to also add -I. to the compilation or not. We (at Weka.IO) have to work extra hard to work around it, and since we have a large project with many packages it's impractical to just put everything on the command line. Also -- you WANT imported modules to be imported (and use the .di equivalent) instead of being compiled on the command line. A solution that won't break backwards compatibility and will still make sense is have this by default in dmd.conf, and when/if required dmd users can just modify their dmd.conf file. Liran
Re: Using executeShell in multiple thread causes access violation error
On Fri, 17 Jul 2015 22:53:55 +, Minas Mina wrote: bump sorry, i was wrong about GC non-calling. yet we still need more info: how long it works before crashing, how much threads it runs, how many git clone commands were ok before crach, what DMD version are you using, and *full* source code that reproduces crash, preferably without needing to clone 100500 repositories. ;-) seems that you hit a bug in runtime or compiler, so we need as much info as you can provide to localize the bug. signature.asc Description: PGP signature
Re: Customization of User Defined Logger
On 07/19/2015 06:02 AM, Suliman wrote:
When I try co compile next code:
class MyCustomLogger : Logger
{
this(string newName, LogLevel lv) @safe
{
super(newName, lv);
According to (and despite :p) its documentation Logger's constructor
takes just a LogLevel:
http://dlang.org/phobos/std_experimental_logger_core.html#.Logger.this
If I am write I think that this example should be extended.
The documentation needs some help. :)
Ali
Re: Dangular - D Rest server + Angular frontend
On Sunday, 19 July 2015 at 19:54:31 UTC, Jarl André Hübenthal wrote: Hi I have created a personal project that aims to learn myself more about D/vibe.d and to create a simple and easy to grasp example on Mongo - Vibe - Angular. [...] Nice. I was thinking about doing one up in React but haven't had much time for D the past few weeks. I quit Angular due to React and all the nonsense regarding 2.0.
Re: Replacement of std.stream
On Monday, 29 June 2015 at 12:00:14 UTC, Jonathan M Davis wrote: On Sunday, June 28, 2015 11:14:57 Baz via Digitalmars-d-learn wrote: On Sunday, 28 June 2015 at 05:04:48 UTC, DlangLearner wrote: I will convert a Java program into D. The original Java code is based on the class RandomeAccessFile which essentially defines a set of methods for read/write Int/Long/Float/String etc. The module std.stream seems to be a good fit for this job, but in its documentation, it is marked deprecated. So I'd like to know what is the replacement for this module. If I don't use this module, what is the other apporach I should use. Thanks for help. You can use std.stream. There is no candidate to replace it. Even if tomorrow someone comes with one, it has to be reviewed, accepted in std.experimental and after a while it would totally replace the old one. I think it's safe to say that std.stream will exist for at least 2 years in its current shape. No. It was decided at dconf that it was going to be deprecated and then removed within a relatively short period of time. In fact, it would have been deprecated with the next release, but there was a problem with the deprecation and the ddoc build, so the deprecation was temporarily reverted. But once that's sorted out, it's going to be deprecated, and it won't be around much longer at all. We decided that it was worse to leave it in saying that it was going to be replaced without having come up with anything for years than to leave it in. And given that std.stream rarely even comes up in discussions and that no one has proposed a replacement, Andrei thinks that it's a sign that there really isn't much demand for it anyway. For the most part, simply using std.stdio.File or std.mmfile.MmFile with ranges does what streams need to do just fine. Maybe someone will come up with a replacement for std.stream eventually, but there really doesn't seem to be much call for it. Regardless, until someone comes up with a replacement, we're simply not going have a stream-based I/O (though ranges are close - which is part of why no one has felt the need to replace std.stream strongly enough to actually do it). - Jonathan M Davis The documentation of std.mmfile.MmFile makes it an unacceptable replacement for std.stream. I can't even tell if it's features are missing, or just unintelligible. It rather looks as if you need to have enough RAM to hold the entire file in memory at once, but I'm not even sure of that. Perhaps this is just a documentation problem. Perhaps. But it's certainly a real problem. std.stdio.File is a much more reasonable substitute, but the documentation needs to be improved...probably lifted into a major heading, perhaps std.stdFile or some such. And examples. As it is it's buried where it gets overlooked...of course, that would tend to break any code that depended on using it is where it is now, so this should be done quickly, or this will end up being a continuing problem. (Even as it is, much of my code will stop compiling when this change is finalized, as I have used std.stream most of the time for years, not knowing of any alternative.)
What is the std.stream replacement?
I have DMD64 D Compiler v2.067.1 installed, and in the documentation of phobos what it says about std.stream is don't use it on new code. It doesn't, however, appear to offer any replacement. Certainly std.file, std.stdio, and std.path aren't replacements. So what *is* the appropriate replacement? More specificly, what should one use for binary i/o, particularly random access binary i/o? With fixed block size.
Re: Sending an immutable object to a thread
On Sunday, 19 July 2015 at 17:04:07 UTC, Frank Pagliughi wrote: [...] Oh, yes, pointer. Ha! I didn't even think of that. Thanks. I'm not familiar with how garbage collection works in D. If the initial reference goes out of scope, and you just have a pointer - in another thread, no less - then are you still guaranteed that the object will not disappear while the pointer exists? [...] a pointer to a pointer(or in this case, a reference) does not keep it alive.
Re: Sending an immutable object to a thread
It looks like passing a pointer to an immutable(Message) works
as well:
Oh, yes, pointer. Ha! I didn't even think of that. Thanks.
I'm not familiar with how garbage collection works in D. If the
initial reference goes out of scope, and you just have a pointer
- in another thread, no less - then are you still guaranteed that
the object will not disappear while the pointer exists?
Like if I did something akin to:
// ...like before...
void send_msg(Tid tid, int n)
{
auto msg = new immutable(Message)(n);
send(tid, thisTid(), msg);
}
void main()
{
Tid tid = spawn(threadFunc);
send_msg(tid, 100);
receiveOnly!int();
}
Do I know that the message object won't be garbage collected
before the thread finishes with it? (I realize this is a very
artificial example, but something like this could happen in a
bigger library).
Frank
Re: Dangular - D Rest server + Angular frontend
On Sunday, 19 July 2015 at 19:54:31 UTC, Jarl André Hübenthal
wrote:
Hi
I have created a personal project that aims to learn myself
more about D/vibe.d and to create a simple and easy to grasp
example on Mongo - Vibe - Angular.
Nice ! I'm also working on a project like this, using some paid
angularjs admin template from themeforest, although I'm powering
it with Vibe.d / Redis and PostgreSQL 9.4 with its new json type.
controllers, but it works as a bootstrap example. I am thinking
to create another view that uses ReactJS because its much much
more better than Angular.
ReactJS has been very promising and I hear a lot of hype around
it. However I believe Angular lived through its hype and is now
more mature in plenty of areas, for example its Ionic framework
for cross-mobile apps is reaching its gold age with seemingly
fluid performance on every device! With vibe.d being a
cross-platform framework, you'd be even able to build a Web
Application that communicates with a client-side OS API,
effectively closing the gap between web dev and software dev.
So, there is two structs, but I really only want to have one.
Should I use classes for this? Inheritance?
Vibe.d is famous for its compile-time evaluation, understanding
structures like with reflection but producing the most optimized
machine code possible. You won't be dealing with interfaces in
this case, you should look at the UDA api instead:
http://vibed.org/api/vibe.data.serialization/. For example, if
your field might not always be in the JSON, you can mark it
@optional.
struct PersonDoc {
@optional BsonObjectID _id;
ulong id;
string firstName;
string lastName;
}
You can also compile-time override the default
serialization/deserialization instructions for a struct by
defining the function signatures specified here:
http://vibed.org/api/vibe.data.json/serializeToJson
or the example here:
https://github.com/rejectedsoftware/vibe.d/blob/master/examples/serialization/source/app.d
This being said, your questions are most likely to be answered if
you ask at http://forum.rejectedsoftware.com
Re: What is the std.stream replacement?
On Sunday, July 19, 2015 09:56:11 Charles Hixson via Digitalmars-d-learn wrote: I have DMD64 D Compiler v2.067.1 installed, and in the documentation of phobos what it says about std.stream is don't use it on new code. It doesn't, however, appear to offer any replacement. Certainly std.file, std.stdio, and std.path aren't replacements. So what *is* the appropriate replacement? More specificly, what should one use for binary i/o, particularly random access binary i/o? With fixed block size. Either use std.stdio.File - e.g. byChunk will allow you to read files as a range of chunks. Or you can use std.mmfile.MmFile to use memory-mapped I/O and operate on the file as a dynamic array (which is about as efficient as it gets). If you want random access, MmFile would likely be the best option - Jonathan M Davis
Re: exclude current directory from search path in dmd ?
On Monday, 20 July 2015 at 03:33:08 UTC, Timothee Cour wrote: I've attached a reduced use case showing that the solutions proposed in this thread do not work, and wrote a local modification to dmd to allow a flag -exclude_cwd_from_imports that does work. Would that be acceptable to have this in official dmd? The best way to find out is to make a Pull Request. If it's hard to workaround than it's a good candidate for enhancement.
Re: exclude current directory from search path in dmd ?
I've attached a reduced use case showing that the solutions proposed in this thread do not work, and wrote a local modification to dmd to allow a flag -exclude_cwd_from_imports that does work. Would that be acceptable to have this in official dmd? On Sun, Jul 19, 2015 at 8:07 PM, Timothee Cour thelastmamm...@gmail.com wrote: https://issues.dlang.org/show_bug.cgi?id=14811 On Wed, Jun 17, 2015 at 3:22 AM, Liran Zvibel via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Monday, 8 June 2015 at 04:08:55 UTC, Adam D. Ruppe wrote: The easiest way is to not use search paths, and instead pass all the modules you want compiled to the compiler directly. Then it will look for the module name declaration instead of the directory/filename layout. I think that this should be an explicit decision to also add -I. to the compilation or not. We (at Weka.IO) have to work extra hard to work around it, and since we have a large project with many packages it's impractical to just put everything on the command line. Also -- you WANT imported modules to be imported (and use the .di equivalent) instead of being compiled on the command line. A solution that won't break backwards compatibility and will still make sense is have this by default in dmd.conf, and when/if required dmd users can just modify their dmd.conf file. Liran
