Re: stdout redirect
On 13/04/2015 1:12 a.m., FreeSlave wrote: On Sunday, 12 April 2015 at 04:39:06 UTC, Philip Stuckey wrote: why not: import std.stdio; stdout = File(args[4], w+); stderr = File(args[4], w+); It just replaces the object, not redirects output. E.g. if you use printf somewhere it will use stdout, not file. You will need to use writefln instead of printf. As printf uses the processes stdout. Changing this would be tricky and OS based.
Re: mixin template question
On Sunday, 12 April 2015 at 04:04:43 UTC, lobo wrote:
On Sunday, 12 April 2015 at 03:51:03 UTC, Paul D Anderson wrote:
I don't understand why the following code compiles and runs
without an error:
import std.stdio;
mixin template ABC(){
int abc() { return 3; }
}
mixin ABC;
int abc() { return 4; }
void main()
{
writefln(abc() = %s, abc());
}
Doesn't the mixin ABC create a function with the same
signature as the actual function abc()?
It compiles with both included and writes abc() = 4. If I
comment out the actual function then it writes abc() = 3.
The actual function takes precedence, but why don't they
conflict?
Paul
As the manual says (snippet below) the surrounding scope
overrides mixin
http://dlang.org/template-mixin.html
---
Mixin Scope
The declarations in a mixin are ‘imported’ into the surrounding
scope. If the name of a declaration in a mixin is the same as a
declaration in the surrounding scope, the surrounding
declaration overrides the mixin one:
int x = 3;
mixin template Foo()
{
int x = 5;
int y = 5;
}
mixin Foo;
int y = 3;
void test()
{
writefln(x = %d, x); // prints 3
writefln(y = %d, y); // prints 3
}
---
bye,
lobo
Thanks.
Trouble in converting C code to D
So I got GDAL binding work. And now I need to understand how to
translate C code to D.
Here is simple tutorial: http://www.gdal.org/gdal_tutorial.html
If I right understand it's easier to take C, than C++ code
example.
Now I am trying to get very simple example work. My code is:
string fileTiff =
`D:\code\RSM2DOC\data-example\03022014_101_022731_09_10_Rostov.tif`;
if (!fileTiff.exists)
writeln(Tiff file do not exists);
GDALDatasetH hDataset = GDALOpen( toStringz(fileTiff),
GDALAccess.GA_ReadOnly );
GDALDriverH hDriver;
hDriver = GDALGetDatasetDriver(hDataset);
double adfGeoTransform[6];
if( GDALGetGeoTransform( hDataset, adfGeoTransform ) == CE_None
)
{
writeln(adfGeoTransform[1]);
}
function (void*, double*) is not callable using argument types
(void*, double[6])
I can't understand why this error is rise up. It's look like
1-to-1 with C code.
Also I can't understand at what moment adfGeoTransform get in it
value.
writefln patterns with mismatching compile-time known number of arguments
I was chatting with a friend and showed him how printf(%s) printed random memory in C, whereas writefln(%s) in D threw an Exception upon execution. It's probably not a completely fair comparison but that's a different topic. I admit to being confused as to why it passed compilation at all in the first place. Surely the %s literal is just as known at compilation as an enum would be. Is there any button in D that could be leveraged to statically assert that the number of arguments precisely match the number of format specifiers, iff the pattern is static/enum/literal? I asked in #d and had it pointed out that this could be solved via an overload of writefln that took the pattern as a template instantiation argument, to which I conceed. The main con would naturally be that you end up with template bloat. You could also have tooling (dfix/dscanner) handle it for you. But the compiler has all the pieces of information needed to see it's wrong, doesn't it? How much of this kind of thing is evaluated during the CTFE passes?
Re: writefln patterns with mismatching compile-time known number of arguments
On Sun, 12 Apr 2015 14:18:21 +, JR wrote: But the compiler has all the pieces of information needed to see it's wrong, doesn't it? no, it doesn't. compiler doesn't know about `std.format.format` and it's special abilities. while it is possible to add such checks to the compiler, it will introduce interdependency between compiler and phobos, which is not desirable. writing CTFE `writef` version is possible without template bloat in binary, but it will take more memory in compile time and slows compilation. there were talks about having `writef!fmt(args)` in phobos, but nobody took that task yet. signature.asc Description: PGP signature
Re: Trouble in converting C code to D
Oh in gdal.d there is comment: /* * The enum CPLErr is defined in the header file cpl_error.h. I have not * for the time being included a binding to that header, but have just * imported this single symbol from it. * * Similarly, GDALProgressFunc is defined in port/cpl_progress.h */ Am I right understand that binding is not file with .d extension? So what is this file with extern(C) and so on. It's named interface file?
Re: Trouble in converting C code to D
Do have you extern(C) everywhere ?
Re: Trouble in converting C code to D
On 2015-04-12 11:19, Suliman wrote:
So I got GDAL binding work. And now I need to understand how to
translate C code to D.
Here is simple tutorial: http://www.gdal.org/gdal_tutorial.html If I
right understand it's easier to take C, than C++ code example.
Now I am trying to get very simple example work. My code is:
string fileTiff =
`D:\code\RSM2DOC\data-example\03022014_101_022731_09_10_Rostov.tif`;
if (!fileTiff.exists)
writeln(Tiff file do not exists);
GDALDatasetH hDataset = GDALOpen( toStringz(fileTiff),
GDALAccess.GA_ReadOnly );
GDALDriverH hDriver;
hDriver = GDALGetDatasetDriver(hDataset);
double adfGeoTransform[6];
if( GDALGetGeoTransform( hDataset, adfGeoTransform ) == CE_None )
{
writeln(adfGeoTransform[1]);
}
function (void*, double*) is not callable using argument types (void*,
double[6])
I can't understand why this error is rise up. It's look like 1-to-1 with
C code.
Also I can't understand at what moment adfGeoTransform get in it value.
GDALGetGeoTransform is declared to take a pointer to a double (array of
doubles). While adfGeoTransform is declared as a static array [1] of
doubles. Static arrays are stack allocated and passed by value, the
function expects an array which is passed by reference. Try adding
.ptr to adfGeoTransform in the call to GDALGetGeoTransform.
[1] http://dlang.org/arrays.html#static-arrays
--
/Jacob Carlborg
Re: stdout redirect
On Sunday, 12 April 2015 at 04:39:06 UTC, Philip Stuckey wrote: why not: import std.stdio; stdout = File(args[4], w+); stderr = File(args[4], w+); It just replaces the object, not redirects output. E.g. if you use printf somewhere it will use stdout, not file.
Re: why cant function parameters be grouped by type ?
On Sun, 12 Apr 2015 11:49:18 +, Baz wrote: Is there anything in the grammar that prevents this syntax ? yes: nameless args. i would like to see 'em burned with napalm, but it seems to be too late to do that... signature.asc Description: PGP signature
Re: Trouble in converting C code to D
Jacob, thanks!
double [6] adfGeoTransform;
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == 0 )
{
writeln(adfGeoTransform[1]);
}
But could you explain why if binding have next string:
enum CPLErr
{
CE_None = 0,
CE_Debug = 1,
CE_Warning = 2,
CE_Failure = 3,
CE_Fatal = 4
}
I can't use:
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) ==
CE_None )
Error: undefined identifier CE_None
Re: vibed - best approach to manage central state (cached records)
On Saturday, 11 April 2015 at 19:24:22 UTC, Laeeth Isharc wrote: Hi. Two questions: 1. On startup I load various indexes from file storage into memory in the shared static this segment, and I would like to access these from threads serving web requests. The data can be considered immutable once loaded. What is the best way to make this data accessible? Obviously static doesn't work as the threads have their own storage (I think this is what is happening). __gshared works, but is there a better approach? You can declare the cache as `immutable` (which is shared across threads) and assign to it using `assumeUnique()`. You just need to make sure the initialization really happens only once, i.e. do it in `main()` or in `shared static this()` as opposed to `static this()`.
Re: Trouble in converting C code to D
On Sunday, 12 April 2015 at 09:36:54 UTC, Stefan Koch wrote: Do have you extern(C) everywhere ? Yes, at binding file. Here is a lot of string like: extern(C) CPLErr GDALGetGeoTransform( GDALDatasetH, double* );
why cant function parameters be grouped by type ?
Hi, while variable declarations work in list: uint a,b,c; function parameters declarations don't: void foo(uint a,b,c); Because of this, function declarations are sometimes super-wide. (despite of the fact that: http://www.brainyquote.com/quotes/quotes/a/alanperlis177279.html) In the previous example, we could imagine that once a type defined, it'd valid until a new one appears (until a redefinition / an override). Is there anything in the grammar that prevents this syntax ? Thx.
Re: why cant function parameters be grouped by type ?
On Sunday, 12 April 2015 at 11:49:19 UTC, Baz wrote: Hi, while variable declarations work in list: uint a,b,c; function parameters declarations don't: void foo(uint a,b,c); Because of this, function declarations are sometimes super-wide. (despite of the fact that: http://www.brainyquote.com/quotes/quotes/a/alanperlis177279.html) In the previous example, we could imagine that once a type defined, it'd valid until a new one appears (until a redefinition / an override). Is there anything in the grammar that prevents this syntax ? Thx. void foo(int a, b); Is `b` a second int argument, or is there a user defined type named `b` and the second argument is nameless of type `b`?
Re: Trouble in converting C code to D
On 2015-04-12 11:57, Suliman wrote: Oh in gdal.d there is comment: /* * The enum CPLErr is defined in the header file cpl_error.h. I have not * for the time being included a binding to that header, but have just * imported this single symbol from it. * * Similarly, GDALProgressFunc is defined in port/cpl_progress.h */ Am I right understand that binding is not file with .d extension? So what is this file with extern(C) and so on. It's named interface file? Based on that comment it sounds like the bindings are not complete. In this case only CPLErr has been included from the cpl_progress.h file. -- /Jacob Carlborg
Re: Trouble in converting C code to D
On 2015-04-12 11:53, Suliman wrote:
But could you explain why if binding have next string:
enum CPLErr
{
CE_None = 0,
CE_Debug = 1,
CE_Warning = 2,
CE_Failure = 3,
CE_Fatal = 4
}
I can't use:
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == CE_None )
In D you need to include the name of the enum type as well:
CPLErr.CE_None. If you want to avoid that you can use aliases:
alias CE_None = CPLErr.CE_None
Or the with-statement:
with (CPLErr)
{
// inside this block all the members of CPLErr can be accessed
without prefixing them with CPLErr
if( GDALGetGeoTransform( hDataset, adfGeoTransform.ptr ) == CE_None )
{
}
}
--
/Jacob Carlborg
Re: writefln patterns with mismatching compile-time known number of arguments
On Sunday, 12 April 2015 at 14:18:23 UTC, JR wrote: I was chatting with a friend and showed him how printf(%s) printed random memory in C I'm pretty sure modern C compilers will warn about something as obviously wrong as this.
Re: IMAP library
On Saturday, 11 April 2015 at 22:45:39 UTC, Laeeth Isharc wrote: Yes - nice to know it can do that also. For me I need to have a way of managing large amounts of email (I have about 2mm messages) including for natural language processing etc. Dovecot/sieve + pipe facility is ok, but not perfect for everything. I guess it should work fine for regular ARM etc - perhaps not an Arduino! I won't say it's impossible, but it would be cumbersome processing email on an AVR. But there are Arduino using ARM Cortex-M microcontrollers too. I can mention a couple of microcontrollers that have ethernet support (eg. they need a PHY of your choice and for instance a HanRun ethernet connector) - Examples are STM32F4xx from ST-Microelectronics and LPC1758/LPC1768/LPC1769/LPC177x/LPC178x/LPC43xx from NXP. There are others from other vendors as well, but those above are quite popular and very easy to find as stand-alone chips or small evaluation boards. I find it particularly interesting to be able to send an email to a device, which can then process and do some simple things (eg. turn stuff on/off, send back the room temparature, etc.) - also a mail-robot would be quite interesting as a stand-alone thing. Have a few other things on the boil, and also constrained in how much time I can spend for various reasons. I have the exact same problems. ;) So don't plan or expect on it being finished soon, although I hope it might be. It'll be ready when it's ready. When building in small steps, the job often gets easier. May you be successful with ease!
Re: vibed - best approach to manage central state (cached records)
On Sunday, 12 April 2015 at 10:04:53 UTC, Marc Schütz wrote: On Saturday, 11 April 2015 at 19:24:22 UTC, Laeeth Isharc wrote: Hi. Two questions: 1. On startup I load various indexes from file storage into memory in the shared static this segment, and I would like to access these from threads serving web requests. The data can be considered immutable once loaded. What is the best way to make this data accessible? Obviously static doesn't work as the threads have their own storage (I think this is what is happening). __gshared works, but is there a better approach? You can declare the cache as `immutable` (which is shared across threads) and assign to it using `assumeUnique()`. You just need to make sure the initialization really happens only once, i.e. do it in `main()` or in `shared static this()` as opposed to `static this()`. Thanks. Laeeth
Re: IMAP library
On Sunday, 12 April 2015 at 17:27:32 UTC, Jens Bauer wrote: I won't say it's impossible, but it would be cumbersome processing email on an AVR. I do miss the days of having to work within very real hardware constraints to achieve something only just about achievable. But part of the joy goes out of it when you know that the constraint is artifical. But there are Arduino using ARM Cortex-M microcontrollers too. Yes - I meant this in a loose, everyday, form of speaking. I can mention a couple of microcontrollers that have ethernet support (eg. they need a PHY of your choice and for instance a HanRun ethernet connector) - Examples are STM32F4xx from ST-Microelectronics and LPC1758/LPC1768/LPC1769/LPC177x/LPC178x/LPC43xx from NXP. There are others from other vendors as well, but those above are quite popular and very easy to find as stand-alone chips or small evaluation boards. Tku - I have one of these modules lying around, but have not had time to hook it up yet and don't remember which one. We may not have been delivered the world of the Jetsons, but I am still occasionally astonished that what was only imagination in childhood is now almost too ordinary to be worth remarking on today. One aspect of embedded stuff I haven't seen people comment on is that even if D is not yet there for running for regular use on the controller, you still need to talk to it from the host or control unit, and I guess D can be quite useful there. Also for processing logs, and so on. I find it particularly interesting to be able to send an email to a device, which can then process and do some simple things (eg. turn stuff on/off, send back the room temparature, etc.) - also a mail-robot would be quite interesting as a stand-alone thing. Yes - makes sense. (Reminded of an article on the supposed spam epidemic from networked 'toasters'). Email might not be the best protocol for this, but it is easy. It'll be ready when it's ready. When building in small steps, the job often gets easier. May you be successful with ease! Thank you! And v interesting what you are doing on the microcontroller side, too - and I hope that goes well. Laeeth
Re: writefln patterns with mismatching compile-time known number of arguments
On Sun, Apr 12, 2015 at 02:33:03PM +, ketmar via Digitalmars-d-learn wrote: On Sun, 12 Apr 2015 14:18:21 +, JR wrote: But the compiler has all the pieces of information needed to see it's wrong, doesn't it? no, it doesn't. compiler doesn't know about `std.format.format` and it's special abilities. while it is possible to add such checks to the compiler, it will introduce interdependency between compiler and phobos, which is not desirable. writing CTFE `writef` version is possible without template bloat in binary, but it will take more memory in compile time and slows compilation. there were talks about having `writef!fmt(args)` in phobos, but nobody took that task yet. It's not hard to write a CTFE version of writef/writeln/etc., that takes the format argument at compile-time, since std.format itself is already CTFE-able. All it takes is for somebody to step up to the plate and implement it. T -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard
