Re: The Problem With DIPs
On Wednesday, 8 June 2016 at 21:15:20 UTC, deadalnix wrote: On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: On 6/7/2016 1:32 PM, Jack Stouffer wrote: a lousy 28% of DIPs are either definitively closed or accepted. I understand that is frustrating. It happens to mine as well, though I am less bothered by it. It's a question of framing. Consider the regression list: https://issues.dlang.org/buglist.cgi?bug_severity=regression_status=NEW_status=ASSIGNED_status=REOPENED_id=208862_format=advanced There are currently 34 issues on it, where we implemented a feature and inadvertently broke something. There are constant complaints on the forum that we have not "fully" implemented things. I agree 100% with the sentiment. We have way too many 95% things. On the other hand, many DIPs are not about implement this new groundbreaking thing, but about tightening loose screws. A good chunk of the problem is that development is made using the wack a mole methodology rather than a more principled approach. Having a DIP specifying at least the intended end goal would be beneficial. Such DIPs would for instance include DIP27/28/30 that change very little of the behavior, but fix a typesystem hole and provide a principled approach to what we already do. Maybe you should make a DIP for that? ;)
Re: The Problem With DIPs
On Wednesday, 8 June 2016 at 19:59:27 UTC, Walter Bright wrote: On 6/7/2016 1:32 PM, Jack Stouffer wrote: a lousy 28% of DIPs are either definitively closed or accepted. There are currently 34 issues on it, where we implemented a feature and inadvertently broke something. There are constant complaints on the forum that we have not "fully" implemented things. How about everyone stop working on "new features" and try to make D solid? Surely you realize the downside to starting a new project in the midst of a current one? It's very easy to start something new, it's enticing in fact... But the the previous project(s) always suffer. D doesn't need any more fancy new features. It needs to be made rock solid and made to be used. My biggest frustration with D is not the language or the compiler but the tools and regressions(that come from starting new "projects"). If one keeps piling stuff on top of stuff eventually the weight of it all creates such a pressure that it turns it into crap(or diamonds, but that usually takes millions of years ;) I use Visual D, for example, and it's the most barbaric way to debug(ok, better than gbd and the other stuff you guys tend to use because you won't get out of the dark ages). I have to wade through useless information to find what I want. OTH, .NET debugging is a walk in the park... I can even write my own visualizers if I want too. I'm spoiled, I've seen the light. Forgive me! What's happening is that the "rest of the world" has great tool sets. D has great language capabilities. D is ahead in that respect but is behind in the other. Remember, most of the programmers out there are not you and they just want things to work so they can do their hello world apps or make a virus or fart app. They need things to work, work well, and look nice and inviting. If you can't get these people you are catering only to the upper echelon of the programmers in the world, most of which are too hard headed and old to switch to something new. Target the kids and D will live long and prosper, target the old fogies and it will die a quick death.
Re: Parse File at compile time, but not embedded
If I use an enum dmd DOES remove it in release build. But I'm not sure for the general case yet.
Re: Parse File at compile time, but not embedded
On Tuesday, 7 June 2016 at 02:04:41 UTC, Mithun Hunsur wrote:
On Monday, 6 June 2016 at 21:57:20 UTC, Pie? wrote:
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
[...]
This doesn't seem to be the case. In a release build, even
though I never "use" the string, it is embedded. I guess this
is due to not using enum but enum seems to be much harder to
work with if not impossible.
[...]
Not necessarily, You chased that rabbit quite far! The data
your reading could contain sensitive information only used at
compile time and not meant to embed. For example, the file
could contain login and password to an SQL database that you
then connect, at compile time and retrieve that information
the disregard the password(it is not needed at run time).
This is definitely possible, but it can depend on your
compiler. If you use an enum, it'll be treated as a
compile-time constant - so if you never store it anywhere (i.e.
enum File = import('file.txt'); string file = File; is a no-no
at global scope), you should be fine.
If you do find yourself in the precarious situation of storing
the data, then it's up to your compiler to detect that there
are no runtime references to the data and elide it. LDC and GDC
most likely do this, but I doubt DMD would.
For safety, you should try and reformulate your code in terms
of enums and local variables; this *should* work with DMD, but
it's possible it's not smart enough to catch onto the fact that
the function is never used at run-time (and therefore does not
need to be included in the executable).
Ok, I will assume it will be able to be removed for release. It
is an easy check(just search if binary contains file info). I'm
sure an easy fix could be to write 0's over the data in the
binary if necessary.
If I use an enum dmd does *not* remove it in release build. I
will work on parsing the file using CTFE and hopefully dmd will
not try to keep it around, or it can be solved using gdc/ldc or
some other method.
Re: Parse File at compile time, but not embedded
On Monday, 6 June 2016 at 21:31:32 UTC, Alex Parrill wrote:
On Monday, 6 June 2016 at 17:31:52 UTC, Pie? wrote:
Is it possible to parse a file at compile time without
embedding it into the binary?
I have a sort of "configuration" file that defines how to
create some objects. I'd like to be able to read how to create
them but not have that config file stick around in the binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin
that mixes in auto x = new my1; auto y = new my1; auto z = new
my2;
}
If parseConfig uses import('Config.txt') then config.txt will
end up in the binary which I do not want. It would be easier
to be able to use import and strip it out later if possible.
Config.txt may contain secure information, which is why is
doesn't belong in the binary.
Most compilers, I believe, will not embed a string if it is not
used anywhere at runtime. DMD might not though, I'm not sure.
This doesn't seem to be the case. In a release build, even though
I never "use" the string, it is embedded. I guess this is due to
not using enum but enum seems to be much harder to work with if
not impossible.
But reading sensitive data at compile-time strikes me as
dangerous, depending on your use case. If you are reading
sensitive information at compile time, you are presumably going
to include that information in your binary (otherwise why would
you read it?), and your binary is not secure.
Not necessarily, You chased that rabbit quite far! The data your
reading could contain sensitive information only used at compile
time and not meant to embed. For example, the file could contain
login and password to an SQL database that you then connect, at
compile time and retrieve that information the disregard the
password(it is not needed at run time).
Parse File at compile time, but not embedded
Is it possible to parse a file at compile time without embedding
it into the binary?
I have a sort of "configuration" file that defines how to create
some objects. I'd like to be able to read how to create them but
not have that config file stick around in the binary.
e.g., (simple contrived example follows)
Config.txt
x, my1
y, my1
z, my2
class my1 { }
class my2 { }
void parseConfig(A)
{
}
void main()
{
parseConfig('Config.txt') // Effectively creates a mixin that
mixes in auto x = new my1; auto y = new my1; auto z = new my2;
}
If parseConfig uses import('Config.txt') then config.txt will end
up in the binary which I do not want. It would be easier to be
able to use import and strip it out later if possible. Config.txt
may contain secure information, which is why is doesn't belong in
the binary.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 05:28:58 UTC, ketmar wrote: On Monday, 6 June 2016 at 05:13:11 UTC, Daniel Kozak wrote: You can still unregister your critical thread from GC. exactly. that's what i did in my sound engine, and it works like a charm: i can enjoy hiccup-less ogg replaying on the background while the main code enjoys GC. So, did your sound engine 'hiccup' before you did that? Do you think it is acceptable? Does C#, Go, or other languages have this problem out of the box? I could write a hiccup-less sound player in C# without messing with the GC at all and it be fully functional... D has a GC problem and they never arrive on time and sometimes make a mess. The real problem is no one seems to care except the people that end up with trash all over their lawn but isn't that always the case?
Re: Embed files into binary.
On Monday, 6 June 2016 at 06:10:35 UTC, rikki cattermole wrote: On 06/06/2016 6:06 PM, Pie? wrote: On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;) Finally was many many months ago[0]. I'm not happy with my implementation. Either way, somebody has to go ahead and write one for Phobos. Although good luck with getting that in. [0] https://github.com/rikkimax/alphaPhobos/tree/master/source/std/experimental/vfs Would this, say, allow an application to embed a "file system" into it's run time and then virtually dispatch file IO? If so, what about write access(the binary would grow in size when written to)? What about seemlessly shifting between a real file system and the virtual one by simple flag toggling and rebuilding? If so, then D would definitely benefit from it. This way one can create binaries and back them by a real file system for debugging purposes(easy access, no extracting from binaries or having to store them) then for release, one can turn that in to a virtual file system. If this is what your vfs does or aims at then hats off! Cheerio! Where do I sign up? If not, would you mind expanding it to do such a thing? I am essentially coding up something like that as we speak... Using static importing the binary and modulating all my file IO into a routine that chooses to use the physical file system when in debug mode and the imported data in release(it's quite easy, just dispatch to std.file io in debug and simply return the memory of the requested data in release).
Re: Embed files into binary.
On Monday, 6 June 2016 at 05:30:12 UTC, rikki cattermole wrote: On 06/06/2016 5:07 PM, Pie? wrote: [...] Then I would say go get a new image library as that one isn't a very good one. ..snip.. Right got rid of all that text. If you want to make the filesystem appear to have files it doesn't, you'll need a virtual file system library. Welcome to the next issue, getting libraries to support it ;) My point exactly! Glad you could finally support my conclusion! ;)
Re: Embed files into binary.
On Monday, 6 June 2016 at 03:23:02 UTC, rikki cattermole wrote:
On 06/06/2016 3:11 PM, Pie? wrote:
On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:
On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I believe the essentially converted the file into a ubyte or
something and then wrote that out to a temp file and read in
the temp
file... this seems a bit of a kludge to me.
They might do that for certain special cases, but
import("file.whatever") just drops the file content in memory
and you
can then access it as an array.
Because D allows such an embedding feature, maybe the file
system
should allow working with this concept?
Why do you need it through the file system? If you're writing
the
code, just use the array in memory. If it is external, see if
the
library offers something like that.
DLL and exe are a special case, most things don't need to be
physical
files.
Because, as I said, if I'm working with pre-exiting modules
that work
with file, I have to provide a file or modify the source.
e.g., how could I do this easily with your read in your png
module? It
takes a file..
/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));
recognize the code?
Of course, like I said, it can be modified in this case, but
that means
nothing in general.
ubyte[] theArray = import("...");
MemoryImage img = imageFromPng(readPng(theArray));
And that's just from the snippet you provided.
Yay overloads!
Yes, I figured it could be done because of the MemoryImage, but
that wasn't the point. You are delving in to code that you might
not normally have access or might not exist.
Adam wrote the MemoryImage that essentially does this but that is
not the general case.
Image if all you access to was readPng(string filename), then
what would you say? That was my point of posting the code, I
didn't mean for you to go look and see if it was possible to
achieve what I was saying in arsd(Formally known as Adam Druppe)
git repository ;)
If that was the case I would have titled this something similar
not but maybe not exactly equivalent(Just being pedantic since we
seem to be having a communications gap in how accurate and
precise our expressions are to be interpreted): "Possible to get
arsd(Formally known as Adam Druppe) readpng lib to read from
import(filename)?".
Since I was desiring to arrive at a more general solution to
potential future programming goals, I phrased my question in more
general terms. I assumed that this would be understood. (i.e.,
vague questions generally gets/desires vague results, intelligent
questions generally get/desires intelligent results, etc.)
In fact, I posted the most generic(and possibly vague) question I
could:
"Embed files into binary." I stated, but not exclaimed or
questioned(as these are in theory, mutually exclusive), in the
subject line!
But this is no question! It is a riddle my friend! By stating it
in such a way as to only imply the logical consequent "How to use
embedded files in the binary"[Of course, with an infinite number
of assumptions mixed in for spice]!
Why is this a necessary forgone conclusion, as Einstein would
some times say(not to me in particular, mind you)? Because there
is no point to embed files in a binary if one can not use them!!!
Naturally, this is why I further said, in a round about way, why
exporting them to temp files is not really an option. This was
further to exclude, if you are keeping track with your Venn
Diagram, something akin to the infinite monkey theorem... or a
breach in the space time continuum or just several responses
about along the lines "...save the data to a temp file and use
that".
Note my retort:
" Because D allows such an embedding feature, maybe the file
system
should allow working with this concept?"
Asking about future events and possibly space-time paradoxes!
For example, what if I derive some source code from some
unexpected places and they have some complex way of using D's
std.file routines and offers no interface to use memory arrays as
an input? Suppose further that it is very contorted and only
Steven Hawkins has figured out how to unravel the complexities of
the law of import/export. We are not privy to his knowledge or
intellectual properties. Would it not be intelligent and
forthright, mimicking Steven Hawkins in a sort of motherly
daughterly bond kind of way, to see that we must write new code
to solve the problem... this timing mimicking God himself as he
bought forth the earth and heaven?
Does that make sense?
Re: Embed files into binary.
On Monday, 6 June 2016 at 02:34:07 UTC, Adam D. Ruppe wrote:
On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote:
I believe the essentially converted the file into a ubyte or
something and then wrote that out to a temp file and read in
the temp file... this seems a bit of a kludge to me.
They might do that for certain special cases, but
import("file.whatever") just drops the file content in memory
and you can then access it as an array.
Because D allows such an embedding feature, maybe the file
system should allow working with this concept?
Why do you need it through the file system? If you're writing
the code, just use the array in memory. If it is external, see
if the library offers something like that.
DLL and exe are a special case, most things don't need to be
physical files.
Because, as I said, if I'm working with pre-exiting modules that
work with file, I have to provide a file or modify the source.
e.g., how could I do this easily with your read in your png
module? It takes a file..
/// Easily reads a png file into a MemoryImage
MemoryImage readPng(string filename) {
import std.file;
return imageFromPng(readPng(cast(ubyte[]) read(filename)));
recognize the code?
Of course, like I said, it can be modified in this case, but that
means nothing in general.
Re: Andrei's list of barriers to D adoption
On Monday, 6 June 2016 at 02:20:52 UTC, Walter Bright wrote: Andrei posted this on another thread. I felt it deserved its own thread. It's very important. - I go to conferences. Train and consult at large companies. Dozens every year, cumulatively thousands of people. I talk about D and ask people what it would take for them to use the language. Invariably I hear a surprisingly small number of reasons: and it's taken you that long to now that the following are the problem? (No offense... just seems like the following list is obvious whether 1 or 1 googol) * The garbage collector eliminates probably 60% of potential users right off. Duh! The claim is made that D can work without the GC... but that's a red herring... If you take about the GC what do you have? A ton of effort to build something that gets D to work properly without the GC. It can be done but it isn't done except by leet guru's who have the time and knowledge to do it. It is not a built in option that works out of the box. * Tooling is immature and of poorer quality compared to the competition. Duh! Every use Visual studio? Sure Visual D offers a glimpse of hope, but only glimpse. D has some cool stuff but that's all it is for most users in my guestimation. * Safety has holes and bugs. * Hiring people who know D is a problem. * Documentation and tutorials are weak. * There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d). I have strongly argued with Sönke to bundle vibe.d with dmd over one year ago, and also in this forum. There wasn't enough interest. * (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist. * Let's wait for the "herd effect" (corporate support) to start. * Not enough advantages over the competition to make up for the weaknesses above.
Re: Embed files into binary.
On Monday, 6 June 2016 at 02:18:48 UTC, docandrew wrote: On Monday, 6 June 2016 at 02:05:09 UTC, Pie? wrote: I saw somewhere someone explaining how to embed resources into a binary using the import keyword. I believe the essentially converted the file into a ubyte or something and then wrote that out to a temp file and read in the temp file... this seems a bit of a kludge to me. Is it possible to do the same, but create a sort of "in memory" file layout? While I can modify my own routines to read the "file" from memory, I can't do that easily with outside code(I could modify the binaries). Basically reading a file has to read it to memory, and if the file data already exists in memory, there is no point to read, just get it direct. Any thoughts on this? Because D allows such an embedding feature, maybe the file system should allow working with this concept? That way, it becomes VERY easy to embed files into the binary and work with them like they wernt. Also, going between the two different versions(embedded vs not) could be done with version (Release). I'm not sure about import, but one option is to put the external files directly in your binary as part of the linker step. Check out: http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967 On Windows I think there's a way to embed files in .DLLs and then link those into your executable, but I'm ignorant of the steps/tools required. -Jon Check out https://p0nce.github.io/d-idioms/ for embedding dll's. It's much easier than using the link you give. The problem is the same though, How to use the in memory data rather than re-reading it? It's not a problem of embedding but that the routines that use the data expect files, not memory backed virtual files.
Embed files into binary.
I saw somewhere someone explaining how to embed resources into a binary using the import keyword. I believe the essentially converted the file into a ubyte or something and then wrote that out to a temp file and read in the temp file... this seems a bit of a kludge to me. Is it possible to do the same, but create a sort of "in memory" file layout? While I can modify my own routines to read the "file" from memory, I can't do that easily with outside code(I could modify the binaries). Basically reading a file has to read it to memory, and if the file data already exists in memory, there is no point to read, just get it direct. Any thoughts on this? Because D allows such an embedding feature, maybe the file system should allow working with this concept? That way, it becomes VERY easy to embed files into the binary and work with them like they wernt. Also, going between the two different versions(embedded vs not) could be done with version (Release).
User Sub-Forms
Maybe it would be interesting to have a forum for users, by their name. e.g., Users Andrei Alexandrescu Walter Bright Users can petition to have themselves added. Works by these people can then be discussed in these groups. It will also make them feel special ;) Which may or may not be helpful.
Re: Generalized Ranges
On Sunday, 5 June 2016 at 03:17:43 UTC, Joakim wrote: On Sunday, 5 June 2016 at 00:28:36 UTC, Pie? wrote: [...] D can be made to do so, but I don't think ranges can, as they assume linear traversal. [...] For structures where a consistent linear traversal can be specified, perhaps you can map it to D ranges, though that may not always make sense for that structure. [...] It is an interesting idea, basically generalizing D's linear range operators to other non-linear structures. It might be worthwhile to define such basic traversal functions for common structures like trees or certain kinds of graphs, so they have a common interface. I don't think using D ranges underneath will work most of the time though. I'll have to think about it more and next time I get a change to apply it I might try. Using lambdas makes working with arbitrary structures quite easy but there is probably a performance issue. With all the compile time logic D has, I imagine a lot of this could be optimized away.
Generalized Ranges
In a mathematical space we can define operators that allow us to
move around in it. Take your typical Euclidean N space. We can
define a set of orthogonal motions for each dimension. These can
be represented by vectors(your typical orthogonal matrix),
derivatives(infinitesimal differential increments), etc.
We can generalize this to many other spaces of dimension N by
providing a set of N movement operators M_j.
Each M_j represents an incremental movement in the jth dimension.
In D, we can represent these as lambdas. The user provides how to
move to the next element on the space. Iterators are a simple
concept of this as they blindly step to the next element. In
general though, we can have very complex spaces and move through
those spaces in very complex ways depending on our Lambdas.
For example, suppose we have a Tree structure. In this case we
have two orthogonal operators "sibling" and "ancestor". One moves
us "up and down" levels of the tree and the other moves us along
the "leafs". We can even visualize this by embedding the tree in
to R^2 and correlating sibling movement with vertical movement in
R^2 and ancestor movement with horizontal movement. Traversing
the Tree can then be mapped out in R^2 and visualized.
Most common computer programming data structures have simple
movement operators:
Single dimension spaces:
List: Incremental: (list, k) => { return list[k]; }
Stack: Incremental: (stack) => { return stack.pop(); }
Queue: etc.
The movement operators can be written quite simply because they
are generally internally defined and the language supports it.
The point here is that most of the basis structures are
"linear"... that is, use a single movement operator to define how
to "move" from one position in the space to another. (e.g.,
list[k] move k steps from the origin and returns the "point" at k)
The above cases generally are all the same but only tailor the
movement operator to specific performance or behavioral
characteristics.
Two dimension spaces:
Tree: Incremental, Incremental: (Tree) => { return
Tree.Child; }, (Tree) => { return Tree.Sibling; }
The Single dimension product cases(List^2 = List[List[]],
etc).
etc.
The point I'm trying to make is that when we deal with
structures, the motions specify the structure. Most of the time
we deal with simple motions(linear/incremental).
Can D deal with the general case?
i.e., Can I specify a series of movement operators/lambdas that
describe how I want to move through the space(maybe very complex
where the operators are more like tensors(position dependent))
and then leverage D ranges to access the space?
A simple example could be a 2D List, where instead of
incremental, I have:
(x,y) => { if (x % 2 == 0) return list[0, y]; return list[x, y %
2]; }
Here the movement operator is cannot be written orthogonality.
(e.g., we can't separate it as movement in the "x" direction then
in the "y")
An orthogonal case might be
(x) => { l = list[x, Y]; X = x; return l; } (y) => { list[X, y];
y = Y; return l; }
Then call (x) then (y), or vice versa gives us our element at
(x,y). (the intermediate results are projections which are only
"half-solutions")
I noticed that when I was recursing a tree structure:
var Tree = new Dictionary();
Where each object may be another Dictionary(), it
would be much easier to be able to specify the motions in this
space in which case I could simply "iterate" over it rather than
use recursion directly. While we can abstract away the explicit
recursion for simple cases, it becomes much harder when there are
many "paths" to take at once.
In terms of iterators though, it is simply specifying the
movement operators then the action to take at the point. If a
nice generic set of tools existed(maybe D's ranges are suitable
as a foundation?) then I could do something like
Tree.Traverse(
(x, T) => { foreach(var child in T) yield child; },
(y, T) => { if (y is Dictionary) yield y; else
Eval(y); },
(e, T) => { ... do something with e, a leaf ... })
or equivalently
void recurse()
{
foreach(var child in T)
{
if (child is Dictionary)
recurse();
else
Eval(child);
}
}
If you were paying attention you could essentially see the two
orthogonal movements(the foreach is a motion in one direction and
the recurse is the other). What is nice about the first example
is that it separates the traversing of the space from the "work"
done on the "points" in the space. For complex cases this is a
benefit, although there may be some cross referencing between
evaluation and movement. E.g., move left if point has some
property, else move right.
Any Ideas?
PS. The above code is more like pseudo-code. I've been using .NET
a lot lately and it shows! ;) Also, The idea is half baked... it
may need some work.
Re: Writing adaptor/wrappers with most scalability and least work
On Saturday, 4 June 2016 at 02:10:57 UTC, Adam D. Ruppe wrote: On Saturday, 4 June 2016 at 01:04:08 UTC, Pie? wrote: alias this pImage; It is actually `alias pImage this;` That should do what you want right here. Then you can add your own methods or wrap/disable the image ones one by one. Is there a better way or is this the standard technique? I was hoping to use some type of design by introspection but haven't come up with a solid way to accomplish this.
Re: adamdruppe: Drawing scaled image
On Saturday, 4 June 2016 at 02:22:37 UTC, Adam D. Ruppe wrote:
On Friday, 3 June 2016 at 20:06:50 UTC, Pie? wrote:
Thanks! It is working. A few issues with my images being
clipped and not throwing when file doesn't exist...
That's weird.. I don't know what's going on there.
BTW have you seen my documentation site too?
http://dpldocs.info/experimental-docs/arsd.gamehelpers.OpenGlTexture.draw.1.html
It has a lot of my modules as well as my fork of the official
Phobos docs.
But the clipping and throwing shouldn't be a problem.
Is the display double buffered or will I need to deal with
that myself?
That's automatic.
Also, when the window is resized it goes white. Any ideas how
to fix that?
It might help to set a window.windowResized handler
window.windowResized = (int width, int height) {
window.redrawOpenGlSceneNow();
};
though I thought I did that automatically, I might have messed
it up (I don't often resize windows when using opengl mode...)
Thanks again! Your code has been the easiest to work with!
Normally have all kinds of problems.
yea, I try to keep it simple - I like minimal dependencies so
things just work without a complicated build process, but
sometimes I drop balls. If you ever want to do patches btw, I
also try to keep the code fairly simple so hacking on it
shouldn't be too hard.
Thanks. I will work on improving it the best I can when I
actually improve upon it ;)
In the simple display code, windowResized happens at the end of a
resize. You explicitly mention that WM_SIZING was not handled
because of performance issues in your code.
I tried to add a windowResizing but, of course, the delegate
signature conflicts with windowResized. I was thinking about
about to accomplish this.
Would it be better for events to have "Features"? e.g., to deal
with identical signatures?
e.g.,
delegate (int w, int h, Feature f)
and when the delegate is called we can use f to disambiguate the
call? (same call for WM_SIZE and WM_SIZING)
Of course, we could create more separation by somehow allowing
for separate assignment but not sure of any cool way to do
this?
Right now you add delegates to the event handling using an array.
...,delegate (int w, int h) { },...
It would be cool if we could add "specifiers" or possibly
attributes to them.
..., (delegate (int w, int h) { }).Resized, (delegate (int w, int
h) { }).Resizing,...
Any ideas on that?
Writing adaptor/wrappers with most scalability and least work
I would like to temporarily write some adapters or wrappers for
various types that allow the most extensibility with the least
amount of work. The goal is to get moving quickly as possible and
not try to implement all future needs. The wrappers will slowly
turn into full their own types and not be wrappers at all.
Obviously this requires declaring an interface and such. I
curious if I could somehow easily delegate work to the the types
I would like to wrap without designing a full fledged oo type.
e.g.,
class Image
{
alias this pImage;
}
So, for all purposes Image acts as pImage(except for constructor
calls). Of course now I'm bound to pImage's interface which I
might not like/want but it gets me pretty far and I can extend it
immediately with things I do not want in Image that are in pImage.
Any ideas on a good way to approach this? Is there some D tricks
that make life easier?
Cool D tricks resources?
Has anyone gathered up all the cool tricks one can do in D? There are a ton of things D can do differently that are optimal in some cases but I never remember them. A sort of cook book of D tricks for different applications would be nice
Re: adamdruppe: Drawing scaled image
On Friday, 3 June 2016 at 15:47:16 UTC, Adam D. Ruppe wrote:
On Thursday, 2 June 2016 at 04:01:03 UTC, Pie? wrote:
Thanks, I'll look into it. I have tried OpenGL with
simpledisplay but I cannot draw to the window. I assume other
drawing methods are required?
Yeah, you have to use the OpenGL functions instead of my
painter functions.
If so, I can use gamehelpers.d to do the drawing of the images?
Yeah, the OpenGlTexture class can help with it. You can
construct it with a TrueColorImage (readPng gives MemoryImage
which you can call .getAsTrueColorImage on to get one)
Then the OpenGlTexture has a draw method which you can call
from inside the redrawOpenGlScene method. OpenGL coordinates
are different than desktop, but the `create2dWindow` method in
gamehelpers.d will create one with a matrix that matches out.
So the function might look like:
SimpleWindow window = create2dWindow("your title", width,
height);
auto image = new
OpenGlTexture(readPng(your_png_file).getAsTrueColorImage));
window.redrawOpenGlScene = {
image.draw(x, y);
};
window.eventLoop();
Use window.redrawOpenGlSceneNow(); in the event loop to make it
redraw.
Thanks! It is working. A few issues with my images being clipped
and not throwing when file doesn't exist... but transparency and
such does exist.
Is the display double buffered or will I need to deal with that
myself?
Also, when the window is resized it goes white. Any ideas how to
fix that?
Thanks again! Your code has been the easiest to work with!
Normally have all kinds of problems.
Re: Why I won't fix phobos bugs anymore
On Friday, 3 June 2016 at 05:18:49 UTC, Patrick Schluter wrote: On Thursday, 2 June 2016 at 20:20:58 UTC, Andrei Alexandrescu wrote: On 06/02/2016 03:41 PM, Basile B. wrote: Yesterday I've took the decision not to propose anymore PR for Phobos bugfixes, even if most of the time it's easy. 1) It can take up to 2 or 3 weeks until a "phobos bugfix" get merged. Even a straight one. 2) Once a pr gets the label "@andrei". It basically means that "it's dead". Also meant to add: email should help. I am currently nursing 3-4 emails that are phobos-related among some 50 other important and urgent emails. There's some Midas effect - every day I wake up thinking "I'll halve my inbox today" and by the evening I still have 50 emails. It's maddening. But please don't take offense. Do email and I'll get to your work. Thanks! That would be Sisyphus, Midas was the king that starved because everything he touches becomes gold. Kinda silly, right? He could have just easily paid someone to feed him with all the gold he made, right? Also, Sisyphus must not have been too crafty! If he spend all that time digging out the hill then it would have been lower in gravity and he wouldn't have to carry it for eternity... just give it a nudge and it would roll down. Hen he could use all that dirt to build a barricade to keep the boulder from rolling away(unless it could magically go through the dirt).
Re: [OT] Things I like about Andrei
He's also very good looking!! That makes a difference! ;)
Re: Derive interface from class?
On Thursday, 2 June 2016 at 16:14:47 UTC, Pie? wrote:
Since D uses the single inheritance model for classes, I wonder
if it is possible to write a class then extract the interface
from it?
e.g.,
class myclass
{
public void foo() { writeln("adf"); }
}
mixin!(extractInterface!(myclass, myinterface));
Where the mixin creates the interface as if I typed it by hand:
interface myinterface
{
void foo();
}
This would greatly simplify having to start writing from a base
interface then add the class. It would also let one do multiple
inheritance from classes that are already defined.
Since every class must have a well defined interface, this
seems like it should be possible and relatively easy using
reflection. A bad idea?
I guess the main issue here is that myclass would then need to be
specified as being derived from myinterface after it was
generated! Not sure if this is possible to solve in D?
Derive interface from class?
Since D uses the single inheritance model for classes, I wonder
if it is possible to write a class then extract the interface
from it?
e.g.,
class myclass
{
public void foo() { writeln("adf"); }
}
mixin!(extractInterface!(myclass, myinterface));
Where the mixin creates the interface as if I typed it by hand:
interface myinterface
{
void foo();
}
This would greatly simplify having to start writing from a base
interface then add the class. It would also let one do multiple
inheritance from classes that are already defined.
Since every class must have a well defined interface, this seems
like it should be possible and relatively easy using reflection.
A bad idea?
Re: Asio Bindings?
On Thursday, 2 June 2016 at 11:15:59 UTC, Guillaume Piolat wrote: On Thursday, 2 June 2016 at 06:28:51 UTC, Pie? wrote: On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;) It doesn't seem to exist but using bindings for FMOD you should be able to access ASIO as an audio driver. If FMOD is that commercial sound lib then I'm not interested. I guess I'll have to try and write some type of asio lib when I get around to it. Hopefully it is not too difficult.
Re: Asio Bindings?
On Thursday, 2 June 2016 at 04:52:50 UTC, Mithun Hunsur wrote: On Thursday, 2 June 2016 at 04:02:36 UTC, Pie? wrote: Does anyone know if there is any Asio bindings or direct D available that allows for IO? Check out vibe.d: https://vibed.org/ - it includes a fairly complete implementation of asynchronous I/O, among other things. Oh, lol, I should have mentioned I meant for audio! ;)
Asio Bindings?
Does anyone know if there is any Asio bindings or direct D available that allows for IO?
Re: adamdruppe: Drawing scaled image
On Thursday, 2 June 2016 at 03:37:01 UTC, Adam D. Ruppe wrote:
On Thursday, 2 June 2016 at 03:19:20 UTC, Pie? wrote:
I'm curious about how to draw a scaled image.
There's a few general options:
1) Scale it yourself in-memory then draw. This is a pain, I
don't think my public libraries have a scale method
2) If on MS Windows, you can resize the window as a user and it
will stretch for you automatically. X on Linux doesn't support
this though.
3) Again, on MS Windows, you could call StretchBlt yourself to
scale and draw to it.
4) You can make an OpenGL texture and draw that at any
scale/rotation. This is fairly involved and uses a totally
different drawing system, but you can do it all with
simpledisplay.d too.
Also, png.d doesn't seem to work with alpha channel?
png does, but simpledisplay doesn't (except for the OpenGL
stuff, of course).
Both the MemoryImage implementations (TrueColorImage and
IndexedImage) have a rgba thing internally so you could
blend yourself before drawing (color.d has an alphaBlend
function, undocumented though), but if you want it done
automatically or in hardware, gotta use the opengl stuff.
Which also leads me to, how to draw one image on to another?
Gotta DIY there, I haven't written a function for that yet.
It's not hard to do though, at least with MemoryImages. The
simpledisplay Image is different - it is optimized for the
platform so the bits change around (it doesn't have an alpha
channel in all cases either).
My terminal emulator does this.. here's the function:
https://github.com/adamdruppe/terminal-emulator/blob/master/main.d#L296
so basically you copy the bits yourself, using the offset
members to handle the platform-specific stuff. I didn't do
alpha blending there though... but the blend function from
color.d could do it.
Doing alpha blending as we draw on the window needs new
functions used... AlphaBlend on Windows and XRender on Linux
IIRC. But since I tend to use OpenGL when I want to do lots of
the blending I haven't been in a big rush to do it.
Thanks, I'll look into it. I have tried OpenGL with simpledisplay
but I cannot draw to the window. I assume other drawing methods
are required?
auto window = new SimpleWindow(600, 400, "Pong game!",
OpenGlOptions.yes);
window.setAsCurrentOpenGlContext();
//auto img = imageFromPng(readPng(cast(ubyte[]) read(args[1])));
// newer api, simpler but less control
auto img = readPng(`x.png`);
auto img2 = readPng(`y.png`);
window.redrawOpenGlScene = delegate() {
auto painter = window.draw();
painter.clear();
painter.drawImage(Point(10, 10),
Image.fromMemoryImage(img2));
painter.drawImage(Point(10, 10),
Image.fromMemoryImage(img));
};
//displayImage(Image.fromMemoryImage(img), window);
window.eventLoop(50, // set a 50 ms timer pulls
// This runs once per timer pulse
delegate () {
//auto painter = window.draw();
//painter.clear();
//painter.drawImage(Point(10, 10),
Image.fromMemoryImage(img2));
//painter.drawImage(Point(10, 10),
Image.fromMemoryImage(img));
window.redrawOpenGlSceneNow();
},
delegate (KeyEvent event) {
},
delegate (MouseEvent event) {
}
);
If so, I can use gamehelpers.d to do the drawing of the images?
Thanks.
adamdruppe: Drawing scaled image
I found your git hub and tried simpledisplay and png. I had virtually no problems getting them working from the get go! Thanks for your hard work!!! You deserve a cookie, or a million bucks! I'm curious about how to draw a scaled image. I would like to have a "global" scale for my image drawing. Is there a way to apply a global transform efficiently?(not all image drawing though, just some). Also, png.d doesn't seem to work with alpha channel? I did a quick "alpha" search and simpledisplay.d says it doesn't work with alpha yet, except for openGL. How hard would this be to add? Obviously it requires composting the underlying bits. I will be working on a buffer for all window drawing, one large non-alpha bitmap that I draw everything to, hence it should be somewhat fast to compose. Which also leads me to, how to draw one image on to another? Basically I want to setup a sort of triple buffer(if necessary, or just single) sprite rendering engine(well, not really but it's equivalent to it). Is simple display and png capable of doing this without too much trouble?
