Re: GDC D2 port status
Awesome! Would be great to see on the official Arch repos! :)
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: 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: Mono-D v0.4.9 - Rough formatting capability
Thanks Alex, even though I don't use auto-formatting (I never did like that).
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: 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: 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: 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.
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: 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: 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: 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: 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: 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: 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: 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: Alexander Bothe Passes GSoC Finals
I missed this post earlier. Congrats, Alex. Truly great work, I've definitely noticed a big speed improvement in the code completion of Mono-D over the summer.
Re: Walter charms the audience at Sioux
Peter Alexander wrote: There's no such thing as a perfect language. Note the asterisks.
Re: Walter charms the audience at Sioux
Andrei Alexandrescu wrote: On 8/23/12 9:27 PM, F i L wrote: Jonathan M Davis wrote: You've been mistaken. @system is the default. If we could go back in time and redo things, we'd probably do stuff like make pure and @safe the default, but it's far too late now. Okay, thanks for the info. I have a feeling that D3 will truly be the golden age and point of mass adoption of the D programming language. If it's not D2, it'll never be. I'm not sure what so hard to understand about the term golden age but I get the impression people here think I was dishing out an insult to D2. I'm not. I'm just being realistic. Johnathan mentions that D3 won't even be considered for years and that's the amount of time I think it'll take before D2 fixes all it's problems keeping it from becoming widely adopted: shared objects, IDE tools, ARM (Android/iOS), third party libraries, etc.. thus me saying that D3 will bring the _golden age_ of D. Meaning it's the age where all the university and programming jobs are focused on D. I'm not being pessimistic here, I'm being optimistic.
Re: Mono-D v0.4.1.2 - Heavily improved performance + Completion bugs removed
http://i3.kym-cdn.com/entries/icons/original/000/004/128/BRILLIANT_.jpg Great work as always, Alex :D
Re: Walter charms the audience at Sioux
I thought default was @safe, but the slides say it's @system... is that a typo or have I been mistaken this entire time?
Re: Walter charms the audience at Sioux
Jonathan M Davis wrote: You've been mistaken. @system is the default. If we could go back in time and redo things, we'd probably do stuff like make pure and @safe the default, but it's far too late now. Okay, thanks for the info. I have a feeling that D3 will truly be the golden age and point of mass adoption of the D programming language.
Re: Walter charms the audience at Sioux
Jonathan M Davis wrote: Well, since it'll be years before we even consider creating D3, we're in trouble if we need D3 for D to be successful. D2 isn't perfect, but it's still a very solid language and outshines more entrenched languages on a number of levels. I'd expect that its lack of adoption is primarily a marketing issue. I think you misunderstand my intent. D2 will carry D to far reaches, and is a very usable, and now stable language; and I know D3 won't come for years. That said, there are language issues that, as you put, simply can't be addressed in D2 because they're not worth the effort required to fix them. I only meant that I think once D3 does come around, and it's *perfect*, that others simply wont be able to resist it and it will truly be adopted on a mass scale.
Re: NaNs Just Don't Get No Respect
On Saturday, 18 August 2012 at 14:29:12 UTC, Jesse Phillips wrote:
On Saturday, 18 August 2012 at 09:32:01 UTC, F i L wrote:
It's flawed because condition2 relies upon condition1 to
function without error. The example, as Walter presented it,
is logically describing:
float f;
if (condition1) {
f = 7;
if (condition2)
f ++;
}
This greatly changes the semantics of the code. I do not
disagree that the example indicates the original programmer is
likely wrong and needs to improve the description of his intent.
I agree, and that's my point here. The original example is an
erroneous presupposition that leads to faulty conclusions. If the
compiler warned against this error the programmer would likely
fix the code to a state which prevents the potential bug this
example was originally intended to illustrate.
What I disagree on is that it is that complaining that f might
not be initialized will force the programmer to think and
address the true issue. It is also taking the example at face
value. The complexity of the relationship could be harder too
see (I don't know what that would be),
I too, don't know of any examples where defaulting to NaN would
prevent an error where static analysis would not, though I'm
always open to argument. Given the benefits of static analysis
and defaulting to 0.0f for class members (which I listed in
previous posts), I see that position as the one with demonstrable
benefit.
and somewhere else where condition1 is set there could be code:
auto condition1 = getmevalue();
enforce(condition1 condition2, Huston this is the
problem!);
I don't see how this changes the situation with NaN vs. static
analysis.
Re: NaNs Just Don't Get No Respect
Your example:
float f;
if (condition1)
f = 7;
... code ...
if (condition2)
++f;
is flawed in that condition1 is _required_ to pass in sync with
condition2, or you'll get a NaN in the result. In this scenario,
you're forced to provide a usable default explicitly no matter
what, so your later argument:
This leads to the programmer getting annoyed with false
positive error diagnostics, and he'll likely add an =0
doesn't make sense, because he needs to provide a usable value in
the first place.
This is exactly why I was arguing that explicit assignment to NaN
was better for debugging as well. Because a maintenance
programmer, that steps in at a later date, would:
1. be less likely to change an explicit assignment to NaN
without understand the code fully first.
2. have an easier time tracking down the origin of a NaN
error, because variables not explicitly assigned to NaN _can't_
be the culprit.
Imagine we have code that looks like:
class SomeClass
{
float foo;
float bobDole;
float someKind;
float barFoo = float.nan;
float aVariable;
float barBaz;
this() { ... lotsa init code ... }
}
If floats defaulted to 0.0f, then we'd know exactly which
variable to analyze in order to find the source of our NaN bug:
'barFoo'. Since we don't have this visual clue, we have to
analyze all of them. Of course, we can reverse this by explicitly
assigning all, except 'barFoo', to 0.0f, but that's:
1. less convenient to type
2. harder to visually parse to find the potential NaNs
3. inconsistent with 'int'
This is how I wish D worked:
1. Functions:
void foo() {
float f;
f ++; // compiler error
}
void foo() {
float f;
if (condition1)
f = 5;
if (condition2)
f ++; // compiler error
}
2. Structs Classes:
class Foo {
float f; // 0.0f
void bar() { f++; }
// Notice: no constructor defined
}
void main() {
auto foo = new Foo();
foo.bar(); // works fine
}
Unfortunately, structs don't have default constructors in D. I'm
not sure exactly why that is, but if there's some design or
performance issue, structs could always work like this instead:
3. Structs:
struct Foo {
float f; // compiler error
}
struct Foo {
float f = 0; // OK
}
struct Foo {
float f; // OK, if:
this() { f = 0; } // set in constructor
}
Re: NaNs Just Don't Get No Respect
bearophile wrote: On a more general note, I know many professionals in other fields that never write small articles about what they are doing. So is it normal just for programmers to write (small) articles like this? I write them, and other programmers I know write similar things. Maybe to program you need (among other things) active linguistic centers in the brain :-) Why would it matter what is normal? Normality is constantly changing anyways. Or are you just curios if it's been common practice in the past?
Re: First working Win64 program!
Bernard Helyer wrote: Clearly the solution is to look into cloning technologies. Nah, we just need to write a software sophisticated enough that it can write software itself. Then we'll need to write software simple enough to enjoy micro-managing that software to keep it on task.
Re: D overview on facepunch.com
On Sunday, 12 August 2012 at 12:04:05 UTC, Jakob Ovrum wrote: On Sunday, 12 August 2012 at 12:02:06 UTC, Andrei Alexandrescu wrote: http://facepunch.com/showthread.php?t=1204676s=affb44baf90ed48786f63e20a6052df1p=37188144#post37188144 Andrei I'm the OP. It's still a work in progress, some sections are super-thin and I need to put in more references since I don't explain most of the terms I introduce, and many of them are D-specific (e.g. scope statements). You mention in the first post that you're unaware of any IDE for Mac. MonoDevelop + MonoD is cross platform and works identical (except for Debugging) on all three platforms. Also, the way you have MonoD listed (for Linux...), it could be confused as a Linux-Only IDE to a passer-by. I noticed later on a person was comparing VisualD to VisualStudios-C#. Often, I've had a much better time with MonoD over VisualD, and for those who place a lot of importance on intelisense, MonoD has much more comparable features to C# AtM. I would recommend amending your MonoD listing to include a Cross Platform label and emphasis on intelisense support *comparable* to C#. Mono-D's not all there yet, but it actually feels faster and less buggy than Mono C#'s built-in intellisense. Project management and refactoring support are also very complete. That being said, D is a much more dynamic beast (syntactically) than C#, so there's more than a few times code-completion simply fails. Regardless, it's a great development environment and I wouldn't recommend anything else :)
Re: First working Win64 program!
On Saturday, 11 August 2012 at 08:17:13 UTC, Walter Bright wrote:
No, it ain't much, some of it is jury rigged, and there's a
heluva lot more work to do. But we've got liftoff!
-
import core.stdc.stdio;
extern (C) int main()
{
puts(hello world\n);
return 0;
}
-
dmd -c -m64 hello.d
cl hello.obj
hello
hello world!
Awesome!
Re: Mono-D v0.4.1 - Completion improvement
On Friday, 10 August 2012 at 18:34:14 UTC, alex wrote: Hi everyone, Just want to announce the release of a new Mono-D version that contains some code completion improvements. I was occupied with developing the expression evaluation all along the GSoC 2012, but unfortunately the current results can't really be seen - since couple of things are done deep down in the parser library, independently from other completion features. Anyway, the project (including me, lol) is still alive, and here are some updated fixed completion features :) Changelog, project blog: http://mono-d.alexanderbothe.com Issues: https://github.com/aBothe/Mono-d/issues Great work, Alex! MonoDevelop 3.0.3 finally just came out on the official Arch Linux repos in tangent with your MonoD update. Good day to be a D programmer :D
Re: dmd 1.075 and 2.060 release
On Thursday, 2 August 2012 at 19:19:04 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.075.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.060.zip Nice! Good to see a std.container get a DList. Also, has something changed with core.simd? It's not showing in the library reference now, but I didn't see anything about a module change in the change log... ?
Phoronix: Merging The GNU D Compiler Into GCC, Again
Looks like GDC's made a little splash over at Phoronix this morning. In case no one here reads Phoronix, here's the link: http://www.phoronix.com/scan.php?page=news_itempx=MTEyMzM The forums rather quiet just yet, but I imagine some C++11 folks may start raising their voices fairly soon. Phoronix isn't really known for it's diplomacy ;-P
Re: Introducing vibe.d!
Sönke Ludwig wrote:
During the last few months, we have been working on a new
framework for general I/O and especially for building
extremely fast web apps. It combines asynchronous I/O with
core.thread's great fibers to build a convenient, blocking
API which can handle insane amounts of connections due to
the low memory and computational overhead.
Some of its key fatures are:
...
vibe.d looks great! Looking through the docs, it feels clean and
hip like node.js
However, there are a couple refactoring choices I think would
have made it even more hip, consider the home page example:
import vibe.d;
void handleRequest(HttpServerRequest req,
HttpServerResponse res)
{
res.writeBody(Hello, World!, text/plain);
}
static this()
{
auto settings = new HttpServerSettings;
settings.port = 8080;
listenHttp(settings, handleRequest);
}
vibe.d as the project name is great, but why have module vibe.d
and not simply vibe? Or, why prefix all the types with
HttpServer when you could separate those objects into a new
module and drop the prefix. I think those simple changes would
make an already polished library shine a bit brighter:
import vibe.http;
void handleRequest(Request req, Response res) {
res.writeBody(Hellow, World!, text/plain);
}
static this() {
auto settings = new Settings;
settings.port = 8080;
listen(settings, handleRequest);
}
the echo server would look like:
import vibe.tcp;
static this()
{
listen(7, (conn){ conn.write(conn) });
}
Also, it's great to see MongoDB support built in :D, but isn't
there a way to trim down the query object from:
BSON({name: BSON(Peter)})
to:
BSON({name:Peter})
by writing a generic AssosiativeArrayToBSON function? That way
you could overload MongoDB's find/save/etc functions to accept
arbitrary AAs as queries, which would end up looking a lot
slicker in the docs I think. Plus, through CTFE it's possible
this conversion could happen at both compile-time and run-time:
auto db = new MongoDB;
auto col = db[test.collection];
foreach (doc; col.ctFind!([name:Peter])) {
...
}
Just some ideas in case you haven't thought of them already :)
Overall vibe.d looks like a fantastic library. Thank you and
Congrats!
Re: Introducing vibe.d!
On Friday, 27 April 2012 at 20:15:05 UTC, Tove wrote: On Friday, 27 April 2012 at 19:40:53 UTC, F i L wrote: vibe.d as the project name is great, but why have module vibe.d and not simply vibe? Or, why prefix all the types with More complicated projects/frameworks ontop of vibe which implements it's own main is free to use vibe.all. But I think... import vibe.d; ... makes perfect sense because it contains main()! Ah I see, I was thinking the example wasn't the full code. Still, I think doing something like: import vibe, vibe.html; where vibe has main() and vibe.html has html is still better semantics.
Re: Mono-D 0.3.7
Stephen Jones wrote: Does anyone else have this issue? No, sorry. I mostly use Mono-D on Linux with MonoDevelop 2.8.4. Probably the best way to resolve this is to report the issue: https://github.com/aBothe/Mono-D/issues
Re: Mono-D 0.3.7
Great!
- [Resolver] Built in new method to cache UFCS parameter
results; Refactored further internal parser wrappers
What is this? Is it this:
void foo(int x) if (x 5) { ... }
...
3.foo(); // underlined as error?
6.foo(); // looks good
?? Or not something that cool? because that would be pretty cool
:)
Re: Mono-D 0.3.7
On Tuesday, 17 April 2012 at 15:44:41 UTC, alex wrote: Oh uhm, the feature you mentioned is not implemented yet - it's just a kind of optimization e.g. when you type 1234. you get all available free methods listed - and this happens kinda quick now, or at least more quicker than before :) Okay, I see. Good luck with GSoC! MonoD + Android could equal a big boost in popularity for D, so I'm glad to hear your GSoC submission is coming along.
Re: dmd 1.074 and 2.059 release
On Friday, 13 April 2012 at 05:54:26 UTC, Walter Bright wrote: Another big pile of bug fixes. More contributors than ever! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.074.zip http://www.digitalmars.com/d/2.0/changelog.html https://github.com/downloads/D-Programming-Language/dmd/dmd.2.059.zip Note that the changelogs on dlang.org haven't been updated yet. Hope to get that done soon. Great news! Congrats to everyone involved! You should update the Downloads Tools page so I can mark DMD as out-of-date on the Arch Linux repo.
Re: Mono-D 0.3.5
UTC, alex wrote: Meh, I guess I'll highlight mixin like 'private' and 'const' are highlighted - so as it was more like an attribute, not a type anymore :) Awesome, thank you! Also, code completion seems to randomly die in this release. Not sure exactly what causes it since it seems to only happens when working with larger files and randomly. I think it might be something to do with template variadic parameters. If I come across something a more concrete, I'll post an bug report. Yeah sure, I cleaned up a lot of stuff - perhaps some hopefully minor things got broken - and variadic parameters aren't really implemented I've been doing a lot with mixin templates lately, so that's probably it.
Re: Mono-D 0.3.5
On Monday, 26 March 2012 at 23:57:27 UTC, alex wrote: Couple of bug fixes + new refactoring feature: - [Expression Evaluator] Began with the expression eval stuff -- added few class stubs - [Resolver] Fixed 2 small completion bugs (very precise, indeed! :-D) - [Parser] Fixed block boundaries determination bug - [Highlighting] Small highlighting change (added __vector keyword and recolored 'mixin') - [Building/Settings] Small usability improvement - [Settings] Fixed saving-bug - [Generic] Add 'lib' prefix to library name when creating new (linux/mac) projects - [Refactoring] Added renaming validation check - [Refactoring] Finished a rough implementation of symbol import refactoring (accessible via keystroke or context menu - just hover an undefined symbol, and right-click) - [Internal] Further code refactoring -- a lot of code could be abstracted - [Completion] Improved method parameter insight Article: http://mono-d.alexanderbothe.com/?p=355 Issues: https://github.com/aBothe/Mono-D/issues Great job, Alex. As always. For what it's worth, I don't like the new mixin coloring. It's colored like a type now, which doesn't make sense to me (in some cases it does, aka: mixin Template name). One of the things I like about MonoDevelop is that I can color seporate many different things: types, attributes, flow control, etc.. but now mixin looks like I'm defining a variable, which isn't usually how I use mixins. Also, code completion seems to randomly die in this release. Not sure exactly what causes it since it seems to only happens when working with larger files and randomly. I think it might be something to do with template variadic parameters. If I come across something a more concrete, I'll post an bug report.
Re: UFCS for D
On Thursday, 29 March 2012 at 00:21:38 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/rif9x/uniform_function_call_syntax_for_the_d/ Andrei Awesome! Been wanting this ever since I bought TDPL! :D One question though, what takes priority, UFCS or opDispatch?
Linux and D wallpaper :)
Don't know if this is the place for this sort of announcement Found a great looking Linux logo over at gnome-look.org by kodama (http://gnome-look.org/content/show.php/Linux+Logo?content=142418). So I thought I'd modify it a bit and make some wallpapers. D sounded like a great place to start. Here's the first go (1080p): http://reign-studios.com/d-wallpapers/LinuxAndD.png I'll make a few more and post them here (suggestions welcome). Also, if anyone wants the original Inkscape files just let me know.
Re: Linux and D wallpaper :)
James Miller wrote: Although, while I like the Men are from Mars quote, I can see it being taken the wrong way... Ya I was anticipating that. I'll be making a version without any sayings, but I'm still playing around with ways to fill that void a bit.
Re: I'll be in Seattle at Lang.NEXT
On Thursday, 15 March 2012 at 21:00:59 UTC, James Miller wrote: On 16 March 2012 09:33, Brad Anderson e...@gnuk.net wrote: You and Bernard Helyer can get together and have a little D conference. Maybe call it D For Two. Regards, Brad Anderson Probably not worth one of us doing a 9 hour drive, or catching a plane, just for that. On a similar note, I wouldn't mind trying to find more D programmers near where I live. -- James Miller Could always start a D-singles.org site... ;p
Re: Mono-D 0.3.0
Awesome job, Alex! With the performance improvements of Mono 2.8.6.5 and Parser/Performance improvements of Mono-D 3.0 working with D is on par with working with C# in Visual Studios. Even better since I get the same experience on all three platforms. It would be nice to see Mono-D (and other IDEs) linked to from the dlang.org somewhere. So new D users won't have to dig through the forums or sift through dead dsource.org projects to find it. Seeing as how, for some of us, proper IDE support is a big issue, and Mono-D + MonoDevelop is virtually on-par with Visual Studios (productivity wise). I think it would help D's popularity to some degree if we could direct people to some officially supported IDEs. With Mono-D on top of course! ;)
Re: TDPL monthly sales at 12-month high
WORK YOU SLAVES!! BWAHAHAHA!! No seriously. Thank you! To all the contributes. Really appreciate it :)
Re: dmd 1.073 and 2.058 release
Marco Leise wrote: I'm just repeating what's already been said, but UFCS on classes and structs has the problem of ambiguities with proper methods of those. If 2.058 introduced more UFCS, then it is for literals. Try 123.foo;. C#'s had UFSC for years without ambiguity problems. Also, 123.foo; doesn't work.
Re: Mono-D 0.2.9
Awesome job Alex! Use this every day ;-) 2.9 seems very stable so far.
