Re: Qt Creator and D
Manu wrote: I see, I didn't know VS was capable of that, but it doesn't sound very useful for large projects which take a lot of time to compile (which I'm sure is important to you folks at Remedy). Actually, it's about a zillion times MORE useful for large projects. If the project is big, takes time to reboot/restart, and particularly in games where you might need to run to a particular part of a level and perform some bunch of actions to test the thing you're trying to debug in the first place. Yes, I understand and agree. I made a typo. I meant to say: ..but it **does** sound very useful for large projects.. Fair enough, but it's weird I should have to. Basic productivity tools like that should surely be known by users of the tools... I'll just go and continue to assume that Visual Studio is still the only viable option on any platform :P Well, again, this isn't my area of experience. Professionally, I spend most my time in Kate/Inkscape/Gimp/Krita/Blender working on front-end web development graphics art. I have a long history of personal Direct3D/OpenGL projects and game logic, but in recent years that has been in C# and D (and some Nimrod), and It's been months since I've really had time to spend on anything there. That said, based on other's responses so far, my bet is that no Linux has these features you need, yet. So your assumptions about VS are probably correct. Mmmm, a concept that I've always found completely amazing actually. How is it that Linux - truly an OS for developers (certainly not for end-users) - This I actually disagree with that on a couple of levels. First, edit and continue is really only a absolute necessity for the AAA game industry (and some others).. since the ability to make changes without having to re-navigate the game to the area being effected is a crucial time saver. Linux hasn't really been a consumer platform before Android, and Android most games (especially in the earlier days) a simple enough that doesn't matter as much. Not to mention you can develop Android apps on non-Linux platforms just fine. So Linux hasn't really *needed* the ability to edit-and-continue until just now, when Android-based systems are becoming more powerful, and Valve is planning it's migration to Linux. Any company assessing the development cost of implementing the features into the tool-chains probably came to the conclusion it wasn't worth the effort. Second, Linux is quickly becoming a platform that's fully fit for end-users. I've installed Gnome Unity systems on my friends and family's computers, and for the most part they where very comfortable with the overall experience - going so far as to praise it as an upgrade in the cases where XP SP3 ate all their outdated computer's ram, and Linux did not. New distro's like Elementary OS present a very balanced and user-friendly desktop environment as well. Linux can also be very pretty and feature-rich, and, as a geek, I like the available choice in DEs Linux offers rather than being stuck with the sometimes unsavory advancements Windows makes in their design (i'm looking at you, Windows 8). Here is a screenshot of my computer: http://reign-studios.com/screenshots/arch-linux-screenshot.png I would have a hard time taking you seriously if you claim that isn't a rather pretty environment ;-) And for features, I have a multi-monitor/multi-resolution AMD Catalyst setup with a HD 7850 (a worse-case scenario for X11 drivers), and what's funny is that the art tools I use (Blender, Krita, MyPaint, Inkscape) actually run much faster on Linux than Windows (mostly because it's their target platform). KDE works great with AMD Tear-free desktop, so no vsync or lags. So I am very happy with Linux as a platform in general. There are still horror stories to be sure, but I think the biggest hurdle Linux faces today is simply the fact that it doesn't run Windows software or come pre-installed on laptops at Walmart.. (the corner cases exist because there aren't enough consumers worth supporting).. It will take a massive amount of advertising to sell Linux as a consumer alternative to Mac and Windows (and it will require being sold like Mac, where the OS is sold with sleek hardware that's drivers functions well with it). So far, only Google has been able to accomplish this, but hopefully Valve inadvertently helps Linux Desktop adoption as well by encouraging it as a gaming platform.
Re: Qt Creator and D
Manu wrote: It's certainly missed in my professional environment, but even outside that, it's still super handy and saves a lot of time. Particularly if you are in the habit of using it. Do you remember when you first got a mouse with a mouse wheel? You thought it was kinda cool, but I'll bet you didn't use it that much... you weren't in the habit of it. Have you tried to use a mouse without a mouse wheel recently? ... it's like that. Yes, I agree. My point wasn't that it isn't a convenience, only that linux tech companies with the ability to implement it probably haven't seen it as a worth-while effort (financially speaking) in the past, due to it not effecting their development practices as much as it may effects other industries (like major game creators). I hope, as I'm sure you do, that, due to Valve's interest in Linux, better debugging features will be seen as more of a priority. It will be a brighter day for Linux when engine designers of AAA game companies don't have anything to complain about when it comes to developing on Linux ;) Linux UI still feels largely like a facade to me. If ANYTHING goes wrong, you are back at square 1, if you're not an expert, you probably can't fix it. I recommend trying Elementary OS sometime (also, keep an eye on Manjaro). There are surely more automatic self-correcting feature on Windows, but Linux is getting better here I think. There has simply been more man-hours put into consumer-level features on Windows. I still think the biggest problem by far is that only an expert can fix it when anything goes wrong. And things *always* go wrong. I think you may be exaggerating a bit. I've never had any outstanding issues with distro's like Unbuntu on my machine, but then, it's subject a lot to the quality of your drivers, which sometimes get neglected a bit due to linux's lack of popularity in the desktop consumer space. I've had good success installing on Intel laptops, for instance, and bad experience installing on AMD laptops. But I think you'd find the same was probably true (or worse) with Mac. Which is why I mentioned the only way to sell Linux would be to put it in a fancy box and paint it's face with some expensive advertising (just like Mac and Sony do with BSD, only someone needs to do it more openly). I do agree, there are some areas Linux needs more time to bake, the Display Server is a good example (and PulseAudio), also things like more user-friendly Software Centers. But projects like Wayland, Gnome, Ubuntu, and Elementary are doing good work, and there are some good improvements on the way in the next year or two I think.
Re: Qt Creator and D
Manu wrote: I was fairly impressed with kdevelop upon recent impressions last weekend. Does it support incremental linking and edit-and-continue? (or is there ANY other compiler+IDE out there that does?) If it does, I'll look at it very very seriously. I'm not sure what you mean by edit-and-continue. I don't know if it does incremental linking, but I thought that sort of thing was more of a compiler/build-system feature, and IDK enough about GCC/Clang or CMake (what KDev is designed around) to know about it's features there. The only language I know for a fact has that built-in is Nimrod. I only work on one C++ project, so I am in no way an expert on the language or it's tools. I'm also fairly new to KDevelop, so I'm not the person to question here. By comparable to VS in many ways, I was referring to KDevelop's debugging, intellisense, code refactoring, syntax highlighting, general interface, and project/session management. All of which I've found to be roughly on-par with Visual Studios in my experience (granted I've barely used VS 2012 2013 is out soon).
Re: Qt Creator and D
Manu wrote: Edit-and-continue is what MS calls the obvious extension from incremental linking where you can re-link your exe while it's running and paused in a debugger, and then continue debugging the current process with the new exe after it links your code changes. it's one of visual studio's most valuable tools. I see, I didn't know VS was capable of that, but it doesn't sound very useful for large projects which take a lot of time to compile (which I'm sure is important to you folks at Remedy). I figured it was something along those lines though, so I tested editing a file while stopped on a breakpoint, and then running it and it didn't work. It's possible there's some switch i needed to hit, or that it would work with Clang/LLDB, but I doubt it (don't quote me on that though, you should ask the KDE folks). It requires support from various stages in the pipeline and gui, but it's been available for a decade from MS. Surely someone else has bothered to copy it? (assuming it was invented by MS?) I wouldn't know. You'll probably get a lot more information on what's available from asking the GCC, LLVM, and KDevelop IRCs. Debugging is the most important feature an IDE offers by far, and it's only half-implemented if it doesn't support edit-and-continue. Everything else looked good to me in kdevelop. I'll definitely give it a bit more time. Sadly there seems to be no push for D in kdevelop though :( Make sure to ask someone more informed than me before you write it off, but I'm guessing this is an area Linux dev tools are lacking in compared to Windows. In Gabe Newell's recent talk at LinuxCon, he mentioned Valve is interested in make Linux a more friendly environment for game developers. To that end, they're working on two different C/C++ debuggers (one for LLVM, I forget the other) and I'm guessing they wouldn't feel the need to do that unless they where unhappy with the current situation compared to what developers expect from Windows. Hopefully their efforts are fruitful in the near future. I've been using Linux and FOSS tools for nearly two years now, and I'm surprised I'd never heard about KDevelope until only a few months ago. It's a great IDE with a lot of nice features (even has Sublime-style text overview) and I hope D gets more attention from the KDev/Kate teams in the future.
Re: Qt Creator and D
On Friday, 20 September 2013 at 04:53:18 UTC, F i L wrote: but it doesn't sound very useful for large projects ... but it **does** sound very useful..
Re: Qt Creator and D
Somewhat related. I use Kate (for D web development) and occasionally KDevelop (for C/C++ stuff). I only started using these when I switched from Gnome to KDE 6 months ago, but I was very impressed and now they're my favorite editors (KDevelop can even challenge Visual Studios for C/C++ dev in many ways). I would love to see more support for both these editors with D. DCD looks cool, but it's a bit complicate to get working, so I've held off from trying it.
Re: Improved Phobos dox
Andrei Alexandrescu wrote: Of course better designs are welcome. One possibility is an incremental search box. Best solution, IMO, would be using a categorized jump-list on the left that scrolls separately from the actual documentation (or each item could have it's own page). That way you get and overview at a glance of everything in the module, regardless of where you are. Similar to how MSDN works.
Re: Template functions, can we make it more simple?
monarch_dodra wrote: Regardless of the existing merits, that would be a (massive) breaking change, and as mentioned, it brings nothing we couldn't do before... Sure, but not if you do it like my second example: auto func(auto a, auto b) // like C++14 That doesn't break anything, right? Anytime I write the body of a function that doesn't use one of its args, I keep the arg name empty. This implicitly documents that the arg is unused. Many people do this in C++ too, since msvc will flag you for not doing it anyways. So your answer your question: who's hand-writing a bunch of functions with nameless params in real D code: Lot's of people, including in Phobos. Fair enough. However, using 'auto' like above would allow cleaner syntax without getting in your way I think.
Re: Template functions, can we make it more simple?
monarch_dodra wrote: I'm not sure auto is the best choice of keywords, given potential clashes with auto ref: What if you want to pass a by ref? auto func(auto ref a, auto ref b) ? auto func(ref auto a, ref auto b) ? What if you want to pass them by *auto* ref? auto func(auto auto ref a, auto auto ref b) ? auto func(auto ref auto a, auto ref auto b) ? At this point, I'd really prefer just seeing classic template syntax... Okay, so I mostly agree with this. I guess adding this change would mostly likely require a breaking change elsewhere, and I can see the merits of not doing anything like that for good while. Thanks for being so convincing.
Re: Template functions, can we make it more simple?
I've brought this up on here awhile ago, and many people seemed to be against it. Which I don't agree with, since the ambiguities it creates are easily addressed (from a design perspective at least) and only exist so that C-style code is usable within D. It could work like: auto func(a, b) // auto func(A, B)(A a, B b) auto func(int a, b) // auto func(B)(int a, B b) auto func(int ?)// C-style: auto func(int) Or... auto func(auto a, auto b) // like C++14 I mean honestly, who's hand-writing a bunch of functions with nameless params in real D code? Sure it's used for linking to C, which is semi-common, but I think having the much cleaner syntax available to actual D code makes more sense that not having it solely for linking-to-C-in-familiar-C-style reasons.
Re: GDC D2 port status
Awesome! Would be great to see on the official Arch repos! :)
Re: Automatic typing
Steven Schveighoffer wrote: There are very good reasons not to do this, even if possible. Especially if the type can change. +1 This sort of inference can only lead to problems down the line, IMO.
Re: Reviving BulletD -- again
I know Bullet is the most noteworthy open-source physics library, but if you intent is to have a D-style physics lib for games/apps you might have a lot more success porting a C# physics engine like Jitter (http://jitter-physics.com/wordpress/) over to D first (then possibly adapt some stuff from Bullet into the code once it's stable). Porting a C# codebase to D should be much less of a struggle. We use Jitter in our C# game libs, and in some cases we've experienced it even beating Bullet in terms of runtime performance in some test cases (granted I don't know near as much about performance tuning in Bullet).
Re: dmd 2.063 beta 5
Leandro Lucarella wrote: That's completely FALSE. You might need some bugfixes! That view of if you want to be up to date you have to be willing to update a lot of code is really hurting D's stability. Evolution was never pain-free. The idea that D can thrive without adapting to it's changing environment will really hurt D's popularity now and in the future. Isn't the feature you folks are talking about technically a bug-fix? IMO it's better to use an older compiler if you really need your work-arounds to function (granted there is proper docs), and let the rest of people adapt with the language.
Re: DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans
Good talk, I've been waiting for this one all week. I know this was more a talk about interlinking C++ D when you have too, but it's interesting to note that Manu's biggest problem appears to be that his engine is written in C++ not D :)
Re: DConf 2013 on twitter
Excited to see the videos when they come out!
Re: We have completed our GSoC 2013 application
Brad Roberts wrote: In what way would this differ from the normal every day experience of hey, I'm going to work on X, could I ask for some help with the design of it? Celebration is good for the community.
Re: Mono-D v0.5.1.2 - Completion/Parameter insight improvements
alex wrote: Do you know a relatively consistent way of building MD 4.0 from scratch and having it 'installed' on one's machine, so with a launcher on the desktop? I don't know, but MonoDevelop 4.0 was just on the Arch Repos yesterday :) Gotta hand it to the MD devs, they really did an excellent job with MD 4.0 The UI is slick and straight-forward The C# code-completion is much better The new Sublime-inspired colors are completely sexy And overall, the performance feels improved in every way. Mono-D is running good so far! Thanks for your work.
Re: Registration now open on dconf.org
The line-up looks great! Unfortunately I cannot attend :( Everyone's talks looks awesome. Looks like it will be a great few days, have fun folks! (and please record it for us unlucky ones :)
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
alex wrote: http://i.imgur.com/3i5R4Mn.png?1 A first shot - I guess in cases of having template parameters, stuff should get 'expanded' to the final type, right? Well then I still have to work on it. Anyway it also works for template mixins and mixin statements. You just move the caret into a mixin, wait half a sec and then get the evaluated string displayed in a halfway good style. Ah, regarding the style..I also have to optimize it again - never touched any 'pretty printing' of entire ASTs before ;) Now that's impressive. Can't wait to see exactly what will come of the expression evaluation :D
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
alex wrote:
Yeah I just named it Expression evaluation - dunno why, just
thought that it could be used in a more general way than 'only'
for mixin insight.
Should I do an extra input box where you could type in
expressions and other things that could be evaluated? Just
thinking of a prototype of an interactive D script console or
so.. :)
That sounds very useful. It would be awesome if you could
evaluate the returned value of functions that already exist in
your program, or (like your picture shows) write simple test
functions to evaluate. Of course not all functions will work, but
It would be great in some areas. So, just to be clear, say you
have the following function in your project:
int foo(int x, int y)
{
return x * y + 5;
}
Then in the expression command line, you just type:
foo(1, 2)
Hit Enter, and you get a message: 7. You could also write
larger test functions in the Expression Evaluation body (like in
your screenshot) which could do more complicated stuff (still
limited of course).
---
You just gave me an awesome idea though. I know this would be a
ton of work (I'm not making a feature request here), but how
realistic would it be with your system to do a side-by-side
expression evaluation with example data (where applicable)? :D
Meaning, imagine your screen looks like:
CODE | EXAMPLE RESULTS
|
int foo(int x, int y) | params: (2, 3) // editable
{ |
return x * y + 5 | returns: 11// not-editable
} |
|
That would simply amazing! I don't expect you to make that, lol,
only want to know if it's possible (or foreseeable) with your
expression evaluation engine. Is it?
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
alex wrote: ... Oh, ps. On a completely unrelated note, Just wanted to say that the new Active Profiler display is completely awesome. Thanks!
Re: Error: class myClass.myClass() is used as a type
F i L wrote:
class myClass() {
this() { ... }
}
Whoops, forgot to remove the '()' after 'myClass'. As others have
pointed out, that will make 'myClass' a template-class.
Re: Error: class myClass.myClass() is used as a type
rsk82 wrote:
What's wrong here ?
module myClass (myclass.d);
class myClass() {
this() { ... }
}
and main app (main.d):
import myclass;
void main() {
myClass my_instance = new myClass();
}
then compile with:
$ dmd main.d myclass.d
or:
$ dmd main myclass
or:
$ rdmd main
ps. Module names should be lowercase (see docs), and you can
safely use 'void' for main()
Re: Do we want functions to act as properties, or merely omit parens for ufcs/chaining?
why in the hell would you want: writeln = lolwut; to compile in the first place?
Re: Mono-D v0.4.9.5 - Infinite analysis fix + Mixin analysis improvement
alex wrote: Morning D folks, Implemented some new features concerning pre-compile time mixin analysis and expression evaluation: ... The new update seems very fast and stable. Trying the new features, Thanks!
Re: Memory Safety without a GC or Ref Counting
On Friday, 25 January 2013 at 11:28:16 UTC, TommiT wrote:
On Monday, 21 January 2013 at 17:37:38 UTC, F i L wrote:
type Foo
{
var bar = 0
}
func main
{
ref f : Foo
ref b : int
scope
{
var foo = Foo # allocates Foo
f = foo # f points to foo
f.bar = 1 # foo.bar = 1
b = f.bar# b points to foo.bar
b = 3 # foo.bar = 3
# auto 'clean up code' at end of scope:
#
# Memory.delete(foo)
# f = null
#
}
f.bar = 4 # ERROR: f is null
I think there should be also b = null in the implicit 'auto
clean up' phase.
b didn't need to be assigned to null because the compiler could
determine it wasn't being directly accessed after that scope (it
was assigned to a new var first). It was intentionally left out
to illustrate how the compiler could optimize special cases like
that. I wrote that in my original post a bit after that code.
I think it's good to note whether errors are compilation errors
or runtime errors. I assume f.bar = 4 in the end there would be
a compilation error?
If the compiler could determine that a ref was being used
directly after being cleaned up, then yes, the compiler could
throw an error. But that can't happen in every case, so when it
can't you'll get a runtime error. Sorry I wasn't clear about that.
On Friday, 25 January 2013 at 02:12:56 UTC, F i L wrote:
var nums = int[] # DynamicArray(int)
ref a, b : int
func main
{
nums += 1 # allocate
nums += 2 # allocate
nums += 3 # allocate
a = nums[2] # nums.=(2, a)
b = a # nums.=(2, b)
What if we now (after the code snippet above) write:
nums += 4
And nums has run out of room in its place in the heap and needs
to re-allocate its data (4 ints now). I guess that would mean
that the call += should nullify all refs pointing to nums (a
and b). If we now write:
a = -3
...that can't be a compilation error. Because it's not known at
compile-time whether or not nums += 4 forces a re-allocation.
Wouldn't this mean then, that all accesses through references
would require a runtime penalty for checking whether the ref is
null or not?
The specific code you're talking about is a demonstration of an
area where the compiler can't (like you said) determine at
compile-time the clean-up code, and therefor has to use a runtime
approach to nullifying references.
The issue you raise isn't really a problem though. If the memory
gets rearranged then the runtime could inform the DynamicArray,
and it, in turn, could reassign those refs to the new memory
address.
The idea here is that if you're writing something complex like a
Container, you may need to use the unmanaged 'ptr' type to get
the job done. However, such containers could still make safety
guarantees to their users. So if the standard libs provided
enough basic building blocks, and the compiler supported advanced
meta-programming features (like in D), then programmers would
rarely, if ever, need to touch a 'ptr' to make applications.
Re: Memory Safety without a GC or Ref Counting
On Friday, 25 January 2013 at 13:14:43 UTC, TommiT wrote:
What if we re-assign a ref variable to another (or same)
element of a DynamicArray:
var nums = int[] # DynamicArray(int)
ref foo : int
nums += 1
nums += 2
foo = nums[0] # nums.=(0, foo)
foo = 42
foo = nums[1] # nums.=(1, foo)
Given the definition of DynamicArray's operator =:
func = (index, r:ref T)
{
refs[index] += r
}
...it would mean that refs would hold two instances foo (at
different indices).
Yeah I caught that bug after I originally posted the code as
well. I have a solution, but it's ugly, so I'm trying to find a
better one. Thanks for the input! I will let you know if I come
up with anything elegant.
Re: Memory Safety without a GC or Ref Counting
H. S. Teoh wrote:
The problem is that quite often, the compiler will not be able
to prove
much about the data structure, esp. when you have non-trivial
manipulation of pointers -- it requires solving the halting
problem to
achieve that level of analysis on arbitrary code -- so it will
probably
fall back to the GC quite often, depending on what the code
does.
Well I misspoke on exactly what I meant by falling back to
ref-counting.. I actually don't think you'd need anything like a
typical GC's or Ref-counting system, since this memory-model is
so rigid it gives a bit more guarantee on when something is
allocated and deleted, therefor when references need to be
cleaned can be a bit more optimized (at least I think).
For any local variables, most of the cleanup code can be
statically injected (like I illustrated above). Really the only
area you need to dynamically track and nullify references is
for dynamically allocating objects, like DynamicArrays. For them
we can fall-back on a sort of Garbage Collection, however I
think it can be better (doesn't need cyclic detection, is
deterministic, etc). Let me illustrate...
In the compiler, our DynamicArray type might look like:
type DynamicArray(T) # template type
{
ptr pointer : T
var length : type(ptr)
ptr refs = MemoryPool(ref T[])
func = (index, r:ref T)
{
refs[index] += r
}
func -= (item)
{
...remove item...
var rfs = refs[getIndex(item)]
each r in rfs
{
if r == item
{
r = null
}
}
refs -= rfs
}
}
Basically, syntax like:
var foos = Foo[]
is just sugar for:
var foos = DynamicArray(Foo)
You'll notice that the DynamicArray type has a reference 'refs'
to a MemoryPool of type 'ref T[]'. This MemoryPool object would
probably be shared across multiple/all DynamicArrays for
optimization, but for now just think of it as a simple
dynamic-array-of-arrays itself.
The functions: '=' '-=' are operators, and happen whenever a
variable is referenced to an item, and when an item is removed,
respectively. To illustrate:
var nums = int[] # DynamicArray(int)
ref a, b : int
func main
{
nums += 1 # allocate
nums += 2 # allocate
nums += 3 # allocate
a = nums[2] # nums.=(2, a)
b = a # nums.=(2, b)
each i in nums
{
if runtime_condition
{
nums -= i # nums.-=(i)
}
}
}
So while this would search through a list of refs every time an
item was removed, it wouldn't have to do any complex cyclic
detection, or other such things. The MemoryPools could be a
universally managed heap of references that each DynamicArray
only held a slice-reference to, therefor allocating arrays would
still be cheap.
That's more of what I meant by falling back to Ref-counting
(more like reverse-referencing) type systems in cases where you
need them. Combined with all the optimizations that could occur
with local variables, I think a system like this could have a lot
of potential as an alternative to a thread-locking GC. Still... I
have this feeling like there's some obvious flaw in the design I
just can't see yet...
Re: Mono-D v0.4.9 - Rough formatting capability
Thanks Alex, even though I don't use auto-formatting (I never did like that).
Memory Safety without a GC or Ref Counting
So I've been thinking about this problem off and on for awhile,
and I think I have a rather simple solution. I highly doubt I'm
the first to think of it, but haven't found any info about a
similar idea on the net. So in the interest of science I'm
posting it here so anyone interested can attempt to poke holes in
the idea, which you folks have been so good at in the past.
This isn't really D related, but I usually like the feedback I
get from this community, plus, if there's any value in the idea,
maybe it would be a worth while discussion for future directions
D might make use of.
I'll be illustrating with Pseudo-code. The basic idea spawns from
conceptually separating variables as either memory owners or
memory references. Basically, the pseudo-code has three types:
var - Memory Owner, never null, deleted at end of scope**
ref - Memory Reference, can't own memory
ptr - Unsafe manually managed memory pointer (like C pointers)
So, 'ptr's aside for now, 'var's would be the only way to
allocate memory, and memory is automatically allocated to them at
their definition**. Vars would be deleted at the end of their
scope (or when they're removed from dynamic-arrays, etc) unless
they're returned, in which case they're injected into the
callers scope, and deleted at the end of that scope. Without too
much lengthy explanation, here's some code:
type Foo
{
var bar = 0
}
func main
{
ref f : Foo
ref b : int
scope
{
var foo = Foo # allocates Foo
f = foo # f points to foo
f.bar = 1 # foo.bar = 1
b = f.bar# b points to foo.bar
b = 3 # foo.bar = 3
# auto 'clean up code' at end of scope:
#
# Memory.delete(foo)
# f = null
#
}
f.bar = 4 # ERROR: f is null
var n = 6
b = n
b = 7 # n = 7
# No clean-up code needed, 'n' is stack-allocated
#
# Also, notice we didn't need to set 'b' to 'null' at
# the end of the scope, since it wasn't accessed
# directly after the end of the scope.
}
So this is sort of like ref-counted scopes (smart scopes), except
the compiler has a higher degree of guarantee on the lifetime of
memory, and there's a lot of static analysis that can happen to
optimize the clean up code (like how we didn't need to assign 'b'
to null in the example above). All ref counting would be done
through static-analysis at compile-time, and injected by the
compiler, so it wouldn't have the runtime overhead of
ref-counting, nor would there be a need for weak references
since references are guaranteed to never own memory.
There's more to it of course. For instance, in order to have
expanding memory, you'd need the concepts of a dynamic-array and
type inheritance. You'd also need to not clean up memory that was
returned... so...
type Foo
{
var name : text
init { name = Foo }
func write { Console.write(name) }
}
type Bar : Foo
{
init { name = Bar }
}
ref global_foo : Foo
func main
{
var foos = Foo[]
foos += Foo # allocation
foos += Foo # allocation
foos += Bar # allocation
foos[].write() # prints: 'Foo', 'Foo', 'Bar'
foos -= foos[1] # deallocation
foos[].write() # prints: 'Foo', 'Bar'
# ---
func getFoo
{
var f = Foo
f.name = Fip
return f
# no cleanup, since 'f' is returned
}
global_foo = getFoo()
global_foo.write() # prints: 'Fip'
# auto cleanup:
#
#Memory.delete(foos)
#Memory.delete(global_foo)
#global_foo = null
#
}
Okay, so with that you could have global var arrays, and assign
global refs to function return values, etc. If you need extra
control, there's also 'ptr' types, which would require manual
clean-up. However, 'ptr's would be automatically cleaned when the
program exist, so they would be safe to use for global references
which only sometimes needed to point to usable memory.
Anyways.. comments and criticisms would be great. Sorry this
isn't more D related. Like I said, I hope it does have value D
might make use of at some point.
Re: Memory Safety without a GC or Ref Counting
F i L wrote: [...code...] global_foo = getFoo() [...code...] Typo, that should have been: global_foo = getFoo() H. S. Teoh wrote: [...] because the concept has limitations: 1) It required code to be manually written to deal with owner pointers correctly (auto_ptr mostly made this automatic, but it is certainly NOT a drop-in replacement for pointers); I don't do a whole lot of C++, so I don't know a lot about their smart_ptr types, however, I doubt you could do anything like my idea in C++ (without a lot of extra syntax like you described) since it requires a lot of automatic per-scope bookkeeping I doubt C++ types alone could accomplish. 2) It can't deal with cyclic structures correctly; That's why there would be a 'ptr' type :) 3) It is still unsafe: you can have a dangling reference to owned memory, because the owner pointer goes out of scope and the memory gets deallocated, but there can still be references lingering around somewhere. This is why there would need to be a lot of magic happening in the compiler. When the compiler can't know, for sure, weather a reference that was assigned to a local-scope var is *still* referencing that var at the end of the scope (pretty common), then it asks before setting assigning to null. If the compiler can't determine, at all, which refs will be pointing to a particular local-var, it falls back to regular ref-counting (for the var in question). I've given it a bit of thought, and while runtime checks and even regular ref-counting wouldn't be too uncommon, due to it's var/ref design there would be a great many places where the compiler could optimize away all the runtime checks and you normally wouldn't have to deal with the cyclic-ref problem ref-counting memory-management usually bring to the table (granted ptr's aren't much better). Also, I can't remember exactly, but because var's are tied to scopes, I think there's more optimization that can happen with ref-counting because it happens at the scope level... more thoughts needed here though. One benefit of this I forgot to mention is that, like ref-counting, memory is deterministic (with optional late-collection). That wou Thanks for your feedback! Arne wrote: I haven´t found any hole or improvement suggestion yet, my only comment is, I`d really love to use a system like this. Me too! Let me know if you think of any flaws. Jacob Carlborg wrote: Seems a bit like ARC (Automatic Reference Counting) that Clang has implemented for Objective-C (and some C libraries on Mac OS X). The compiler automatically inserts calls to retain and release where appropriate. Interesting, I will have to look into that. Thanks for the info.
Re: Memory Safety without a GC or Ref Counting
F i L wrote: ... Also, I can't remember exactly, but because var's are tied to scopes, I think there's more optimization that can happen with ref-counting because it happens at the scope level... more thoughts needed here though. Ah right I remember. Since vars only ever get collected at the end of a scope, you don't need to check for zero-refs on every dereference, only at the end of the var's scope.
Re: D popularity
On Monday, 21 January 2013 at 20:48:22 UTC, Walter Bright wrote:
On 1/21/2013 12:31 PM, Rob T wrote:
I have to wonder if many of the features can be generalized
down into less
features without sacrificing anything.
Yeah, well, that's the major thing about any language design!
and on that note I hear the C++ community (at least one key
member) is proposing a:
auto add(auto a, auto b) {
return a + b;
}
pretty-template syntax! I wouldn't feel right if C++ had
something that elegant and D did not *wink* *wink* :-)
Re: DConf 2013 Call for Submissions: deadline on January 28
I have been playing around with UDAs recently and in combination with D's meta-programming they allow for some awesome stuff. I would love to see a presentation on that. I heard Ian mention doing a presentation on the challenges of porting D to ARM/Parallella which I think would a be very, very interesting talk to a great many people (myself included). Just ideas.
Phobos Members-Tuple function?
Is there a function in phobos which will return a Tuple of a
Type's members, for use in a foreach statement?
I need this for collecting info on all Type Members's User
Attributes. Currently, I have written a recursive function which
does this, but I'm looking for a more elegant solution.
Let's say I have an Ship Actor class:
class Ship : Actor
{
@Bind(Stage.update) void update()
{
// ...
}
@Bind(Canvas.draw) void draw()
{
// ...
}
}
and I want to iterator over all it's members.. and, in turn,
iterate over all their attributes. If I use
__traits(derivedMembers, Ship) it returns a Tuple of strings,
which I can't use with __traits(getAttributes, ..). So what are
my options here? Ideally, I'd like to be able to do this:
auto ship = new Ship;
enum mbrs = membersOf(Ship); // returns Tuple
foreach (m; mbrs)
{
enum atrs = __traits(getAttributes, m);
foreach (a; atrs)
{
if (is(a : Bind))
Engine.bindActors(ship, a.pattern);
}
}
Like I said, I've already accomplished this using recursion. I'm
just wondering if there's an easier way (like above). Also, if
recursive functions are required, I'd love to hear ideas on the
best way to write a general purpose recursive function for this
kind of thing.
Re: Phobos Members-Tuple function?
bearophile wrote: I have not fully understood the problem, but have you tried [__traits(getAttributes, m)] ? yes, that's not really relevant to my problem. 'm' in your example, can't be read at compile time, because __traits(derivedMembers, ..) returns a Tuple of strings, not Symbols. I can get the attributes of a specific member just fine, the problem is iterating over *all* members, then finding the attributes for each member. It's relatively easy to solve with recursion, I'm just trying to cover my tracks here and see if there's a better way I'm unaware of.
Re: Phobos Members-Tuple function?
Ali Çehreli wrote: The following program produces this output: [...code...] Awesome! Thanks, I wasn't expecting it to actually be as easy as that. I tried all sort of difference combinations with __traits(allMembers, ..) but it looks like I just needed to move it into the foreach loop itself. I wounder why there's a difference when assigning to an enum...
Re: Mono-D v0.4.8
Nice work, Alex, but something broke my GDB debugger support... :-\ I'm not sure if it's something specific to Arch Linux or not, so can anyone confirm that their Mono-D is work with GDB fine? Mine reports: warning: Could not load shared library symbols for linux-vdso.so.1.\nDo you need \set solib-search-path\ or \set sysroot\ [Thread debugging using libthread_db enabled] Using host libthread_db library \/usr/lib/libthread_db.so.1\.
Re: Exceptional coding style
sorry if this has already been posted, but Phoronix did an article on John Carmack's words as well, and the forum discussion has a bit of talk about D in it (specifically how it compares to C++). http://phoronix.com/forums/showthread.php?76719-John-Carmack-s-Comments-On-C-C#post306255
Re: core.runtime: loadLibrary and unloadLibrary?
On Friday, 11 January 2013 at 02:20:27 UTC, Walter Bright wrote: On 1/10/2013 2:42 AM, Jonathan M Davis wrote: C shared libraries are fine. It's D shared libraries that are the problem. I don't remember the details, but IIRC, among other things, you end up with multiple copies of the GC running. The runtime needs a variety of non-trivial tweaks to it order to fix those problems before shared D libraries become viable. This was fixed in D1 long ago. DLLs would use the Executable's gc instance. Wait.. this was a bit unclear, but it sounded like you just said D's DLL issues where fixed awhile ago.. Is D2 capable of correctly loading DLLs? What's the situation with Linux?
Re: small idea
Yes this has been requested a few times. I just want to point out that while I like the idea (seeing how well it works in C#), I also think it should be optionally how it is now. There are times when you want to pass and object as ref for optimization only, and aren't actually modifying the value (like Matrix Multiplication for example). In these cases, the way D works right now is nice, because it hides that detail from the end user. Still, I think 'ref'/'out' should be require at call-site by default, to avoid any gotchas. I also don't see any problem with UFCS really. I mean, using that syntax is pseudo-OOP and implies the first parameter might be modified in the function.
Re: D 1.076 and 2.061 release
dimsuz wrote: +1 for Arch. Have used almost everything Gentoo, Ubuntu, Debian, OpenSuse and ended up with Arch Linux. I am happy with it for almost two years now and wouldn't even consider switching to something else :) Same here. After making my way through the most popular Linux distros, I eventually braved setting up Arch.. and I'll never go back. For me, it's the best OS I've ever used.. granted you make it past the setup and aren't afraid to open a terminal. That's also it's biggest (only?) flaw. Hopefully Manjaro/CinnArch are successful in creating a more user-friendly arch-based distro for the casual user.
Re: Runtime code reloading in D, part 1
On Sunday, 30 December 2012 at 12:32:00 UTC, Benjamin Thaut wrote: An article about runtime code reloading in the context of game developement. A topic I'm currently working on in my spare time. I hope it holds some valuable information for everyone working with D. http://3d.benjamin-thaut.de/?p=25 Kind Regards Benjamin Thaut Awesome, thanks for the post. I've been playing around with this idea for awhile, and that article is immensely helpful. Proper .so/.dll support is very needed for this, and I hope something is happening on that front.
Re: Social comments integrated with dlang.org
Sönke Ludwig wrote: And frankly, in my experience such comments were immensely helpful in a number of cases on various online documentation sites (including MSDN and ...PHP). They are like an in-place stack overflow discussion that you don't have to search for, often with some real gems. I couldn't agree more. Half the time I find answers to questions in old forum conversations or similar user dialog. The new doc layout looks great, with lots of room for descriptions and examples per-item. User comments makes a lot of sense, and could help fill any gaps in the documentation itself. ps. I don't think it looks ugly or out of place at all, and I don't think it should be collapsed by default (it's less googlable that way).. just throwing that out there.
Re: Private default arguments?
Good idea, but honestly what we really need is a static foreach
Re: Social comments integrated with dlang.org
What do you think? It's great!
Re: Mono-D v0.4.5
On Monday, 24 December 2012 at 22:37:49 UTC, alex wrote: Hi everyone, I've just uploaded a new version of Mono-D. This time again several bug fixes, improvements..the usual stuff ;) For a changelog, see the first link to the project blog. Oh and merry Christmas to each of you - may there be a small social leftover besides the entire x-mas commerce we've got to experience during these days ;-D http://mono-d.alexanderbothe.com https://github.com/aBothe/Mono-D/issues https://github.com/aBothe/D_Parser/issues Great as always! Merry Christmas!
Re: ICE 0.1: a moddable shoot-em-up in D
On Thursday, 20 December 2012 at 18:41:13 UTC, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. There's still a lot of work to do (moddability is there but no user-friendly editor, no ship upgrading, need better sounds, bosses), but at least the game is playable. We're using a component-based entity system (where components behave as plain data), allowing various custom entities to be created without touching the code. The game is pretty slow on older PC's; this is not a D issue, but some code (graphics) is just written very inefficiently right now. It's getting better, though; D features made it easy to write tools to profile memory allocations and frame times; we can do stuff like find the slowest frames, break them down into zones to find out what took the most time, even find the allocations made during these frames. (I'd like to separate thisinto another project in future). See the full announcement here: http://icegame.nfshost.com/index.html Download the game: http://icegame.nfshost.com/pages/downloads.html Forums: http://iceforum.nfshost.com/ Comments/criticism welcome (I've worked on a few toy game projects, but this is the first one that actually had a release; there are likely many beginner errors). Awesome! Works perfect (without errors) on Arch Linux x86_64.
Re: D as a Unity3D language
On Wednesday, 19 December 2012 at 14:21:43 UTC, Joel Lamotte wrote: So I was thinking vaguely about future of game programming in my own career, how I would have used D if there was more tool and library support for my domain and other similar things and it hit me that if D was a language available in some specific game dev tools, it's popularity and availability would jump to the roof. I was wondering is either Andrei or Walter did try to contact Unity3D guys see if it would have been possible for them to have D as one of the possible scripting language? I know D could be used from the paid version of Unity, like C++ can be called from Unity3D scripts. However D as a scripting language for it would be very interesting at least on the educational point. What do you think? Joel Lamotte I doubt the Unity3D team will have much interest in adapting D to their engine, unfortunately. It just isn't cost effective, there's no real benefit over C# for what Unity makes use of (besides possibly getting rid of the Mono dependency). I'm pretty sure Unity also makes use of C#'s runtime reflection capabilities to dynamically bind to script events and properties. D is mostly just as capable as C# with runtime reflection (to my knowledge), but you have to build out structures manually, and it's much more difficult. A better idea would be to make a new Game Engine completely written in D, which also uses D for scripts. You'd still need to build runtime reflection structures for anything like Unity's editor, though. I was playing around with D the other day with a similar motive, but I never really came up with a solution on how to dynamically bind a delegate to a unknown type's function.
Re: Javascript bytecode
Without bytecode, the entire compiler becomes a dependency of a AOT/JIT compiled program.. not only does bytecode allow for faster on-site compilations, it also means half the compiler can be stripped away (so i'm told, i'm not claiming to be an expert here). I'm actually kinda surprised there hasn't been more of a AOT/JIT compiling push within the D community.. D's the best there is at code specialization, but half of that battle seems to be hardware specifics only really known on-site... like SIMD for example. I've been told many game companies compile against SIMD 3.1 because that's the base-line x64 instruction set. If you could query the hardware post-distribution (vs pre-distribution) without any performance loss or code complication (to the developer), that would be incredibly idea. (ps. I acknowledge that this would probably _require_ the full compiler, so there's probably not be to much value in a D-bytecode). The D compiler is small enough for distribution I think (only ~10mb compressed?), but the back-end license restricts it right?
Re: Get specific functions of unknown type at runtime?
Okay, thanks for the help folks.
Re: New newsgroup: digitalmars.D.ldc
On Sunday, 16 December 2012 at 10:11:37 UTC, Walter Bright wrote: For all things specific to LDC. Nice! Always wounder why there was a GDC forum and not an LDC one.
Get specific functions of unknown type at runtime?
My goal is this, to have an XML file:
!-- scene.xml --
scene
object class=Person event=greet/
/scene
and a D file:
module person;
import std.stdio;
class Person
{
void greet() {
writeln(hello);
}
}
and then another D file:
module main;
import person;
import std.xml;
import std.file;
static class Engine
{
static void delegate() event;
static void callEvent() { event(); }
}
void main() {
auto doc = new Document(read(scene.xml));
auto className = /* find class name in xml file */;
auto eventName = /* find event name in xml file */;
auto obj = Object.factory(className);
Engine.event = /* get 'eventName' void in 'obj' */;
for (/* some loop */) { Engine.callEvent(); }
}
So yeah, basically is is possible to create a general object,
then look at it's members at runtime? Through maybe a .classinfo
or something? Or is this level of runtime reflection simply not
supported in D (yet)? If so, what are my best alternative options
here?
Re: Get specific functions of unknown type at runtime?
@Adam D. Ruppe
Damn, I was afraid you where going to say to do something like
that. It doesn't really work for what I'm thinking about, but
thanks for confirming that my original code can't work.
I have an alternative in mind, but first, is there a possible way
for a Super class to ask about a derivative's members during
constructions? (I'm guessing not). Something like:
import std.stdio, std.traits;
class A
{
this() {
alias typeof(this) type;
static if (hasMember!(type, foo)) {
auto top = cast(type) this;
top.foo();
}
}
}
class B : A
{
void foo() { writeln(foobar); }
}
void main() {
auto b = new B(); // prints: 'foobar'
}
I assume there's no way (I can't get it to work), but I've heard
odd things about 'typeof(this)' before, I just can't remember
exactly what, so I figure it's worth asking about.
If not, I have an alternative way to accomplish what I want. It's
just not as ideal. I really wish D has partial classes, that
would be awesome.
@Jacob Carlborg
Thanks for the link.
Re: Moving towards D2 2.061 (and D1 1.076)
On Saturday, 15 December 2012 at 06:17:13 UTC, Walter Bright wrote: On 12/14/2012 6:26 PM, F i L wrote: Sorry if I missed this, but with User Defined Attributes be part of 2.61? Yes. Awesome! Can't wait :)
Re: Moving towards D2 2.061 (and D1 1.076)
Sorry if I missed this, but with User Defined Attributes be part of 2.61? Or is that still not ready?
Re: Getting rid of dynamic polymorphism and classes
Tommi wrote: If virtual method calls are really that fast to do, then I think the idiom in the code snippet of my first post is useless, and the idiom they represent in that video I linked to is actually pretty great. Virtual functions have other performance limitations, naming they can't be inlined. So small virtual calls do have a big impact if used often, especially (so I hear) on ARM processors which don't have as advanced branch-prediction machinery as x86 (again, I'm just repeating what I've heard before).
Re: Mono-D v0.4.1.9
On Thursday, 8 November 2012 at 17:50:35 UTC, alex wrote: Between all these discussions about new D language features :) A new version just released. For any info, see http://mono-d.alexanderbothe.com Issues go here: https://github.com/aBothe/Mono-D/issues If you've downloaded MonoDevelop from download.monodevelop.com, please download the latest addin directly from http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.9_MD3.0.4.7.mpack Project version declarations looks great, thanks!
Re: Getting rid of dynamic polymorphism and classes
That's essentially how Go is designed:
type Shape interface {
draw()
}
type Circle struct { ... }
type Square struct { ... }
func (c *Circle) draw() { ... }
func (s *Square) draw() { ... }
func main() {
var shape Shape
var circle Circle
var square Square
shape = circle
shape.draw() // circle.draw()
shape = square
shape.draw() // square.draw()
}
Re: [ ArgumentList ] vs. @( ArgumentList )
@(attribute) looks prettier to me, and with the other pros I think it's the clear winner. I always though C#'s [Attribute] syntax didn't make a lot of sense. I'm also for: @attr1 @attr2 int i; type syntax if that was being discussed previously (someone mentioned it). It would be very consistent with what's already there. Congrats on Attributes, BTW! Great news :)
Re: Mono-D v0.4.1.7
alex wrote: Fixed it. Was something with manual SO prevention and a missing declaration conditition implementation..but now it works definitely, see: https://github.com/aBothe/Mono-D/issues/161 I've put it in Mono-D v0.4.1.7 Good to hear! Nice work, and thanks.
Re: Very simple SIMD programming
Manu wrote:
One thing I can think of that would really improve simd (and
not only simd)
would be a way to define compound operators.
If the library could detect/hook sequences of operations and
implement them
more efficiently as a compound, that would make some very
powerful
optimisations available.
Simple example:
T opCompound(string seq)(T a, T b, T c) if(seq == * +) {
return
_madd(a, b, c); }
T opCompound(string seq)(T a, T b, T c) if(seq == + *) {
return
_madd(b, c, a); }
I thought about that before and it might be nice to have that
level of control in the language, but ultimately, like jerro
said, I think it would be better suited for the compiler's
backend optimization. Unfortunately I don't think more complex
patterns, such as Matrix multiplications, are found and optimized
by GCC/LLVM... I could be wrong, but these are area where my
hand-tuned code always outperforms basic math code.
I think having that in the back-end makes a lot of sense, because
your code is easier to read and understand, without sacrificing
performance. Plus, it would be difficult to map a sequence as
complex as matrix multiplication to a single compound operator.
That being said, I do think something similar would be useful in
general:
struct Vector
{
...
static float distance(Vector a, Vector b) {...}
static float distanceSquared(Vector a, Vector b) {...}
float opSequence(string funcs...)(Vector a, Vector b)
if (funcs[0] == Math.sqrt
funcs[1] == Vector.distance)
{
return distanceSquared(a, b);
}
}
void main()
{
auto a = Vector.random( ... );
auto b = Vector.random( ... );
// Below is turned into a 'distanceSquared()' call
float dis = Math.sqrt(Vector.distance(a, b));
}
Since distance requires a 'Math.sqrt()', this pseudo-code could
avoid the operation entirely by calling 'distanceSquared()' even
if the programmer is a noob and doesn't know to do it explicitly.
Re: Mono-D v0.4.1.6
On Sunday, 21 October 2012 at 17:37:17 UTC, alex wrote:
This behaviour is terribly inreproducable..Sometimes it tends
to not have any plan of what I'm typing, but mostly (and quite
only) it actually knows what I want to have in my completion
list..
If you're able to figure out a good way of having it that
buggy, please tell me.
In the mean time, if you want to switch to older versions, just
check out
http://mono-d.alexanderbothe.com/repo
Thanks Alex. As far as reproducing the error, all I have to do is
create a new test project, and change the 'main.d' file to look
like:
module main;
class Test
{
int x = 10;
}
void main()
{
auto t = new Test();
t... // wrong options, you know the situation
}
I'll try and find a situation where it works, and report before I
Switch back to an older version.
Re: [RFC] ColorD
Robik wrote:
Hello,
I would like to introduce ColorD, small library that allows to
simply manipulate console output colors, both on Windows and
Posix operating systems. It also supports font styles such as
underline and strikethrough(Posix feature only).
It might be nice to have a solution which works better with
native writeln(), aka, something like:
import std.stdio, colord;
void main() {
writeln(Colors.Red, Foo Bar, Colors.Reset);
}
Re: Mono-D v0.4.1.6
On Saturday, 20 October 2012 at 22:12:57 UTC, alex wrote: Aaaand Mono-D 0.4.1.6 released.. please check out http://mono-d.alexanderbothe.com/?p=645 .. this time, I'm too lazy to enum any details but one larger improvement: The new way of renaming symbols. It can be done a bit more comfortable via relatively nice designed dialog boxes now - I even appended a screenshot to the post :) hmmm... with the latest update (and possibly the previous one, I hadn't updated since the first post of this thread), the intellisense completely fails. Every symbol's intellisense options read: alingof init mangleof sizeof stringof The symbols themselves show up fine, but any class/struct members don't show up.
Re: Mono-D v0.4.1.6
On Sunday, 21 October 2012 at 01:14:58 UTC, alex wrote: On Saturday, 20 October 2012 at 23:49:03 UTC, F i L wrote: The symbols themselves show up fine, but any class/struct members don't show up. I have no idea why it's suddenly working again. I've uploaded a new http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.6_MD3.0.4.7.mpack That didn't change anything on my end. Still the same intellisense options after the install. BTW, by installing from the file, will that stop me from receiving online updates?
Re: Mono-D v0.4.1.6
On Sunday, 21 October 2012 at 01:14:58 UTC, alex wrote: On Saturday, 20 October 2012 at 23:49:03 UTC, F i L wrote: The symbols themselves show up fine, but any class/struct members don't show up. I have no idea why it's suddenly working again. I've uploaded a new http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.6_MD3.0.4.7.mpack That didn't change anything on my end. Still the same intellisense options after the install. BTW, by installing from the file, will that stop me from receiving online updates?
Re: 48 hour game jam
Trying to build in Linux, but having problems. I follow the steps from github wiki How to build under Windows, except I run 'Fuji/create_project.sh' instead of '.bat'... now I'm a bit confused as to what steps to take. Running 'Fuji/make' has errors, and running 'Stache/make_project.sh' - 'make' gives me: make[1]: *** No targets. Stop. make: *** [Stache] Error 2 which I assume is because Fuji isn't built (?). Help please! Nice screenshot, btw :)
Re: 48 hour game jam
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote: We did a 48hr game jam at work this past weekend. We decided to do our entry in D, to further prove that D was a viable and productive solution for real-world game dev. Here's our entry, for those interested. It has only been built/tested in Windows using VS2010, but it should theoretically work on Linux and consoles as well (but the build scripts aren't setup to do it automatically). If there is interest, I will create the build scripts, and test on Linux. https://github.com/RemedyGameJam/stache/wiki Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)?
Re: core.simd woes
David Nadlinger wrote: By the way, I just committed a patch to auto-generate GCC-LLVM intrinsic mappings to LDC – thanks, Jernej! –, which would mean that you could in theory use the GDC code path for LDC as well. Your awesome, David!
Re: Mono-D v0.4.1.5 Fixes
On Saturday, 13 October 2012 at 13:17:52 UTC, alex wrote: Hi everyone, Just released a new Mono-D version that features couple of bigger sort of fixes.. The download: http://mono-d.alexanderbothe.com/repo/MonoDevelop.D_0.4.1.5_MD3.0.4.7.mpack The changelog: http://mono-d.alexanderbothe.com/?p=634 The blog: http://mono-d.alexanderbothe.com The issues: https://github.com/aBothe/Mono-D/issues Cheers, Alex Nice work, as always, Alex.
Re: core.simd woes
Manu wrote: actually, no I won't, I'm doing a 48 hour game jam (which I'll probably write in D too), but I'll do it soon! ;) Nice :) For a competition or casual? I would love to see what you come up with. My brother and I released our second game (this time written with our own game-engine) awhile back: http://www.youtube.com/watch?v=7pvCcgQiXNk Right now we're working on building 3D animation and Physics into the engine for our next project. It's written in C#, but I have plans for awhile that once it's to a certain point I'll be porting it to D.
Re: core.simd woes
Manu wrote:
std.simd already does have a mammoth mess of static if(arch
compiler).
The thing about std.simd is that it's designed to be portable,
so it
doesn't make sense to expose the low-level sse intrinsics
directly there.
Well, that's not really what I was suggesting. I was saying maybe
eventually matching the agnostic gdc builtins in a separate
module:
// core.builtins
import core.simd;
version (GNU)
import gcc.builtins;
void madd(ref float4 r, float4 a, float4 b)
{
version (X86_OR_X64)
{
version (DigitalMars)
{
r = __simd(XMM.PMADDWD, a, b);
}
else version (GNU)
{
__builtin_ia32_fmaddpd(r, a, b)
}
}
}
then std.simd can just use a single function (madd) and forget
about all the compiler-specific switches. This may be more work
than it's worth and std.simd should just contain all the platform
specific switches... idk, i'm just throwing out ideas.
Re: core.simd woes
On Tuesday, 9 October 2012 at 19:18:35 UTC, F i L wrote:
Manu wrote:
std.simd already does have a mammoth mess of static if(arch
compiler).
The thing about std.simd is that it's designed to be portable,
so it
doesn't make sense to expose the low-level sse intrinsics
directly there.
Well, that's not really what I was suggesting. I was saying
maybe eventually matching the agnostic gdc builtins in a
separate module:
// core.builtins
import core.simd;
version (GNU)
import gcc.builtins;
void madd(ref float4 r, float4 a, float4 b)
{
version (X86_OR_X64)
{
version (DigitalMars)
{
r = __simd(XMM.PMADDWD, a, b);
}
else version (GNU)
{
__builtin_ia32_fmaddpd(r, a, b)
}
}
}
then std.simd can just use a single function (madd) and forget
about all the compiler-specific switches. This may be more work
than it's worth and std.simd should just contain all the
platform specific switches... idk, i'm just throwing out ideas.
You know... now that I think about it, this is pretty much
EXACTLY what std.simd IS already... lol, forget all of that,
please.
Re: core.simd woes
Iain Buclaw wrote: I fixed them again. https://github.com/D-Programming-GDC/GDC/commit/9402516e0b07031e841a15849f5dc94ae81dccdc#L4R1201 float a = 1, b = 2, c = 3, d = 4; float4 f = [a,b,c,d]; === movss -16(%rbp), %xmm0 movss -12(%rbp), %xmm1 Nice, not even DMD can do this yet. Can these changes be pushed upstream? On a side note, I understand GDC doesn't support the core.simd.__simd(...) command, and I'm sure you have good reasons for this. However, it would still be nice if: a) this interface was supported through function-wrappers, or.. b) DMD/LDC could find common ground with GDC in SIMD instructions I just think this sort of difference should be worked out early on. If this simply can't or won't be changed, would you mind giving a short explanation as to why? (Please forgive if you've explained this already before). Is core.simd designed to really never be used and Manu's std.simd is really the starting place for libraries? (I believe I remember him mentioning that)
Re: What is the case against a struct post-blit default constructor?
+1 to all of that. If the only issue is performance, I think the best solution is just to Document with a warning against using default constructors in performance critical structs.
Re: core.simd woes
Iain Buclaw wrote:
I'm refusing to implement any intrinsic that is tied to a
specific architecture.
I see. So the __builtin_ia32_***() functions in gcc.builtins are
architecture agnostic? I couldn't find much documentation about
them on the web. Do you have any references you could pass on?
I guess it makes sense to just make std.simd the lib everyone
uses for a base-line support of SIMD and let DMD do what it
wants with it's core.simd lib. It sounds like gcc.builtins is
just a layer above core.simd anyways. Although now it seems that
DMD's std.simd will need a bunch of 'static if (architectureX) {
... }' for every GDC builtin... wounder if later that shouldn't
be moved to (and standerized) a 'core.builtins' module or
something.
Thanks for the explanation.
Re: Implicit instantiation of parameterless templates
On Friday, 5 October 2012 at 12:01:30 UTC, Piotr Szturmaj wrote:
Java and C# with their generics can do the following:
class List { }
class ListT { }
List list = new List();
Listint intList = new Listint();
In D similar code can't work because we can't have both a type
and a template with the same name. So this code must be
rewritten to:
class List(T = Variant) { }
List!() list = new List!();
List!int intList = new List!int;
When template name is used as a type and it can be instantiated
with no parameters it could be automatically rewritten to
List!() by the compiler. That code would then look like this:
List list = new List;
List!int intList = new List!int;
The question is... is it possible to change D's behaviour to
avoid awkward !() template parameters _without_ breaking
backward compatibility?
+1 This is natural.
Plus, this has other uses I've mentioned on here in the past,
sub-scoping:
class Foo
{
int bar;
template baz
{
int bar;
}
}
void main()
{
auto f = new Foo();
f.bar = 0;
f.baz.bar = 1;
}
Currently, this syntax is possible, but requires to some ugly
work-arounds.
Re: Implicit instantiation of parameterless templates
Dmitry Olshansky wrote:
Hm... If placed at the global scope it looks like a namespace.
I don't see anything wrong with that. It's just another way
(somewhat unique to D) you can categorize your code. Most people
probably won't use this sort of thing all over the place, but it
actually might be useful for enforcing naming classifications:
// File system/io.d
template Console
{
void write( ... )
void read()
}
template File
{
void write( ... )
void read()
}
// File something.d
import system.io;
void main()
{
// Prefix 'Console/File' required so to the
// user, it looks somewhat like a static object
Console.write( ... );
File.write( ... );
}
Re: Implicit instantiation of parameterless templates
Piotr Szturmaj wrote:
final abstract class Console
{
static:
void write() { }
void read() { }
}
Console.write();
P.S. Yes, simultaneous final and abstract actually works :)
Yes, I know there are other ways to do this, like you mentioned
above. However, parameter-less templates would still be nice for
scopes withing a Class (like my original example). Like I
mentioned, it's possible today:
class Foo
{
int bar;
alias Baz!() baz;
template Baz()
{
int bar;
}
}
auto foo = new Foo();
foo.bar = 10;
foo.baz.bar = 10; // Same as..
foo.Baz!().bar = 10; // ..writing this.
However, like OP is suggesting, it would be nice to have
syntax-sugar to eliminate the need for extra typing at
instantiation and at definition (my suggestion). The fact that
these odd '!()' symbols are required will probably detour
less-experienced people from using this feature today.
Re: core.simd woes
jerro wrote: I'm trying to create a bugzilla account on that site now, but account creation doesn't seem to be working (I never get the confirmation e-mail). I never received an email either. Is there a expected time delay?
Re: core.simd woes
Manu wrote: These are indeed common gotchas. But they don't necessarily apply to D, and if they do, then they should be bugged and hopefully addressed. There is no reason that D needs to follow these typical performance patterns from C. It's worth noting that not all C compilers suffer from this problem. There are many (most actually) compilers that can recognise a struct with a single member and treat it as if it were an instance of that member directly when being passed by value. It only tends to be a problem on older games-console compilers. As I said earlier. When I get back to finishing srd.simd off (I presume this will be some time after Walter has finished Win64 support), I'll go through and scrutinise the code-gen for the API very thoroughly. We'll see what that reveals. But I don't think there's any reason we should suffer the same legacy C by-value code-gen problems in D... (hopefully I won't eat those words ;) Thanks for the insight (and the code examples, though I've been researching SIMD best-practice in C recently). It's good to know that D should (hopefully) be able to avoid these pitfalls. On a side note, I'm not sure how easy LLVM is to build on Windows (I think I built it once a long time ago), but recent performance comparisons between DMD, LDC, and GDC show that LDC (with LLVM 3.1 auto-vectorization and not using GCC -ffast-math) actually produces on-par-or-faster binary compared to GDC, at least in my code on Linux64. SIMD in LDC is currently broken, but you might consider using that if you're having trouble keeping a D release compiler up-to-date.
Re: core.simd woes
On Tuesday, 2 October 2012 at 21:03:36 UTC, jerro wrote:
SIMD in LDC is currently broken
What problems did you have with it? It seems to work fine for
me.
Can you post an example of doing a simple arithmetic with two
'float4's? My simple tests either fail with LLVM errors or don't
produce correct results (which reminds me, I meant to report
them, I'll do that). Here's an example:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
writeln((a + b).array); // WORKS: [3, 3, 3, 3]
float4 c = [1, 2, 3, 4]; // ERROR: Stored value type does
// not match pointer operand type!
// [..a bunch of LLVM error code..]
float4 c = 0, d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
writeln((c + d).array); // WRONG: [1, 1, 1, 1]
}
Re: core.simd woes
Also, I'm using the LDC off the official Arch community repo.
Re: core.simd woes
jerro wrote:
This code gives me internal compiler errors with GDC and DMD
too (with float4 c = [1, 2, 3, 4] commented out). I'm using
DMD 2.060 and a recent versions of GDC and LDC on 64 bit Linux.
Yes the SIMD situation isn't entirely usable right now with DMD
and LDC. Only simple vector arithmetic is possible to my
knowledge. The internal DMD error is actually from processing '(a
+ b)' and returning it to writeln() without assigning to an
separate float4 first.. for example, this compiles with DMD and
outputs correctly:
import core.simd, std.stdio;
void main()
{
float4 a = 1, b = 2;
float4 r = a + b;
writeln(r.array);
float4 c = [1, 2, 3, 4];
float4 d = 1;
c.array[0] = 4;
c.ptr[1] = 4;
r = c + d;
writeln(r.array);
}
correctly outputs:
[3, 3, 3, 3]
[5, 5, 4, 5]
I've never tried to do SIMD with GDC, though I understand it's
done differently and core.simd XMM operations aren't supported
(though I can't get them to work in DMD either... *sigh*). Take a
look at Manu's std.simd library for reference on GDC SIMD
support:
https://github.com/TurkeyMan/phobos/blob/master/std/simd.d
Re: Simple GEdit .lang github color scheme
On Monday, 1 October 2012 at 12:44:45 UTC, deadalnix wrote:
OK, simple feedback : it doesn't recognize the lazy keyword.
Except for that, it is really good.
Whoops, I added that awhile ago but forgot to re-upload. Here's a
updated version with 'ref', 'lazy', and bracket/operator
highlighting.
http://reign-studios.com/d-downloads/reign.lang.tar.gz
I like the bracket/operator highlighting, but if you don't want
it just remove these lines:
lines 209 - 211:
context id=operators style-ref=type
match
extended=true[\(\)\{\}\[\]lt;gt;=\~\.,\/\!\%\^\amp;\*\+\-\:;]/match
/context
line 274:
context ref=operators/
Re: core.simd woes
Not to resurrect the dead, I just wanted to share an article I
came across concerning SIMD with Manu..
http://www.gamasutra.com/view/feature/4248/designing_fast_crossplatform_simd_.php
QUOTE:
1. Returning results by value
By observing the intrisics interface a vector library must
imitate that interface to maximize performance. Therefore, you
must return the results by value and not by reference, as such:
//correct
inline Vec4 VAdd(Vec4 va, Vec4 vb)
{
return(_mm_add_ps(va, vb));
};
On the other hand if the data is returned by reference the
interface will generate code bloat. The incorrect version below:
//incorrect (code bloat!)
inline void VAddSlow(Vec4 vr, Vec4 va, Vec4 vb)
{
vr = _mm_add_ps(va, vb);
};
The reason you must return data by value is because the quad-word
(128-bit) fits nicely inside one SIMD register. And one of the
key factors of a vector library is to keep the data inside these
registers as much as possible. By doing that, you avoid
unnecessary loads and stores operations from SIMD registers to
memory or FPU registers. When combining multiple vector
operations the returned by value interface allows the compiler
to optimize these loads and stores easily by minimizing SIMD to
FPU or memory transfers.
2. Data Declared Purely
Here, pure data is defined as data declared outside a class
or struct by a simple typedef or define. When I was
researching various vector libraries before coding VMath, I
observed one common pattern among all libraries I looked at
during that time. In all cases, developers wrapped the basic
quad-word type inside a class or struct instead of declaring
it purely, as follows:
class Vec4
{
...
private:
__m128 xyzw;
};
This type of data encapsulation is a common practice among C++
developers to make the architecture of the software robust. The
data is protected and can be accessed only by the class interface
functions. Nonetheless, this design causes code bloat by many
different compilers in different platforms, especially if some
sort of GCC port is being used.
An approach that is much friendlier to the compiler is to declare
the vector data purely, as follows:
typedef __m128 Vec4;
ENDQUOTE;
The article is 2 years old, but It appears my earlier performance
issue wasn't D related at all, but an issue with C as well. I
think in this situation, it might be best (most optimized) to
handle simd the C way by creating and alias or union of a simd
intrinsic. D has a big advantage over C/C++ here because of UFCS,
in that we can write external functions that appear no different
to encapsulated object methods. That combined with
public-aliasing means the end-user only sees our pretty
functions, but we're not sacrificing performance at all.
Re: Dangling if
monarch_dodra wrote:
Personally, EVEN when I'm doing a 1 line if, I *still* wrap it
in a block. EG:
if(a == 0)
a = 1;
or
if(a == 0) a = 1;
Becomes:
if(a == 0)
{a = 1;}
or
if(a == 0) {a = 1;}
It might look iffy at first, but very quickly feels natural. It
may look like it requires (god forbid) useless typing, but
when that 1 liner becomes a 2 liner, it saves your life.
It has saved mine more than once actually!
I've done the dangling if bug often. One day I said no-more!.
I've addopted the above format, and it has not happened to me
since.
Further more, thanks to D's ban on if();, you can litterally
never fail with this format. I warmly recommend it to every one.
This is exactly why I think the '{}' brackets should be a
requirement and not the '()' brackets:
if a == b { doSomething(); }
if a == b
{ doSomething(); }
if a == b
{
doSomething();
doSomethingElse();
}
I know this will never happen in D, but it's how it should be,
IMO.
since LDC install command is listed for Fedora...
...on the 'Downloads Tools' page, it might be nice to list the install command for Arch Linux as well. Although I doubt any Arch users won't first try a pacman command, it's very well supported on Arch Linux official repos and it might be nice to advertise that fact. LDC on Arch is up-to-date (version 2.060), and a very good compiler, especially with the release of LLVM 3.1's auto-vectorization. The command is simply: pacman -S ldc and the Arch Linux logo can be found here: http://www.archlinux.org/art/
Re: Simple GEdit .lang github color scheme
deadalnix wrote: Sound nice. How can I use that on my computer ? What do I do with the files ? You need to move the files into their 'gtksourceview-3.0' folders. On Linux (and other OS's should be similar), do: 1. find or create the following user directories: ~/.local/share/gtksourceview-3.0/styles ~/.local/share/gtksourceview-3.0/language-specs 2. Move the downloaded files into their respective folders, 'D.lang' to 'language-specs' and 'github.xml' to 'styles'. (Note, the download already contains this hierarchy) Alternatively (although I don't recommend it), you can move the files to: /usr/share/gtksourceview-3.0/... (overwriting the existing D.lang file) which will change it for all users. Hope that helps. Let me know if you have any problems, or find any highlighting bugs. Thanks.
Re: totally satisfied :D
* Its predecessor is :C, a very very unhappy language lawl
Re: Would like to see ref and out required for function calls
On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote: Couldn't this easily be supported by an IDE by coloured function arguments based on their type? Then the information is clearly visible without cluttering the code. no because... wait... that... that could work.
Re: Would like to see ref and out required for function calls
On Friday, 14 September 2012 at 22:20:16 UTC, Manuel wrote: On Friday, 14 September 2012 at 06:55:00 UTC, F i L wrote: On Thursday, 13 September 2012 at 22:21:34 UTC, ixid wrote: Couldn't this easily be supported by an IDE by coloured function arguments based on their type? Then the information is clearly visible without cluttering the code. no because... wait... that... that could work. Ok. Then ... who is writing this IDE ? I'm just saying it's a solution that doesn't require adding a breaking feature to D. I know MonoDevelop has the ability to color user-types and such, maybe eventually Alex will be able to add such a feature. If the compiler developers can't or won't add 'foo(ref x)' semantics to the compiler, then this is really the only option left available that gives the same level of insight to developers that C# does.
Re: Would like to see ref and out required for function calls
Minas wrote: Anyway, who needs to see f(ref x) when you can put your mouse above the function call and see its declaration? All modern IDEs support that - and I don't think C# guys use plain text editors. People debugging large bodies of code should not be required to hover the mouse over each and every function parameter for a second to properly understand structure. People using non-tooltip text editors have an even harder time. I think you're missing the point. This code: int* x; foo(x); at least tells you there's a _potential_ x is being manipulated rather than just used. We don't need full insight into what's going on, just a helpful hint which narrows the potential culprits when debugging. If fact, it would nice if even reference types where required to follow similar is modified in function semantics, and I have ideas about that, but I'm not going there right now...
Re: Simple GEdit .lang github color scheme
Little update: - float numbers without '.f' (eg, 1f, 234f, etc) are colored like numbers - Capatalized identifiers with preceding underscores are still colored like types (except for __FILE__, __LINE__, etc) Same Download link as above: http://reign-studios.com/d-downloads/gtksourceview-3.0.tar.gz
Re: Simple GEdit .lang github color scheme
On Monday, 10 September 2012 at 19:32:42 UTC, angel wrote: Both your links are seemingly dead. Odd, they work for me :-/
Simple GEdit .lang github color scheme
After being annoyed with GEdit's presentation of D code, I decided to do something about it. This isn't any big Announcement or anything, just thought I'd share. I made a color-scheme based on the colors from Github cause they're pretty and D loves github :). And I modified the the 'lang.d' gtk-sourceview file in the following ways: - @property/@system/etc are properly highlighted - I included common types like 'string', 'size_t', 'c_long', even core.simd's vector types like 'float4'. - Since D follows camelCaseSyntax consistently and the community seems to largely follow it as well, I made all words starting with a capital letter (PascalCase) colored as types. This is nice because user-types blend in nicely with built-in ones (int/float/etc) and helps you pick out where the code is dealing with a Type rather than a local. Screenshot: http://reign-studios.com/screenshots/DlangGedit.png Download: http://reign-studios.com/d-downloads/gtksourceview-3.0.tar.gz
Re: Win64 milestone
Walter Bright wrote: D1 now compiles Phobos1 completely, and gets all the way to main() without crashing, and shuts down without crashing. Nice!
Re: Would like to see ref and out required for function calls
On Friday, 7 September 2012 at 11:33:41 UTC, Kevin McTaggart wrote: I've been looking at migrating a reasonably large ship motion library (tens of thousands of lines) from C# to D. I've become quite enthusiastic about D, and most of my problems have been relatively minor (e.g., inconsistent bugs with std.container.Array, would like orange serialization to give me an error telling me I didn't register a class before calling serialize). I suggest that the language require ref and out when calling functions, as C# requires. This would make code easier to understand, and would also eliminate the problem I had when the wrong function from the following choices was mistakenly called: parseLineInts(string text, int positionStart, out int j0, out int j1) parseLineInts(string text, out int j0, out int j1, out int j2) I note that the second function calls another function as follows: int positionStart = 1; parseLineInts(text, positionStart, j0, j1, j2); I look forward to seeing feedback from D experts. This is the only significant change that I could think of recommending for the language. +1. The fact that a value type is modified should be information the programmer can see at a glance. Andrei Alexandrescu wrote: Actually the darndest thing is that C# has retired the syntax in 5.0 (it used to be required up until 4.0). Apparently users complained it was too unsightly. Citation? I'm using C# 5.0 with Visual Studios 2012 on Windows 8 right now and ref/out are still required at the call sight of functions.
