Re: dgui - Button continually repainting

2014-09-10 Thread Mike James via Digitalmars-d-learn

//
Please file this issue also on the dgui

bibucket home page.

Kind regards
Andre


//

Done.

Regards, -=mike=-


DUB: link to local library

2014-09-10 Thread rcor via Digitalmars-d-learn
I'd like to link to DAllegro5, which doesn't have an official dub 
package yet.

My project structure looks like this:
--
ext/
  dallegro5/
allegro5/ d bindings that need to be imported
libdallegro5.a -- library I need to link to
src/
   app.d  single source file which uses DAllegro5 
bindings

dub.json
--
app.d is just the DAllegro5 example:
https://github.com/SiegeLord/DAllegro5/blob/master/example.d

I can build a working executable with the following command:
dmd -Iext/dallegro5 -L-Lext/dallegro5 src/app.d

dub.json contains what I think should do the same as above:
{
  name: test,
  importPaths: [ext/dallegro5],
  lflags: [-Lext/dallegro5]
}

Obviously this is missing some fields that I would want in a full 
project like authors and license but I'm trying to keep it simple 
until I figure out dub.


dub.json seems like it should add the import and library search 
paths just like the dmd command I used, but instead fails with 
linker errors:


.dub/build/application-debug-linux.posix-x86_64-dmd-323FC98A6F20DD1891F81CB0FEE1D200/test.o:(.rodata+0x1ba8): 
undefined reference to `_D8allegro57allegro12__ModuleInfoZ'


... a few more of these, followed by:

.../test/src/app.d:39: undefined reference to `al_init'
... and many more undefined references

Does anyone have an idea of how to make this work? I can push 
this test project structure up on a git repo if it would help to 
see the whole thing.


Re: UFCS doesn't work in some cases

2014-09-10 Thread Danyal Zia via Digitalmars-d-learn
On Tuesday, 9 September 2014 at 18:46:31 UTC, ketmar via 
Digitalmars-d-learn wrote:
UFCS is not working for nested functions. this is not a bug, it 
was

designed this way. the same for 'with', i believe.
Apparently it is a bug that UFCS doesn't work with 'with' 
statement.

https://issues.dlang.org/show_bug.cgi?id=10349

there is rationale. see http://dlang.org/function.html, UFCS 
section.

Must have missed it before, thanks.


Re: UFCS doesn't work in some cases

2014-09-10 Thread ketmar via Digitalmars-d-learn
On Wed, 10 Sep 2014 13:58:18 +
Danyal Zia via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:

 Apparently it is a bug that UFCS doesn't work with 'with' 
 statement.
my fault, i thought that it shouldn't. i'm still not Guru. too bad,
will work. ;-)


signature.asc
Description: PGP signature


Re: DUB: link to local library

2014-09-10 Thread Edwin van Leeuwen via Digitalmars-d-learn

On Wednesday, 10 September 2014 at 13:40:16 UTC, rcor wrote:

dub.json contains what I think should do the same as above:
{
  name: test,
  importPaths: [ext/dallegro5],
  lflags: [-Lext/dallegro5]
}


Does adding:

libs: [dallegro5]

make a difference?

Cheers, Edwin


Re: DUB: link to local library

2014-09-10 Thread andre via Digitalmars-d-learn
Dub command line supports something like Dub add-local. Then you 
can use the package directly.


Kind regards
Andre

On Wednesday, 10 September 2014 at 15:40:11 UTC, Edwin van 
Leeuwen wrote:

On Wednesday, 10 September 2014 at 13:40:16 UTC, rcor wrote:

dub.json contains what I think should do the same as above:
{
 name: test,
 importPaths: [ext/dallegro5],
 lflags: [-Lext/dallegro5]
}


Does adding:

libs: [dallegro5]

make a difference?

Cheers, Edwin




Re: DUB: link to local library

2014-09-10 Thread rcor via Digitalmars-d-learn
On Wednesday, 10 September 2014 at 15:40:11 UTC, Edwin van 
Leeuwen wrote:

On Wednesday, 10 September 2014 at 13:40:16 UTC, rcor wrote:

dub.json contains what I think should do the same as above:
{
 name: test,
 importPaths: [ext/dallegro5],
 lflags: [-Lext/dallegro5]
}


Does adding:

libs: [dallegro5]

make a difference?

Cheers, Edwin


I thought libs was for linking to system libraries, which 
dallegro5 isn't (its just built locally and not installed 
system-wide).
However, libs: [dallegro5] does seem to change the errors a 
bit:

Without:
http://pastebin.com/Xpq94EkR
With:
http://pastebin.com/7fet3xU1

In particular, it makes the undefined reference to al_init 
disappear, so maybe its a step in the right direction. Allegro 
divides its functionality into several modules -- when I was 
using C I would have to specify each of these libs, which I would 
get from pkgconfig. I wonder if I need to do that here, but it 
wasn't necessary when I was building with dmd alone.


Re: DUB: link to local library

2014-09-10 Thread rcor via Digitalmars-d-learn

On Wednesday, 10 September 2014 at 16:26:07 UTC, andre wrote:
Dub command line supports something like Dub add-local. Then 
you can use the package directly.


Kind regards
Andre


DAllegro5 doesn't have an official dub package yet, but I threw 
together one that could build the library and added it with `dub 
add-local`. It now shows up in

`dub list`, but adding:

dependencies: {
  dallegro5: ~master
}

doesn't seem to change anything.

I think the dub.json I put in dallegro5 works, because the 
library it produces can be used to run the example with dmd.


Re: DUB: link to local library

2014-09-10 Thread JD via Digitalmars-d-learn
DAllegro5 doesn't have an official dub package yet, but I threw 
together one that could build the library and added it with 
`dub add-local`. It now shows up in

`dub list`, but adding:

dependencies: {
  dallegro5: ~master
}



I think I recently saw something like:

dependencies: {
dallegro5: { version: ~master, path: 
../path/to/your/lib }

}

Although I haven't tried it yet.

Bye, Jeroen


std.range.byLine

2014-09-10 Thread Nordlöw
I'm missing a range variant of byLine that can operate on strings 
instead of just File.


This is such a common feature so I believe it should have its 
place in std.range.


My suggestion is to define this using

splitter!(std.uni.isNewline)

but I'm missing std.uni.isNewline.

I'm guessing the problem here is that newline separators can be 1 
or 2 bytes long. that is it Separator must be of the same time as 
Range.


Should I add an overload in PR?

Destroy.


Downloading Files in D

2014-09-10 Thread Nordlöw
What's the recommended way to to download files (typically over 
http(s) or ftp) from within D? Should I use


http://dlang.org/phobos/std_net_curl.html

or

vibed.org

?

I'm asking because I've read somewhere that there have been 
complaints about the curl wrapper.


Re: Downloading Files in D

2014-09-10 Thread Adam D. Ruppe via Digitalmars-d-learn
The curl one should be easiest for just downloading files. The 
big problems with it are that it can be a pain to get the library 
working with versioning and stuff and that it sometimes does the 
wrong thing in advanced use cases.


But if the curl library works for you at all, doing downloading 
with it is easy.


Re: std.range.byLine

2014-09-10 Thread Ali Çehreli via Digitalmars-d-learn

On 09/10/2014 02:06 PM, Nordlöw wrote:

I'm missing a range variant of byLine that can operate on strings
instead of just File.

This is such a common feature so I believe it should have its place in
std.range.

My suggestion is to define this using

splitter!(std.uni.isNewline)

but I'm missing std.uni.isNewline.

I'm guessing the problem here is that newline separators can be 1 or 2
bytes long. that is it Separator must be of the same time as Range.

Should I add an overload in PR?

Destroy.


There is std.ascii.newline. The following works where newline is '\n' 
e.g. on my Linux system. :)


import std.ascii;
import std.algorithm;
import std.range;

void main()
{
assert(foo\nbar\n
   .splitter(newline)
   .filter!(a = !a.empty)
   .equal([ foo, bar ]));
}

Ali



Re: std.range.byLine

2014-09-10 Thread Nordlöw
On Wednesday, 10 September 2014 at 22:29:55 UTC, Ali Çehreli 
wrote:

assert(foo\nbar\n
   .splitter(newline)
   .filter!(a = !a.empty)
   .equal([ foo, bar ]));
}

Ali


Ok, great.

So I got.

auto byLine(Range)(Range input) if (isForwardRange!Range)
{
import std.algorithm: splitter;
import std.ascii: newline;
static if (newline.length == 1)
{
return input.splitter(newline.front);
}
else
{
return input.splitter(newline);
}
}

unittest
{
import std.algorithm: equal;
assert(equal(a\nb.byLine, [a, b]));
}

One thing still:

Is my optimization for newline.length == 1 unnecessary or perhaps 
even wrong?


Re: std.range.byLine

2014-09-10 Thread Nordlöw

On Wednesday, 10 September 2014 at 22:45:08 UTC, Nordlöw wrote:

auto byLine(Range)(Range input) if (isForwardRange!Range)
{
import std.algorithm: splitter;
import std.ascii: newline;
static if (newline.length == 1)
{
return input.splitter(newline.front);
}
else
{
return input.splitter(newline);
}
}


IMHO, this should be added to std.string and restricted to 
isSomeString. Should I do a PR?