Re: Ranges: How to take N last of elements of range
On Friday, 25 December 2015 at 20:06:04 UTC, drug wrote: 25.12.2015 17:13, Ur@nuz пишет: [...] You can do following http://dpaste.dzfl.pl/41c57f89a5a0 The reason of compile error is your using a range as a separator, change it to single symbol and it works. Also I used 'array' after 'take' to make range bidirectional to let next 'retro' works. And 'join' joins result to string with '.' as a separator. Thanks for reply. This is useful
Re: DMD -L Flag, maybe a bug?
On Friday, 25 December 2015 at 23:45:42 UTC, anonymous wrote: ... That means a .lib file, right? Yes. The GtkD docs say to use -L though [2], so I suppose that should work too. Maybe show your exact complete command line, if you want to find out why it doesn't work for you. It's almost like the example in the URL you showed: dmd test.d -LC:/gtkd/src/build/GtkD.lib Where the command above doesn't works, on the other hand the 2 others below works: dmd test.d -L C:/gtkd/src/build/GtkD.lib dmd test.d C:/gtkd/src/build/GtkD.lib But if you do a search for problems like: Linking problem or Symbol Undefined most command lines uses this: "-Lpath/to/whatever" (Without Space). And another thing... there is other flag commonly used "-I" with doesn't need space, so most people will assume the same for -L. Well this problem took only 30 minutes, because luckily I found the answer on the second link, but it could take hours. Bubba.
Re: Graphics/font/platform backends with common interfaces?
On 26/12/15 3:46 AM, thedeemon wrote: On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote: So far I've been implementing windowing and image libraries for Phobos. Right now windowing works on Windows minice eventing. Once eventing is done it is ready for the first stage of feedback. I don't understand something about this project. Having existing GtkD, DFL, DlangUI, SimpleDisplay, DQuick and probably a few others, creating windows on different platforms and eventing seems to be a solved problem, multiple times solved. But your project is lasting for years at this little stage. And this makes me wonder what it is about. I take a lot longer because I'm not doing the quick and dirty. In a few hundred lines you can on Windows for example create a window and OpenGL context. Great! But now what about iterating over the displays? Screenshots? Changing title? Icons? Notifications? This is why it is not a solved problem. I've just checked SDL, it doesn't handle notifications at all and a bunch of other things I do. I'm almost ready for a feedback post. Problem is.. png image loader is failing on palette interlaced loading.
Re: DMD -L Flag, maybe a bug?
On 25.12.2015 19:32, Bubbasaur wrote: On Friday, 25 December 2015 at 15:06:27 UTC, anonymous wrote: In fact it works without the "-L". Which makes me wonder if I was using it wrongly? I'm convinced that putting a space between "-L" and its argument is nonsense. The "-L" part just means "pass the empty string to the linker", which doesn't do anything. And the argument is interpreted by dmd then, not by the linker. What exactly are trying to pass to the linker? A lib: GtkD. That means a .lib file, right? dmd knows how to handle .lib files [1], so it's no surprise that things work when you pass the .lib file to dmd. The GtkD docs say to use -L though [2], so I suppose that should work too. Maybe show your exact complete command line, if you want to find out why it doesn't work for you. [1] http://dlang.org/dmd-windows.html#switches [2] https://github.com/gtkd-developers/GtkD/wiki/Installing-on-Windows#testing-installation
Re: Ranges: How to take N last of elements of range
25.12.2015 17:13, Ur@nuz пишет:
static struct LogerInfo
{
string func;
int line;
void write(T...)(T data)
{
import std.stdio;
import std.algorithm: splitter;
import std.range: retro;
import std.range: take;
import std.array: array;
string shortFuncName =
func.splitter(".").retro.take(2).retro.array;
writeln( shortFuncName, "[", line, "]: ", data );
}
}
You can do following http://dpaste.dzfl.pl/41c57f89a5a0
The reason of compile error is your using a range as a separator, change
it to single symbol and it works. Also I used 'array' after 'take' to
make range bidirectional to let next 'retro' works. And 'join' joins
result to string with '.' as a separator.
Re: DMD -L Flag, maybe a bug?
On Friday, 25 December 2015 at 15:06:27 UTC, anonymous wrote: ... You can try removing the "-L" entirely. If it still works... In fact it works without the "-L". Which makes me wonder if I was using it wrongly? What exactly are trying to pass to the linker? A lib: GtkD. Can you give a link to that? Sure (It's the second from the last answer): http://www.dsource.org/forums/viewtopic.php?t=4928&sid=e1caca2e12a14c49672a92126dc0922c Bubba.
Re: Understand typeof trick
On Friday, 25 December 2015 at 14:55:04 UTC, anonymous wrote:
On 25.12.2015 13:10, Joakim Brännström wrote:
[B]
Evaluates to the function type "constructed" by binaryFun.
Almost. It evaluates to the type of the expression. The
expression is a function call, so typeof evaluates to the
return type of the generated function.
Ahh, I missed this.
The subtle difference between:
int fun(uint x) { return 1; }
pragma(msg, typeof(fun)); // -> int(uint x)
pragma(msg, typeof(fun()); // -> int
That second one leads us to the longest form of the is-typeof
idiom: `is(typeof({foo(); bar();}))`. Wrapping the code in a
delegate so that it's an expression, which can be passed to
typeof.
Nice, didn't know that was possible. I'll remember that.
Thank you for the detailed answer.
Re: Understand typeof trick
Well, what I'd really want to document here's isn't necessarily the nitty-gritty of the idiom and why it is used (that's a thing for api authors, but these docs are targeted at api consumers), but more just what it actually means at a glance. That line of code simply means "pred must be a function that takes two arguments of the same type as the front of needle and haystack" The binaryFun helper means you can pass your own function, callable object, or string! The string is one of those "a == b" style things you sometimes see in Phobos. I could write on that line of code for probably a full page from several perspectives - there's quite a lot going on there. But the user of findSkip, when reading that doc, wants to simply know that constraint is about the predicate function, that it must take those arguments. Once you get used to the pattern, you'll know what it means, but first-time readers would surely appreciate a translation right there... and examples of what kind of compiler errors will result if you make a mistake. (And I think it also must return bool, though the constraint doesn't say that... nor does the prose... nor do any of the examples get into it. Gah, so either I'm wrong or that's an undocumented requirement. is(typeof()) could check the return value though.)
Re: DMD -L Flag, maybe a bug?
On 25.12.2015 15:40, Bubbasaur wrote: But at least on Windows, you need to put a space between -L and the PATH. Which It's weird, since with "-I" flag you don't need any space. I don't think that's right. Unless something awful is going in Windows dmd, that should be processed as two separate entities: "-L" passes nothing to the linker, and whatever you try to send the linker is interpreted independently by dmd. You can try removing the "-L" entirely. If it still works, then dmd is apparently able to handle things for you, and you don't need to go the linker yourself. What exactly are trying to pass to the linker? It took me 30 minutes until I find why my program wasn't compiling. (I found the tip on a forum elsewhere). Can you give a link to that?
Re: Understand typeof trick
On 25.12.2015 13:10, Joakim Brännström wrote:
In http://forum.dlang.org/post/ojawnpggfaxevqpmr...@forum.dlang.org Adam
uses findSkip as an example and especially points out the "D idiom with
is/typeof".
I'm not quite sure I understand it correctly. Please correct me if I
have misunderstood anything regarding the idiom.
findSkip: http://dlang.org/phobos/std_algorithm_searching.html#.findSkip
bool findSkip
(alias pred = "a == b", R1, R2)
(ref R1 haystack, R2 needle)
if (isForwardRange!R1 &&
isForwardRange!R2 &&
is([C]
typeof( [B]
binaryFun!pred( [A]
haystack.front, needle.front;
[A]
Nothing special. findSkip's pred is passed on to binaryFun. binaryFun's
constraints thus apply to findSkip's pred.
See http://dlang.org/phobos/std_functional.html#.binaryFun
Yup, and then the resulting function is called with arguments
`haystack.front, needle.front`. The template instantiation, and the
function call can fail compilation (more precisely: semantic analysis).
In that case, A is marked as being "broken".
[B]
Evaluates to the function type "constructed" by binaryFun.
Almost. It evaluates to the type of the expression. The expression is a
function call, so typeof evaluates to the return type of the generated
function.
If A has been marked broken, then B does not become a proper type, and
it's marked "broken" as well.
[C]
The is expression is true if A->B is valid "code".
It's true if the argument, i.e. B, is a proper type. In particular, B
must not be marked "broken".
If B is "broken", then C is false. Any error messages that would usually
be printed for the broken A/B are suppressed.
It is used to convert any compiler errors to "false" (thus the
constraint wouldn't be fulfilled).
Yes, but be aware that this only works on semantic errors, not on syntax
errors.
For example, `is(foo())` and `is(typeof(foo(); bar();))` don't give you
false, but they error out in the syntax checking phase.
That second one leads us to the longest form of the is-typeof idiom:
`is(typeof({foo(); bar();}))`. Wrapping the code in a delegate so that
it's an expression, which can be passed to typeof.
Question:
I guess that binaryFun is used in the implementation of findSkip.
Yeah, the constraint wouldn't make sense otherwise.
The reason for using this type of idiom is to avoid "compilation errors"
to occur in the implementation when pred/R1/R2 is "funky". It "confuses"
the user.
The idiom is thus used to move errors to the call site?
"D idiom: constraint error at call site"?
I think Adam meant just the is(typeof(...)) thing itself, regardless of
where it appears.
Constraints are used to reject bad instantiations early on, yes. They're
also used to distinguish different template "overloads".
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 23:34:58 UTC, Rikki Cattermole wrote: So far I've been implementing windowing and image libraries for Phobos. Right now windowing works on Windows minice eventing. Once eventing is done it is ready for the first stage of feedback. I don't understand something about this project. Having existing GtkD, DFL, DlangUI, SimpleDisplay, DQuick and probably a few others, creating windows on different platforms and eventing seems to be a solved problem, multiple times solved. But your project is lasting for years at this little stage. And this makes me wonder what it is about.
DMD -L Flag, maybe a bug?
If you follow the link below: https://dlang.org/dmd-windows.html#switch-L It's written: " -Llinkerflag pass linkerflag to the linker link.exe , for example, -L/ma/li " But at least on Windows, you need to put a space between -L and the PATH. Which It's weird, since with "-I" flag you don't need any space. It took me 30 minutes until I find why my program wasn't compiling. (I found the tip on a forum elsewhere). Is this a bug or a mistake? Bubba.
Ranges: How to take N last of elements of range
How to take N last of elements of range?
I have tried the following example in my code, but it says that
it deprecated. What is the other possible way?
static struct LogerInfo
{
string func;
int line;
void write(T...)(T data)
{
import std.stdio;
import std.algorithm: splitter;
import std.range: retro;
import std.range: take;
import std.array: array;
string shortFuncName =
func.splitter(".").retro.take(2).retro.array;
writeln( shortFuncName, "[", line, "]: ", data );
}
}
It says the following:
/usr/include/dmd/phobos/std/range/package.d(224): Deprecation:
function std.algorithm.iteration.splitter!("a == b", string,
string).splitter.Result.popBack is deprecated - splitter!(Range,
Range) cannot be iterated backwards (due to separator overlap).
/usr/include/dmd/phobos/std/range/package.d(223): Deprecation:
function std.algorithm.iteration.splitter!("a == b", string,
string).splitter.Result.back is deprecated - splitter!(Range,
Range) cannot be iterated backwards (due to separator overlap).
declarative/parser.d(68): Error: template std.range.retro cannot
deduce function from argument types !()(Take!(Result!())),
candidates are:
/usr/include/dmd/phobos/std/range/package.d(188):
std.range.retro(Range)(Range r) if
(isBidirectionalRange!(Unqual!Range))
declarative/parser.d(130): Error: template instance
declarative.parser.Parser!(TextForwardRange!(string,
LocationConfig(true, true, true, true,
true))).Parser.LogerInfo.write!(string, string) error
instantiating
declarative/interpreter_test.d(11):instantiated from
here: Parser!(TextForwardRange!(string, LocationConfig(true,
true, true, true, true)))
Failed: ["dmd", "-v", "-o-", "declarative/interpreter_test.d",
"-Ideclarative"]
Re: Must I compile on the target architecture?
On Friday, 25 December 2015 at 12:43:05 UTC, Jakob Jenkov wrote: If I write a program in D and I use Windows for development but want it to run on Linux, do I have to copy the source code to the target Linux machine and compile it there, to make an executable for that machine? What is the standard process for cross platform compilation? For building Windows apps on Linux, I just run the Windows version of dmd on wine, right from the linux box. For Linux programs built on Windows... you'll prolly just want to copy it to a linux box.
Re: Must I compile on the target architecture?
On Friday, 25 December 2015 at 12:43:05 UTC, Jakob Jenkov wrote: Hi, just a quick question: If I write a program in D and I use Windows for development but want it to run on Linux, do I have to copy the source code to the target Linux machine and compile it there, to make an executable for that machine? What is the standard process for cross platform compilation? You're right. Simply copy your files to the target and compile.
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist
wrote:
Shouldn't there be like a common (interface/abstract class)
that these back-ends can fulfill? maybe I am unaware of how
these things are done. And perhaps there are performance
reasons that many of these are baked in.
The way I see it it can be decomposed in many parts.
{color definition} depends on nothing
{image concept library} depends on {color definition}
{windowing library} depends on {image concept library} and
platform APIs
{image loading library} depends on {image concept library}
{software rasterizer} depends on {image loading library}
{font rasterizer} depends on {image loading library}
{UI libray} depends on {windowing library}, {font rasterizer} and
{image loading library} and probably everything else.
To simplify I think only UI libraries and windowing libraries
need to know about GPU acceleration.
For example ae.utils.graphics is an amazing image concept library
(also color definition) we have.
imageformats is a good loader library that define its own
abstraction.
for font rasterizer I use a translation of stb_truetype but
something way better could be done that looses less generality.
I think we need a more STL-like approach to UI but it seems not
enough people are willing to reuse each other work and avoid
creating new interfaces/data types, in favor of creating full
stack solutions.
Must I compile on the target architecture?
Hi, just a quick question: If I write a program in D and I use Windows for development but want it to run on Linux, do I have to copy the source code to the target Linux machine and compile it there, to make an executable for that machine? What is the standard process for cross platform compilation?
Understand typeof trick
Hello, In http://forum.dlang.org/post/ojawnpggfaxevqpmr...@forum.dlang.org Adam uses findSkip as an example and especially points out the "D idiom with is/typeof". I'm not quite sure I understand it correctly. Please correct me if I have misunderstood anything regarding the idiom. findSkip: http://dlang.org/phobos/std_algorithm_searching.html#.findSkip bool findSkip (alias pred = "a == b", R1, R2) (ref R1 haystack, R2 needle) if (isForwardRange!R1 && isForwardRange!R2 && is([C] typeof( [B] binaryFun!pred( [A] haystack.front, needle.front; [A] Nothing special. findSkip's pred is passed on to binaryFun. binaryFun's constraints thus apply to findSkip's pred. See http://dlang.org/phobos/std_functional.html#.binaryFun [B] Evaluates to the function type "constructed" by binaryFun. [C] The is expression is true if A->B is valid "code". It is used to convert any compiler errors to "false" (thus the constraint wouldn't be fulfilled). Question: I guess that binaryFun is used in the implementation of findSkip. The reason for using this type of idiom is to avoid "compilation errors" to occur in the implementation when pred/R1/R2 is "funky". It "confuses" the user. The idiom is thus used to move errors to the call site? "D idiom: constraint error at call site"?
GTKD - Get the size of the context
Hello, i want to draw something to a GTKD context and i need the size of the context in pixel but i don't know how i can get the pixel height and width? Any ideas? With best regards
Re: Graphics/font/platform backends with common interfaces?
On Wednesday, 23 December 2015 at 19:22:01 UTC, Taylor Hillegeist
wrote:
So I have seen alot of projects that need the same sort of
stuff.
graphics libraries
gui libraries
game libraries
ploting libaries
they would all benefit from a backend solution with a common
interface for
color
fonts
drawing pen_style aliasing etc.
but each one i look at seems to have a built up solution with
various degrees of integration with things like freetype gdi
cairo sdl glew opengl.
Shouldn't there be like a common (interface/abstract class)
that these back-ends can fulfill? maybe I am unaware of how
these things are done. And perhaps there are performance
reasons that many of these are baked in.
perhaps it should be like:
standard color implementation.
font interface that converts glyphs into drawing strokes.
and a standard set of drawing instructions with transforms.
//probably a grotesque simplification
interface font_do{
glyphstrokes getstrokes(string characterstoget);
}
interface draw_do{
drawpixel(double x,double y);
drawline(double x,double y);
drawglyph(glypstrokes g);
getpostdrawnsize(glypstroks g)
... other things
}
I can consider splitting of DlangUI library into platform and
widgets.
Platform will provide window creation, initialization of OpenGL
context when necessary, keyboard and mouse events, user events.
As well, it has font support - FreeType and on Windows it can use
native Windows fonts.
Currently supported platforms:
Windows: Win32 API or SDL
Linux, OSX: SDL or X11
I'm planning to make Cocoa (native OSX) and Wayland (for Linux)
support later.
