Re: [Phobos] You're crippled by your orthodoxism
Jean pierre: This is a problem, you, the D core has: you're crippled by your orthodoxism. Nothing will be added because of this: **rules**. The current level of acceptance of Phobos patches seems roughly correct to me. Bye, bearophile
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 02:39:56 UTC, Steven Schveighoffer wrote: An array as an output range writes to the front. You can use std.array.Appender to get appending behavior. I know, it's weird. Alternatively, you can add more bytes to the array, and append to the slice, but that may be ugly/hard to do. -Steve Hmm... isnt that't what the std.bitmanip.write function is for? It even provides an index. I could make an 8 byte buffer and then make a slice with the last 4 bytes and use append there, but it would be rather a hack around something that should have worked. Perhaps I have found a bug. Actually I am not sure because I am not yet familiar with the way to use templates, so there is the possibility that I am using incorrect arguments. If only the documentation and/or test units were more clear...
Re: Release D 2.067.0
On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: On Tue, 24 Mar 2015 21:56:29 +, Tove wrote: On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congrats! Although, I must admit, I was a little saddened to see that multiple alias this didn't make the release, I thought it was finalized... I should have kept a closer watch. and even single `alias this` is broken, so deadcode can't be build with 2.067. i told about that, but nobody cares, as usual. Was it filed at issues.dlang.org as a regression?
Unittests and windows application
I am currently porting a D1 application to D2. I am trying to take advantage of new language features but mostly of the new standard library features. The old application has several unit tests and I would like to have them executed to secure that everything works as expected. The problem with the unit tests is that they will be executed but I can not see the results because errors will be written to console output which is not available in a windows application. I did a little bit of research and found this two similar threads: - http://stackoverflow.com/questions/27580107/why-is-unit-testing-not-working-in-this-d-program - http://forum.dlang.org/thread/joiglupanlvejarms...@forum.dlang.org But they just explain why that does not work. Interestingly enough, the hint in the first thread to use the standard D main method instead of a WinMain (http://wiki.dlang.org/D_for_Win32) works for me. I just specify a *.def with SUBSYSTEM WINDOWS. Class runtime.d seems to contain the code that performs the unit tests: bool runModuleUnitTests() Runtime has a @property moduleUnitTester which can be set to a function that runs the unit test of a given module. If this is property is set it will be used otherwise a default test runner will be executed. This default test runner will report any error with the internal function void printErr(in char[] buf). The question is where should the error output go in a windows application. Possible solutions maybe: - write that to file similar to the code coverage *.lst - write it to windows debug view with win32: void OutputDebugStringA( LPCTSTR lpOutputString ) I will try set the modultUnitTester property and use OutputDebugView. Although, not very nice because a lot of code has to be copied. Are there any other options?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wed, 2015-03-25 at 14:00 -0700, Andrei Alexandrescu via Digitalmars-d-announce wrote: https://www.reddit.com/r/programming/comments/30ad8b/why_gos_design_is_a_disservice_to_intelligent/ Andrei The reaction in the Go community to this article has been exactly as one would have anticipated. I paraphrase the common theme thus: Go is successful in the market, D isn't, therefore Go is a better language than D. Go does indeed have much greater market penetration, but I leave it as an exercise for the reader to deduce the sophistry, and indeed casuistry, in most of the argumentation. Interestingly, or not, Erlang and Go are bringing better concurrency and parallelism to Java. If there was some design/programming resource, is would be good to revisit D's std.concurrency and std.parallelism, in the light of the fibres stuff, to do something not dissimilar to the Quasar framework so as to provide an integrated actor/dataflow/CSP/data parallelism framework for D. As GPars has shown, trying to do this stuff on volunteer labour alone just doesn't work. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
[Issue 14343] Postfix increment doesn't work on structs with immutable member
https://issues.dlang.org/show_bug.cgi?id=14343 Nicolas Sicard dran...@gmail.com changed: What|Removed |Added OS|Mac OS X|All Severity|enhancement |normal --
[Issue 14343] Postfix increment doesn't work on structs with immutable member
https://issues.dlang.org/show_bug.cgi?id=14343
--- Comment #1 from Nicolas Sicard dran...@gmail.com ---
The problem doesn't show with the old operator overloading methods:
struct S
{
int i;
immutable(Object) o;
void opAddAssign(int j) { i += j; }
S opPostInc() { ++i; return this; }
void opAssign(S other) {}
}
unittest
{
S s;
++s;
assert(s.i == 1);
s++;
assert(s.i == 2);
}
--
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote: On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: Downplaying other languages makes the D crowd look desperate... Heh, there were whole sites like phpain (can't find it now) and something similar for C++. It happens in the IDE world too. http://www.ihateeclipse.com/ As physics student new to programming I agree with most of the Go comments in the blog. bye, Amber
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
I wrote the article in a rush last night (girlfriend calling me to bed) and as a result it has a few spelling/grammar errors which I've hopefully corrected. The article is a total rant about Go after using it over the last month or so for a project. I honestly was getting so bored with Go and the article that I was literally falling asleep writing it. lol! Is started liking Go but after a while I found it increasing difficult trying to change me way of working to shoehorn solutions into such a simple language. I know it's a bit unfair in places and it's got a click bait title but who cares? I got my point across and I think people understand where i'm coming from. It seems to have got really popular and I've been swamped with mail, etc. I think it's the most read article i've ever written. ha! :o)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 00:08:28 UTC, bachmeier wrote: On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: Go has stability, is production ready and has an ecosystem with commercial value. You could say the same things about Cobol or PHP, but that doesn't mean the languages themselves should be free from criticism. There is a difference between claiming that language A makes this and that difficult and claiming that language B is better than A. To claim the latter you need to look at comparable larger real world programs and how it fares regarding scaling and maintainability issues. My opinion of Go was very much consistent with the article. It doesn't mean much to me to have a stable language that I don't want to use. His points are valid. I could easily make similar points about D and it's somewhat messed up type system, syntax and libraries. It would be quite easy to convincingly claim that C++/Go/Python are a better languages than D. The Go designers keep the language small and polish it to production quality before moving on with new features. Some of the Go designers also have acknowledged that exceptions and generics can be useful, but that they don't want to add features until they know it is the right thing to do and how to go about it. If you aren't making a research language (and D most certainly would fail in that arena) the only thing that matters is how it fares in a production setting by programmers who do full time programming in the language.
Re: Problem overloading operator for a struct with an immutable member
On Thu, 26 Mar 2015 09:02:53 +, Nicolas Sicard wrote:
On Thursday, 26 March 2015 at 04:57:55 UTC, ketmar wrote:
by the way. do you know that you still CAN overload postincrement
operation? yes, the code is still here, and it works...
somethimes. ;-)
Thnaks. Indeed, this works:
---
struct S {
int i;
immutable(Object) o;
void opAddAssign(int j) { i += j; }
S opPostInc() { ++i; return this; }
void opAssign(S other) {}
}
unittest {
S s;
++s;
assert(s.i == 1);
s++;
assert(s.i == 2);
}
---
Old operator overloading to the rescue !
just make sure you didn't add `opUnary` there, as it will kill
`opPostInc`.
it worth nothing that `opPostInc` is not deprecated yet. ;-)
signature.asc
Description: PGP signature
Re: Problem overloading operator for a struct with an immutable member
On Thu, 26 Mar 2015 09:17:21 +, ketmar wrote: worth nothing heh. my pet misspelling. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: Downplaying other languages makes the D crowd look desperate... Heh, there were whole sites like phpain (can't find it now) and something similar for C++.
Re: Problem overloading operator for a struct with an immutable member
On Thursday, 26 March 2015 at 04:57:55 UTC, ketmar wrote:
by the way. do you know that you still CAN overload
postincrement
operation? yes, the code is still here, and it works...
somethimes. ;-)
Thnaks. Indeed, this works:
---
struct S
{
int i;
immutable(Object) o;
void opAddAssign(int j) { i += j; }
S opPostInc() { ++i; return this; }
void opAssign(S other) {}
}
unittest
{
S s;
++s;
assert(s.i == 1);
s++;
assert(s.i == 2);
}
---
Old operator overloading to the rescue !
[Issue 14343] New: Postfix increment doesn't work on structs with immutable member
https://issues.dlang.org/show_bug.cgi?id=14343
Issue ID: 14343
Summary: Postfix increment doesn't work on structs with
immutable member
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dran...@gmail.com
struct S
{
int i;
immutable(Object) o;
S opUnary(string op)() { return this; }
void opAssign(S other) {}
}
void main()
{
S s, t;
t = s; // OK
++s; // OK
s++; // Error: cannot modify struct s S with immutable members
}
--
[Issue 14334] (D1 only) Forward reference error with method returning template instance equal to typeof(this)
https://issues.dlang.org/show_bug.cgi?id=14334 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com --- (In reply to Andrej Mitrovic from comment #4) (In reply to Kenji Hara from comment #3) (In reply to Andrej Mitrovic from comment #2) It's not fixed: http://dpaste.dzfl.pl/734b3b884325 It's using 2.065. Ah I'm soryr, I misread your comment as 2.055.1! :) Sorry even. --
[Issue 14334] (D1 only) Forward reference error with method returning template instance equal to typeof(this)
https://issues.dlang.org/show_bug.cgi?id=14334 --- Comment #4 from Andrej Mitrovic andrej.mitrov...@gmail.com --- (In reply to Kenji Hara from comment #3) (In reply to Andrej Mitrovic from comment #2) It's not fixed: http://dpaste.dzfl.pl/734b3b884325 It's using 2.065. Ah I'm soryr, I misread your comment as 2.055.1! :) --
[Issue 14341] [REG 2.067] Crash with -O -release -inline after sort and map!(to!string)
https://issues.dlang.org/show_bug.cgi?id=14341 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com --- Introduced in https://github.com/D-Programming-Language/dmd/pull/4415 --
Re: Release D 2.067.0
On Thu, 26 Mar 2015 10:13:42 +, John Colvin wrote: On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: On Tue, 24 Mar 2015 21:56:29 +, Tove wrote: On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congrats! Although, I must admit, I was a little saddened to see that multiple alias this didn't make the release, I thought it was finalized... I should have kept a closer watch. and even single `alias this` is broken, so deadcode can't be build with 2.067. i told about that, but nobody cares, as usual. Was it filed at issues.dlang.org as a regression? nope, it's not. i was asking for help in general (building minimised sample), but nobody was interested. neither do i, actually, as i believe that `alias this` is an abomination and ugly hack. maybe Kenji will fill the bug if he'll find a time for that. signature.asc Description: PGP signature
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote: On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: Downplaying other languages makes the D crowd look desperate... Heh, there were whole sites like phpain (can't find it now) and something similar for C++. The feature set of C++ does cause maintenance issues in real world codebases if you let programmers roam about freely and redefine the syntax/semantics. More so than C with it's limited feature set. Are you sure that D does not have similar issues? I have no idea how Go fares, but orthogonal simplicity could be an advantage in real world code bases where you read code other people have written/mutated. What I find interesting is that Python also has a feature set for redefining semantics that should cause C++ like issues. Still, I find most Python libraries I use to be fairly clean and intuitive. Maybe the fact that Python is untyped and non-performance-oriented makes programmers constrain themselves more from producing spaghetti libraries...?
Feature idea: scope (failure, ExceptionSpecification) for catching exceptions
One idea I'd like to see is to enhance scope(failure) to allow it to
catch a specific type of exception which would allow us to e.g. log
the exception message and potentially re-throw the exception. All of
this without having to nest our code in try/catch statements.
So instead of having code such as the following:
-
void test ( )
{
try
{
prepare();
foo();
finish();
try
{
prepare();
bar();
finish();
}
catch (MyException ex)
{
logger.log(bar() failed with: ~ ex.msg);
throw ex;
}
}
catch (MyException ex)
{
logger.log(foo() failed with: ~ ex.msg);
throw ex;
}
}
-
-
void test ( )
{
scope (failure, MyException ex)
{
logger.log(foo() failed with: ~ ex.msg);
throw ex;
}
prepare();
foo();
finish();
scope (failure, MyException ex)
{
logger.log(bar() failed with: ~ ex.msg);
throw ex;
}
prepare();
bar();
finish();
}
-
Granted it's not the best example out there, but I think it has
potential. Thoughts?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 06:05:25 UTC, ketmar wrote: On Wed, 25 Mar 2015 22:30:10 +, Ola Fosheim Grøstad wrote: Downplaying other languages makes the D crowd look desperate... and we are. see for example bug#14035. typesystem? lolwut, never heard about that thing! that's why i'd better report bugs directly to Kenji: he is a sane person. D most certainly needs stronger typing, not sure why it tries to propagate the weak typing of C. I find myself adding extra template parameters and explicit in my C++ code just to get stronger typing. New AoT languages ought to do better than C++. What Go really got right was to have untyped literals. If you combine that with a orthogonal weak-cast operator with pleasant syntax then you have something. Strong explicit typing also makes it possible to overload on return values... Something I really want to see in a C++ replacement language.
Re: Unittests and windows application
On Thursday, 26 March 2015 at 10:50:06 UTC, Vladimir Panteleev
wrote:
On Thursday, 26 March 2015 at 10:23:58 UTC, Stefan wrote:
..
That's a bug. You'll notice that if an exception is thrown in
main() (or anything called from it), you'll get a MessageBox
for GUI applications. That this doesn't also occur with
unittest failures is a bug.
Do you have the bug/issue number for that?
For now, you can work around this by writing your own WinMain,
which calls rt_runModuleUnitTests explicitly, inside a
try/catch block which will then display a MessageBox.
Hmm, that is what i tried to do, but the code in
Runtime.runModuleUnitTests() catches already all exceptions and
writes that to the console.
I have not found rt_runModuleUnitTests in the current D runtime
(2.067.0).
However, I was successful in setting the moduleUnitTester
property of Runtime. Inside my main module I do:
static this() {
Runtime.moduleUnitTester = unitTestRunner;
}
bool unitTestRunner() {
string line = ;
void printErr(in char[] buf) {
string message = to!string(buf);
if ( message == \n ) {
Logger.send( line );
line = ;
} else {
line ~= message;
}
}
size_t failed = 0;
foreach( m; ModuleInfo ) {
if( m ) {
auto fp = m.unitTest;
if( fp ) {
try {
fp();
} catch( Throwable e ) {
e.toString(printErr); printErr(\n);
failed++;
}
}
}
}
return failed == 0;
}
where the Logger.send() delegates to OutputDebugStringA().
Re: Unittests and windows application
On Thursday, 26 March 2015 at 10:23:58 UTC, Stefan wrote: I am currently porting a D1 application to D2. I am trying to take advantage of new language features but mostly of the new standard library features. The old application has several unit tests and I would like to have them executed to secure that everything works as expected. The problem with the unit tests is that they will be executed but I can not see the results because errors will be written to console output which is not available in a windows application. That's a bug. You'll notice that if an exception is thrown in main() (or anything called from it), you'll get a MessageBox for GUI applications. That this doesn't also occur with unittest failures is a bug. For now, you can work around this by writing your own WinMain, which calls rt_runModuleUnitTests explicitly, inside a try/catch block which will then display a MessageBox.
Re: DlangUI
On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - SNIP Hi Vadim, I have just installed the latest D 2.067.0, ran the git install and the build now fails. The errors are as follows: C:\D\dmd2\gui\dlanguidub run dlangui:example1 --build=release Building package dlangui:example1 in C:\D\dmd2\gui\dlangui\examples\example1\ Target gl3n 1.0.1 is up to date. Use --force to rebuild. Building dlib ~master configuration library, build type release. Running dmd... ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\image\io\jpeg.d(681): Warning: instead of C-style syntax, use D-style syntax 'ubyte[64] dezigzag' ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\filesystem\windows\directory.d(77): Error: undefin ed identifier wcslen FAIL ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\.dub\build\library-release-windows-x86-dmd_2067-17 3DBA1310DF90D85EA81F6AA09FBD95\ dlib staticLibrary Error executing command run: dmd failed with exit code 1. C:\D\dmd2\gui\dlangui any clues? Thanks. Regards, Mike.
Re: DlangUI
On Thursday, 26 March 2015 at 11:41:17 UTC, Mike James wrote: On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - SNIP Hi Vadim, I have just installed the latest D 2.067.0, ran the git install and the build now fails. The errors are as follows: C:\D\dmd2\gui\dlanguidub run dlangui:example1 --build=release Building package dlangui:example1 in C:\D\dmd2\gui\dlangui\examples\example1\ Target gl3n 1.0.1 is up to date. Use --force to rebuild. Building dlib ~master configuration library, build type release. Running dmd... ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\image\io\jpeg.d(681): Warning: instead of C-style syntax, use D-style syntax 'ubyte[64] dezigzag' ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\filesystem\windows\directory.d(77): Error: undefin ed identifier wcslen FAIL ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\.dub\build\library-release-windows-x86-dmd_2067-17 3DBA1310DF90D85EA81F6AA09FBD95\ dlib staticLibrary Error executing command run: dmd failed with exit code 1. C:\D\dmd2\gui\dlangui any clues? Thanks. Regards, Mike. Try `dub upgrade --force-remove` followed by `dub build --force`
Re: Linkage runaround
On 3/26/15 8:37 AM, Steve Teale wrote: If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo .../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone. It looks like you are missing a required library. Are you linking with ld? If so, make sure you run dmd with -v to see the link line it uses. -Steve
Linkage runaround
If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo ../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 12:27:14 UTC, Chris wrote: Further down the road, people will ask for more features in Go, and there will be patches and more patches, until we'll have Go++. Quite possible. Being open source it is quite likely that some outsiders create a go++. I can see that coming when/if they get their runtime up to snuff, it could be a promising starting point for new concurrent GC-based languages. Maybe even a starting point for a D3 language? This, or they won't get the features and move on to other language. Of course, Google is trying to prevent this by binding as many users as possible right now, so it will be hard to leave. The oldest trick in the IT hat. ... or Google abandons Go! Ha ha ha. Yeah, I doubt Google care about people leaving Go, or that they have invested all that much in Go. We'll have to keep in mind that they hire 1000s of programmers, spending a few on some experimental programming projects like Go and Dart is probably just reasonable RD. They also spend RD on Angular, Polymer, AtScript, the Closure-compiler, and a slew of other projects. As far as I am concerned Google don't back Go until it is fully supported on App Engine.
Re: std.typecons.Flag -- public import for API users?
On Tuesday, 24 March 2015 at 16:41:28 UTC, Rene Zwanenburg wrote: Should not be necessary. privately import Flag and make a public alias: module a; import std.typecons : Flag; alias SomeFlag = Flag!SomeFlag; SomeFlag.Yes and SomeFlag.No should be usable in other modules without additional imports. Nice idea Rene, thanks!
Re: Did D will try to get the vulkan opportunity?
On Wednesday, 25 March 2015 at 18:46:51 UTC, bioinfornatics wrote:
Dear,
I would like to know if D dev have a plan with vulkan :
https://www.khronos.org/vulkan/ ?
D lang will be at same level than others language, nothing
exists !
D could try to provide API and an environment around vulkan. To
become a language need to be used in this field.
Regards
I'm very excited about the movement in the graphics API space to
provide a better abstraction over the modern GPUs.
I was planning to make a Mantle binding when the SDK was to be
released (because it would be at least 90% the same as Vulkan,
minus the SPIR-V), and I also wanted to get my hands dirty
earlier), but unfortunately AMD announced that they will be
releasing only the spec.
Well they've now released[1] the spec and I couldn't resist
reading it.
I was very (pleasantly) surprised with how little AMD specific
stuff it has in it. Actually it is divided into core Mantle and
AMD extentions and the core part is pretty generic because it has
to support different GPUs, different OSes and different driver
versions. For example you need to query the API at runtime for
the size of the objects, their alignment requirements, their
preferred placement in one of the (possibly several) memory heaps
and so on. At the initialization of the API you can provide your
custom allocation and deallocation functions.
Since it is pure C API the obvious things that a D binding can do
better are:
+ use slices were the API expects a pointer and size
+ functions like grGetObjectInfo[2] can be templated on the
GR_INFO_TYPE enum, so you won't have to manually provide the
value of pDataSize and and the D binding will automatically
assert/enforce that pDataSize bytes has been written.
+ various other CTFE automation of the quite verbose C API.
+ overall the API is UFCS friendly - for example [3] can be
written in D as [4].
+ the one thing that can be potentially higher impact is to able
to compile D code to SPIR-V (maybe doable via CTFE DSL, but it
probably better if we can use the LLVM or GCC backends). There is
a C++14 subset that you can use in OpenCl 2.1 C++. We can do
probably something similar with D.
The moment a working Vulkan SDK is released I will try to make a
D binding. I expect that other people from the D community are
also interested in this, so you can sure there will be at least a
DerelictVulkan ;)
[1]:
http://www.amd.com/en-us/innovations/software-technologies/technologies-gaming/mantle#downloads
[2]: GR_RESULT grGetObjectInfo(
GR_BASE_OBJECT object,
GR_ENUM infoType,
GR_SIZE* pDataSize,
GR_VOID* pData);
[3]:
// This is C code
#includegr //mantle or vulkan
result = grCreateCommandBuffer(device, cmdBufInfo, cmdBuffer);
// Start building command buffer, optimize fo single time
submittion
result = grBeginCommandBuffer(
cmdBuffer,
GR_CMD_BUFFER_OPTIMIZE_ONE_TIME_SUBMIT);
// Record command buffer commands
grCmdSetEvent(cmdBuffer, event);
// Finish recording
grEndCommandBuffer(cmdBuffer);
[4]:
// This is D code
import gr; // this our Mantle or Vulkan wrapper module
// Return a new CmdBuffer instance by value, since it is
(probably)
// not much larger than a handle.
// Pass a CmdBufInfo by ref, or expand the members
// of the struct as parameters to
// device method (in semi-OOP terminology).
// The wrapper function asserts that the GR_RESULT is GR_SUCCESS
// since it is probably a logic error that we have provided
// invalid arguments, and we are not Go fanboys obsessed with
// checking error codes :-D
auto cmdBuffer = device.createCommandBuffer(cmdBufInfo);
// The rest is UFCS + scope statement + style
// changes (to make it more friendly-looking).
{
cmdBuffer.beginRecording(CmdBufUsage.oneTimeSubmit);
scope(exit) cmdBuffer.endRecording();
cmdBuffer.setEvent(event);
}
Re: Release D 2.067.0
On Thursday, 26 March 2015 at 11:25:50 UTC, ketmar wrote: On Thu, 26 Mar 2015 10:13:42 +, John Colvin wrote: On Thursday, 26 March 2015 at 06:16:59 UTC, ketmar wrote: On Tue, 24 Mar 2015 21:56:29 +, Tove wrote: On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin Congrats! Although, I must admit, I was a little saddened to see that multiple alias this didn't make the release, I thought it was finalized... I should have kept a closer watch. and even single `alias this` is broken, so deadcode can't be build with 2.067. i told about that, but nobody cares, as usual. Was it filed at issues.dlang.org as a regression? nope, it's not. i was asking for help in general (building minimised sample), but nobody was interested. neither do i, actually, as i believe that `alias this` is an abomination and ugly hack. maybe Kenji will fill the bug if he'll find a time for that. This is (one of the many reasons) why we can't have nice things. You knew there was a regression and you didn't report it. A report without a minimised example is still better than no report at all, especially if it's a regression!
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 10:07:07 UTC, Hugo wrote:
If only the documentation and/or test units were more clear...
OK, I made a simpler test, using an example from the
documentation:
void main() {
import std.stdio, std.array, std.bitmanip;
auto buffer = appender!(const ubyte[])();
buffer.append!ushort(261);
assert(buffer.data == [1, 5]);
writefln(%s, buffer.data);
}
It seems to work, so apparently one has to explicitly create a
buffer with the appender template. Not terribly useful IMHO.
Wouldn't it be possible for the append function to automaticaly
change the mode of an already existing buffer?
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes of
invocation...
Re: problems with std.bitmanip.append (bug?)
On 3/26/15 6:07 AM, Hugo wrote: On Thursday, 26 March 2015 at 02:39:56 UTC, Steven Schveighoffer wrote: An array as an output range writes to the front. You can use std.array.Appender to get appending behavior. I know, it's weird. Alternatively, you can add more bytes to the array, and append to the slice, but that may be ugly/hard to do. Hmm... isnt that't what the std.bitmanip.write function is for? It even provides an index. Quite possibly write and append do the same thing for arrays because of the way slices support the output range idiom. Perhaps I have found a bug. Actually I am not sure because I am not yet familiar with the way to use templates, so there is the possibility that I am using incorrect arguments. No, it's not a bug. A slice does not support appending in the way you expect as an output range. Think of a slice/array as a buffer in which to put information, maybe it's a stack buffer. If you output to this buffer, you wouldn't expect it to allocate more memory and append to the end would you? Instead, you'd expect to write data starting at the beginning. If you want append behavior, use std.array.Appender, as is described in the example of std.bitmanip.append. I do, however, think that the term append is very misleading. If it were named putInto, that might have been a less confusing term. -Steve
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 11:29:20 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 March 2015 at 10:17:42 UTC, Kagamin wrote: On Wednesday, 25 March 2015 at 22:30:15 UTC, Ola Fosheim Grøstad wrote: Downplaying other languages makes the D crowd look desperate... Heh, there were whole sites like phpain (can't find it now) and something similar for C++. The feature set of C++ does cause maintenance issues in real world codebases if you let programmers roam about freely and redefine the syntax/semantics. More so than C with it's limited feature set. Are you sure that D does not have similar issues? I have no idea how Go fares, but orthogonal simplicity could be an advantage in real world code bases where you read code other people have written/mutated. What I find interesting is that Python also has a feature set for redefining semantics that should cause C++ like issues. Still, I find most Python libraries I use to be fairly clean and intuitive. Maybe the fact that Python is untyped and non-performance-oriented makes programmers constrain themselves more from producing spaghetti libraries...? Further down the road, people will ask for more features in Go, and there will be patches and more patches, until we'll have Go++. This, or they won't get the features and move on to other language. Of course, Google is trying to prevent this by binding as many users as possible right now, so it will be hard to leave. The oldest trick in the IT hat. ... or Google abandons Go! Ha ha ha.
Re: problems with std.bitmanip.append (bug?)
On Thursday, 26 March 2015 at 12:21:23 UTC, Hugo wrote:
On Thursday, 26 March 2015 at 10:07:07 UTC, Hugo wrote:
If only the documentation and/or test units were more clear...
OK, I made a simpler test, using an example from the
documentation:
void main() {
import std.stdio, std.array, std.bitmanip;
auto buffer = appender!(const ubyte[])();
buffer.append!ushort(261);
assert(buffer.data == [1, 5]);
writefln(%s, buffer.data);
}
It seems to work, so apparently one has to explicitly create a
buffer with the appender template. Not terribly useful IMHO.
Wouldn't it be possible for the append function to automaticaly
change the mode of an already existing buffer?
Also, can anyone provide a similar example but using little
endian order? If only to contrast differences between modes of
invocation...
void main() {
import std.stdio, std.array, std.bitmanip, std.system;
auto buffer = appender!(const ubyte[])();
buffer.append!(ushort, Endian.littleEndian)(261);
assert(buffer.data == [5, 1]);
writefln(%s, buffer.data);
}
Re: DlangUI
On Thursday, 26 March 2015 at 11:47:59 UTC, Vadim Lopatin wrote: On Thursday, 26 March 2015 at 11:41:17 UTC, Mike James wrote: On Tuesday, 20 May 2014 at 18:13:36 UTC, Vadim Lopatin wrote: Hello! I would like to announce my project, DlangUI library - SNIP Hi Vadim, I have just installed the latest D 2.067.0, ran the git install and the build now fails. The errors are as follows: C:\D\dmd2\gui\dlanguidub run dlangui:example1 --build=release Building package dlangui:example1 in C:\D\dmd2\gui\dlangui\examples\example1\ Target gl3n 1.0.1 is up to date. Use --force to rebuild. Building dlib ~master configuration library, build type release. Running dmd... ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\image\io\jpeg.d(681): Warning: instead of C-style syntax, use D-style syntax 'ubyte[64] dezigzag' ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\dlib\filesystem\windows\directory.d(77): Error: undefin ed identifier wcslen FAIL ..\..\..\..\Users\mikej\AppData\Roaming\dub\packages\dlib-master\.dub\build\library-release-windows-x86-dmd_2067-17 3DBA1310DF90D85EA81F6AA09FBD95\ dlib staticLibrary Error executing command run: dmd failed with exit code 1. C:\D\dmd2\gui\dlangui any clues? Thanks. Regards, Mike. Try `dub upgrade --force-remove` followed by `dub build --force` Thanks Vadim, That did the trick. regards, -=mike=-
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/26/2015 8:53 PM, Laeeth Isharc wrote: It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). Feynman's books are all worth reading, even if you have no interest in physics. His attitude about things is just a marvel. I once had a roundtable discussion with the question if you could resurrect any historical figure, who would it be? I nominated Feynman, and that pretty much ended the discussion :-) nobody could think of anyone more appropriate. So yeah, I definitely take inspiration from him.
[Issue 1759] Closures and With Statements
https://issues.dlang.org/show_bug.cgi?id=1759 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/38d906b8366a881d19a7f9267b536d372409da31 fix Issue 1759 - Closures and With Statements https://github.com/D-Programming-Language/dmd/commit/a1d857a4f46aa21722712c3014fd40c978ee28c5 Merge pull request #4518 from 9rnsr/fix1759 Issue 1759 - Closures and With Statements --
[Issue 14344] [REG2.067] Wrong opBinary call in construction
https://issues.dlang.org/show_bug.cgi?id=14344 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a39502dad3138bc911a7c092a38bc095dbd91227 fix Issue 14344 - Wrong opBinary call in construction https://github.com/D-Programming-Language/dmd/commit/1139c4298507a1aa0676e76059d491c6158a6f74 Merge pull request #4519 from 9rnsr/fix14344 [REG2.067] Issue 14344 - Wrong opBinary call in construction --
Re: readln() doesn't stop to read the input.
but readln(p); isn't supposed to read input and store it into p?
Re: Why dont dlang check NullPointer?
Is there any other ways? http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ There is a hook in the runtime to enable this if you want. I will try this black magic,Thanks.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Friday, 27 March 2015 at 01:47:57 UTC, Walter Bright wrote: On 3/26/2015 12:40 PM, Russel Winder via Digitalmars-d-announce wrote: (Almost) All publicity is good publicity. I attended a presentation at NWCPP on Go last week. I have never written a Go program, so filter my opinion on that. It seems to me that every significant but one feature of Go has a pretty much direct analog in D, i.e. you can write Go code in D much like you can write C code in D. The one difference was Go's support for green threads. There's no technical reason why D can't have green threads, it's just that nobody has written the library code to do it. vibe has (experimental?) green threads, doesn't it? I don't keep up with vibe, so I may be wrong.
Re: Unittests and windows application
On Thursday, 26 March 2015 at 13:57:31 UTC, Kagamin wrote: Maybe, it's possible to redirect output explicitly? myapp.exe output.txt 2errors.txt Unbelievable, it is really as simple as this.
[Issue 13983] RefCounted needs to be pure, @safe, nothrow
https://issues.dlang.org/show_bug.cgi?id=13983 weaselcat r9shacklef...@gmail.com changed: What|Removed |Added CC||r9shacklef...@gmail.com --- Comment #1 from weaselcat r9shacklef...@gmail.com --- ping, this requires a safe wrapper around malloc/free right? --
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
That kind of articles are bad for the image of the D community Nick S: No. Just...no. I'm honestly *really* tired of general society's (seemingly?) increasing intolerance FOR intolerance. Some things ARE bad. Some ideas are dumb ideas (ie without merit). Some features are bad features. Some products really are crappy products. Calling it out when you see it, using a frank explanation of your reasoning, isn't bad, it's productive. Excellence is incompatible with tolerating mediocrity or what is appalling, and what I have seen is that there are aesthetic aspects to creative endeavours not conventionally thought of as having an aesthetic element, and it is in the nature of such things that one cannot and should not tolerate what one perceives to be ugly in a creative endeavour. If one is driven mostly by ROI rather than high feelings, one doesn't get to excellence. So it is my belief that dealing with creative people means dealing with a certain ... intensity. That (on the aesthetic aspects of technical fields) is not just my opinion, but also (I think) that of a certain Mr W Bright, judging by his comments on how good code should look and on good aircraft design, although he presented this in his usual low-key manner. I was looking for a language that was beautiful, as well as powerful, and for whatever it is worth, this was a factor of high appeal with D. It's also the view of Feynman, not to mention many great minds of the past. Ie it is limiting to insist on data before forming a strong opinion about something (which is not to say that one may not change one's mind in the face of contrary data). You can recognize truth by its beauty and simplicity. When you get it right, it is obvious that it is right—at least if you have any experience—because usually what happens is that more comes out than goes in. ...The inexperienced, the crackpots, and people like that, make guesses that are simple, but you can immediately see that they are wrong, so that does not count. Others, the inexperienced students, make guesses that are very complicated, and it sort of looks as if it is all right, but I know it is not true because the truth always turns out to be simpler than you thought. - Feynman via Wikiquote (but the same idea comes across in his books). To discourage dissent, objections, or complaints is to rob ourselves of potential improvement. *That's* what critique and complaints and objections ARE: Recognition of the potential for improvement. There *cannot* be progress and improvement without first identifying existing faults. If nobody ever identified and voiced criticism of punchcards, for example, we'd all still be stuck in the world of 1950's computing. Excellently put. (And, I would add, a constructive draw towards what is generative - not just fault-finding). It's not as if the D crowd doesn't critique itself and it's own language just plenty, so it's not like there's any hypocrisy here. And I'm certainly not willing to accept that programmers should be viewed as being part of distinct mutually-exclusive factions based on some single-language allegiance. I'm a D guy. I also happen to be a fan of Nemerle. And both languages have things I hate. So scratch the it's the D crowd idea. Interesting - what should I read about Nemerle, and what is it best at ? And seriously, the article in question barely mentions D at all. So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. There are some very interesting psychological dynamics in the reaction to this kind of piece. For me it was key that although it was clearly written in a humorous tone, and hurriedly, he seemed to speak from the heart - it is refreshing to see such work even when one doesn't agree with it. BTW since when has linking to something been an endorsement of it?
Re: readln() doesn't stop to read the input.
On Friday, 27 March 2015 at 04:37:34 UTC, jonaspm wrote: Please, i need your help, I tried this: write(Write p: ); readln(p); p = chomp(p); writeln(Write q: ); readln(q); q = chomp(q); but the result is: Write p: Write q: and doesn't pause to read keyboard input... what's wrong? Thanks in advance! http://dlang.org/phobos/std_stdio.html#.readln Check the example, and you will see the problem. readln(p) doesn't read what was typed into p.
Re: Why dont dlang check NullPointer?
On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote: The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers. But this will make the developement more difficult for me, or not acceptable. Is there any other ways? http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ There is a hook in the runtime to enable this if you want. BUT, null pointer exception or not, Adam is right. Have your stuff run in multiple process that you can restart. This is more reliable, this is more secure, this is easier to update without downtime, and so on... This is far superior solution for server stuff.
Re: Why dont dlang check NullPointer?
The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers. But this will make the developement more difficult for me, or not acceptable. Is there any other ways?
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 19:37:30 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 March 2015 at 19:16:54 UTC, bachmeier wrote: You're making a big assumption about which programmers and projects count and which don't. I wonder if outside of Google It doesn't matter what the programmers think, what matters is how the development environment affects the project in measurable terms. Having all kinds of features does not necessarily benefit projects. That's the difference between a fun toy language and one aiming for production and maintenance. Programming is - for now - still a human activity, and what is important in human activities may not always be measured, and what may be easily measured is not always important. That doesn't mean one should throw away the profiler and go back to guessing, but it does suggest caution about adopting the prestigious techniques of the natural sciences and applying them to a domain where they don't necessarily fully belong. I say this as someone coming from the financial markets, where we have all experienced quite recently the effects of mistaking being quantitative for thinking soundly - what happened ought not to have been a surprise, and of those who saw 2008 coming and spoke publicly about it, I don't think a single one based their view on the quant especially. Yet the field of macroeconomics is much more fully developed than that of assessing programmer productivity and quality of output. It is not scientific to depend on an approach that has not yet proven itself in practical terms over the course of time and in different environments. http://en.wikipedia.org/wiki/Scientism http://plato.stanford.edu/entries/feyerabend/ Laeeth.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 3/26/2015 7:06 PM, weaselcat wrote: vibe has (experimental?) green threads, doesn't it? I don't keep up with vibe, so I may be wrong. I don't know, but if it does have good 'uns they should be moved into Phobos!
readln() doesn't stop to read the input.
Please, i need your help, I tried this: write(Write p: ); readln(p); p = chomp(p); writeln(Write q: ); readln(q); q = chomp(q); but the result is: Write p: Write q: and doesn't pause to read keyboard input... what's wrong? Thanks in advance!
[Issue 14344] [REG2.067] Wrong opBinary call in construction
https://issues.dlang.org/show_bug.cgi?id=14344 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 8234] symbols used in CTFE affect the function literal type
https://issues.dlang.org/show_bug.cgi?id=8234 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/cd3cd0dc66dbc40b9666a3b2b2b8efde8c0e0216 fix Issue 8234 - symbols used in CTFE affect the function literal type https://github.com/D-Programming-Language/dmd/commit/c420fa1f642bfcb2aa0ba4bf7778b9c34465131b Merge pull request #4517 from 9rnsr/fix8234 Issue 8234 - symbols used in CTFE affect the function literal type --
Re: Why dont dlang check NullPointer?
On Friday, 27 March 2015 at 04:13:01 UTC, deadalnix wrote: On Friday, 27 March 2015 at 03:59:30 UTC, zhmt wrote: The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers. But this will make the developement more difficult for me, or not acceptable. Is there any other ways? http://www.deadalnix.me/2012/03/24/get-an-exception-from-a-segfault-on-linux-x86-and-x86_64-using-some-black-magic/ There is a hook in the runtime to enable this if you want. BUT, null pointer exception or not, Adam is right. Have your stuff run in multiple process that you can restart. This is more reliable, this is more secure, this is easier to update without downtime, and so on... This is far superior solution for server stuff. multi-process means crashes are isolated by process, but isolated by thread may be more handy. For example , this feature is suported by java c# lua, ie. This can make dlang app developed by most developers more reliable.
Re: Why dont dlang check NullPointer?
On Friday, 27 March 2015 at 03:46:49 UTC, zhmt wrote: The code above will not print a exception message, but crashes instead. It actually will throw on Windows and can be tricked into it on Linux; it is an operating system thing more than a language thing. But... If null exception happens, I hope the server continue running, not crash. If the server continue running, the functions offered by old modules can be used by users, only the new module stop serving. The best way to do that is to separate the server modules into independent processes. Then if one crashes, the others keep running without fear of corruption. So instead of server modules, try doing mini servers that communicate with the main server. This is how a lot of newer programs are written because of the reliability and security benefits it offers.
Why dont dlang check NullPointer?
class A
{
void test()
{
writeln(test);
}
}
try
{
A a = null;
a.test();
}catch(Throwable t)
{
writeln(t.msg);
}
The code above will not print a exception message, but crashes
instead.
I dont think this a good choice for most scenes. For example,I
developed many modules in my server, and add a new module now. If
null exception happens, I hope the server continue running, not
crash. If the server continue running, the functions offered by
old modules can be used by users, only the new module stop
serving.
In short words, I want to catch something like
NullPointerException.
Is this possible?
Re: Looking for a little help with the win32 headers
On Friday, 27 March 2015 at 01:27:25 UTC, Belly wrote: If anyone reading this can save me some time and help me with this: How to declare a byte pattern, for example to pass to WriteProcessMemory? I guess it's uint[] bytes; How do I set it to 0x12345678 ? Since WriteProcessMemory accepts a LPCVOID (that is const void*), you can use any type of array (provided that you will take care of endianess): uint[] ints = [0x12345678]; ushort[] shorts = [0x1234, 0x5678]; ubyte[] bytes = [0x12, 0x34, 0x56, 0x78]; WriteProcessMemory(processHandle, address, ints.ptr, ints.length * 4 null); WriteProcessMemory(processHandle, address, shorts.ptr, shorts.length * 2, null); WriteProcessMemory(processHandle, address, bytes.ptr, bytes.length, null);
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/26/2015 04:44 AM, Gary Willoughby wrote: I wrote the article in a rush last night (girlfriend calling me to bed) and as a result it has a few spelling/grammar errors which I've hopefully corrected. The article is a total rant about Go after using it over the last month or so for a project. I honestly was getting so bored with Go and the article that I was literally falling asleep writing it. lol! Is started liking Go but after a while I found it increasing difficult trying to change me way of working to shoehorn solutions into such a simple language. I know it's a bit unfair in places and it's got a click bait title but who cares? I got my point across and I think people understand where i'm coming from. It seems to have got really popular and I've been swamped with mail, etc. I think it's the most read article i've ever written. ha! :o) It's funny how the posts that people love to hate are the biggest successes. On my site, I've made probably about about a hundred or so posts, but by FAR the most popular one based on hits and number of comments (in fact one of the very few that ever gets any hits/comments *at all*), was the one where I just bitched and ranted and swore and vented all about dynamic languages and especially Python. Heck, I got as much appreciative comments as I did disapproving ones. And more still roll in now and then. I really need to put up an ad there ;) But it really is true, controversy sells. Of course I'm not saying that makes trolling good (although I'm absolutely *amazed* that so many on reddit actually see your article as trolling - it obviously isn't, they clearly didn't even read it. Some of them even think *you're* the one who's calling many programmers lesser rather than Rob Pike), but it's amazing how much dissonance there is between what people think they hate to read and what they reward with their time and energy and comments. Oh, also, I wanted to point out one other thing. On a modern net where sites that look like this are common: http://thedailywtf.com/articles/are-you-down-with-php- http://thedailywtf.com/series/code-sod The visual style on your site is refreshingly easy to look at and read.
Re: Looking for a little help with the win32 headers
On Thursday, 26 March 2015 at 16:46:06 UTC, Belly wrote:
No, wait, the first code is even better because it uses the
headers so I don't need to declare the API myself and it uses
the MAX_COMPUTERNAME_LENGTH define, too, nice!
Using this will return only the first 15 characters of the
computer name, if longer.
Please use the unicode version of the function GetComputerNameW
instead of the ANSI one (GetComputerNameA), because the second
one has a known bug, returning always 0 as required buffer size.
import std.stdio;
import std.c.windows.windows;
wstring getComputerName()
{
enum ERROR_BUFFER_OVERFLOW = 111;
uint size;
if (GetComputerNameW(null, size) == 0 GetLastError() ==
ERROR_BUFFER_OVERFLOW)
{
wchar[] buf = new wchar[size];
if (GetComputerNameW(buf.ptr, size))
return buf[0 .. size].idup;
}
return Unknown;
}
int main(string[] argv)
{
writeln(getComputerName());
getchar();
return 0;
}
Re: Feature idea: scope (failure, ExceptionSpecification) for catching exceptions
I think I'd tend towards not adding this feature. It seems like it's just a logging problem, and try-catch is probably enough for that.
Re: Linkage runaround
On Thursday, 26 March 2015 at 13:17:04 UTC, Steven Schveighoffer wrote: On 3/26/15 8:37 AM, Steve Teale wrote: If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo .../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone. It looks like you are missing a required library. Are you linking with ld? If so, make sure you run dmd with -v to see the link line it uses. Telling the linker to use the dynamic linking so - on Ubuntu, that appears to be /lib/i386-linux-gnu/ld-linux.so.2 - makes no difference. -Steve
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Wednesday, 25 March 2015 at 23:00:32 UTC, bearophile wrote: Ola Fosheim Grøstad: Downplaying other languages makes the D crowd look desperate... That kind of articles are bad for the image of the D community (and the D code shown in that article is not the best). Bye, bearophile I don't think it's that bad. The general sentiment in the comments seems to agree with the article despite (or because of) its strong opinionation, and apparently this is the most popular article Gary has ever written, which is good publicity for D.
Re: Class Hierarchy Graphs
On Thursday, 26 March 2015 at 17:41:58 UTC, w0rp wrote:
Hello everyone. I was talking in the IRC channel today and I
mentioned something small I wrote a couple of years ago which
generates a Graphviz DOT file based on ModuleInfo, so you can
see a visual class hierarchy with interfaces included. There
was some interest in this in the channel at the time.
The code doesn't do much more than that at the moment, it could
offer a few more options including outputing the hierarchy in
other formats, and the graph it generates could perhaps look
better. I'm just wondering if anyone here is interested in
having a tool like this.
If enough people are interested and have a few suggestions for
some features they like which aren't crazy massive feature
lists, I'd be willing to expand it a bit, add some
documentation, and offer it as a DUB package.
+1
How much of a stretch would it be to extend the dependency graph
to compositional types?
struct Foo {
mixin Bar!(a,b,c);
}
alias Qux = Baz!Foo;
and so on?
Class Hierarchy Graphs
Hello everyone. I was talking in the IRC channel today and I mentioned something small I wrote a couple of years ago which generates a Graphviz DOT file based on ModuleInfo, so you can see a visual class hierarchy with interfaces included. There was some interest in this in the channel at the time. The code doesn't do much more than that at the moment, it could offer a few more options including outputing the hierarchy in other formats, and the graph it generates could perhaps look better. I'm just wondering if anyone here is interested in having a tool like this. If enough people are interested and have a few suggestions for some features they like which aren't crazy massive feature lists, I'd be willing to expand it a bit, add some documentation, and offer it as a DUB package.
Re: Class Hierarchy Graphs
On Thursday, 26 March 2015 at 17:41:58 UTC, w0rp wrote: Hello everyone. I was talking in the IRC channel today and I mentioned something small I wrote a couple of years ago which generates a Graphviz DOT file based on ModuleInfo, so you can see a visual class hierarchy with interfaces included. There was some interest in this in the channel at the time. The code doesn't do much more than that at the moment, it could offer a few more options including outputing the hierarchy in other formats, and the graph it generates could perhaps look better. I'm just wondering if anyone here is interested in having a tool like this. If enough people are interested and have a few suggestions for some features they like which aren't crazy massive feature lists, I'd be willing to expand it a bit, add some documentation, and offer it as a DUB package. I forgot to link the GitHub repository. Here it is. https://github.com/w0rp/dhier
Re: Class Hierarchy Graphs
On Thursday, 26 March 2015 at 17:43:46 UTC, Vlad Levenfeld wrote:
+1
How much of a stretch would it be to extend the dependency
graph to compositional types?
struct Foo {
mixin Bar!(a,b,c);
}
alias Qux = Baz!Foo;
and so on?
I'm not sure about that. I'd have to think about it a bit.
Templates are probably trickier.
Someone else has also suggested module dependency graphs. I could
maybe offer something for that too.
Re: Looking for a little help with the win32 headers
No, wait, the first code is even better because it uses the headers so I don't need to declare the API myself and it uses the MAX_COMPUTERNAME_LENGTH define, too, nice!
Re: Digger 1.1
On 2015-03-25 20:19:53 +, Vladimir Panteleev said: OK, let me know. Might be better to take this discussion to a GitHub issue. https://github.com/CyberShadow/Digger/issues 2.067.0 can be build and installed without any problems. So, I don't think an issue is necessary. Keep up the good work. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: need help with CTFE
On Thursday, 26 March 2015 at 16:19:17 UTC, Dmitri Makarov wrote:
When I compile version DOES_NOT_WORK, I get the following error:
c/tool.d(13): Error: variable name cannot be read at compile
time
c/tool.d(13):while looking for match for
hasMember!(Tool, name)
However, the other version ('else' case) compiles, runs, and
outputs (as expected):
this is a screwdriver.
unknown tool transmogrifier.
What's the fundamental difference that makes the variable
'name' readable in one version and unreadable in another?
Should the version DOES_NOT_WORK not be compilable in principle
or is it only a limitation of the current CTFE implementation
in the front-end?
In DOES_NOT_WORK you're trying to pass `name` in a template value
parameter. You cannot do that, because `name` is a dynamic
value but you can only pass a static value there. (There may
be better terms than dynamic/static value.)
You may think: But it all happens in CTFE, so all values are
compile time values or static values, aren't they?
They aren't. The semantics during CTFE are the same as for run
time. `name` is still a dynamic value. If it doesn't fly for run
time execution, it doesn't fly in CTFE.
To solve the problem at hand, here's one solution that's similar
to what you tried:
string generate()
{
import std.traits : isCallable;
foreach(memberName; __traits(allMembers, Tool))
{
if(memberName == name)
{
alias M = typeof(mixin(this. ~ memberName));
static if(isCallable!M)
{
return `writeln(this is a ` ~
mixin(this. ~ memberName ~ ()) ~
`.);`;
}
}
}
return `writeln(unknown tool ` ~ name ~ `.);`;
}
The foreach is (implicitly) a 'static' one, because
__traits(allMembers, ...) results in a static/type/expression
tuple (I don't know what's the best name to set it apart from
other kinds of tuples).
That means, `memberName` is a static value. And so it can be used
in mixin, whereas `name` cannot be used there.
need help with CTFE
I'm compiling the following application (2 d modules)
// file c/tool.d
module c.tool;
struct Tool
{
string name;
auto generate()
{
version (DOES_NOT_WORK)
{
import std.traits : hasMember;
if (hasMember!(Tool, name))
return `writeln(this is a ` ~ mixin (this. ~ name ~
()) ~ `.);`;
}
else
{
if (name == hammer)
return `writeln(this is a ` ~ this.hammer() ~ `.);`;
}
return `writeln(unknown tool ` ~ name ~ `.);`;
}
auto hammer()
{
return screwdriver;
}
}
string code(string input)
{
auto tool = Tool(input);
return tool.generate();
}
-
// file x/app.d
class Application
{
void run()
{
import c.tool;
import std.stdio;
mixin (code(hammer));
mixin (code(transmogrifier));
}
}
int main(string[] args)
{
auto app = new Application();
app.run();
return 0;
}
When I compile version DOES_NOT_WORK, I get the following error:
c/tool.d(13): Error: variable name cannot be read at compile time
c/tool.d(13):while looking for match for hasMember!(Tool,
name)
However, the other version ('else' case) compiles, runs, and
outputs (as expected):
this is a screwdriver.
unknown tool transmogrifier.
What's the fundamental difference that makes the variable 'name'
readable in one version and unreadable in another? Should the
version DOES_NOT_WORK not be compilable in principle or is it
only a limitation of the current CTFE implementation in the
front-end?
Thanks.
Re: Looking for a little help with the win32 headers
Thank you guys, I tried the second reply and it works great!
Re: need help with CTFE
On Thursday, 26 March 2015 at 17:30:40 UTC, anonymous wrote: value parameter. You cannot do that, because `name` is a dynamic value but you can only pass a static value there. (There may be better terms than dynamic/static value.) Thank you, anonymous. It makes sense. I guess rather than static/dynamic, I would think of known/unknown at compile-time. In this case, 'if (name == hammer)' seems no more static or less dynamic than 'hasMember!(Tool, name)'. Nevertheless, I appreciate your help and will use the solution that you offered.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thu, 2015-03-26 at 12:33 -0700, Walter Bright via Digitalmars-d-announce wrote: On 3/26/2015 1:44 AM, Gary Willoughby wrote: I know it's a bit unfair in places and it's got a click bait title but who cares? I got my point across and I think people understand where i'm coming from. It seems to have got really popular and I've been swamped with mail, etc. I think it's the most read article i've ever written. ha! :o) You've managed to get 376 points and 663 comments, which is probably a record for any Reddit D related article! For better or worse, you've clearly struck a nerve. Welcome to the world of guerilla marketing. (Almost) All publicity is good publicity. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: How does the D compiler get updated on travis-ci.org?
On Thursday, 26 March 2015 at 19:31:44 UTC, Gary Willoughby wrote: Now that we have a new D compiler version released how does the D compiler on travis-ci.org get updated? I've recently fixed some issues (in my code) that were hampered by a bug in the last version. Now that it's fixed the older version on travis-ci.org is crashing because of it. I've raised an issue here: https://github.com/travis-ci/travis-ci/issues/3472 i think it is already available on travis. this it what works for me: https://github.com/Extrawurst/unecht/blob/master/.travis.yml ``` language: d d: - dmd-2.067.0 ```
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 19:16:54 UTC, bachmeier wrote: You're making a big assumption about which programmers and projects count and which don't. I wonder if outside of Google It doesn't matter what the programmers think, what matters is how the development environment affects the project in measurable terms. Having all kinds of features does not necessarily benefit projects. That's the difference between a fun toy language and one aiming for production and maintenance.
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: ...snip... So tl;dr; make the template constraints in ddoc less prominent? The new library reference preview under Resources seems to already have this (example: http://dlang.org/library/std/algorithm/searching/starts_with.html)
Re: Human unreadable documentation - the ugly seam between simple D and complex D
On 3/26/15 3:45 PM, Alex Parrill wrote: On Thursday, 26 March 2015 at 19:32:53 UTC, Idan Arye wrote: ...snip... So tl;dr; make the template constraints in ddoc less prominent? The new library reference preview under Resources seems to already have this (example: http://dlang.org/library/std/algorithm/searching/starts_with.html) Yes, it's so unprominent, I can't find it :) I don't think this was intentional... -Steve
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/25/2015 07:00 PM, bearophile wrote: Ola Fosheim Grøstad: Downplaying other languages makes the D crowd look desperate... That kind of articles are bad for the image of the D community No. Just...no. I'm honestly *really* tired of general society's (seemingly?) increasing intolerance FOR intolerance. Some things ARE bad. Some ideas are dumb ideas (ie without merit). Some features are bad features. Some products really are crappy products. Calling it out when you see it, using a frank explanation of your reasoning, isn't bad, it's productive. To discourage dissent, objections, or complaints is to rob ourselves of potential improvement. *That's* what critique and complaints and objections ARE: Recognition of the potential for improvement. There *cannot* be progress and improvement without first identifying existing faults. If nobody ever identified and voiced criticism of punchcards, for example, we'd all still be stuck in the world of 1950's computing. It's not as if the D crowd doesn't critique itself and it's own language just plenty, so it's not like there's any hypocrisy here. And I'm certainly not willing to accept that programmers should be viewed as being part of distinct mutually-exclusive factions based on some single-language allegiance. I'm a D guy. I also happen to be a fan of Nemerle. And both languages have things I hate. So scratch the it's the D crowd idea. And seriously, the article in question barely mentions D at all. So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. So he happens to also use D? So what? A lot of people use a lot of langauges. I'm sure the author's used more than just Go and D, too. That certainly doesn't make it one language attacking another. Maybe he's a fan of burritos, too. Maybe then we could take it as a ZOMG! The burrito enthusiasts are attacking golang!
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky wrote: So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. == digitalmars.D.announce
feature request for dlang.org library preview
So I just noticed, when I click on source code button for a function in dlang.org library preview, it brings me to the source code as of that release, but to the file itself (on github). I'd like it to go to the specific line where that function is defined instead. I'm not sure if we need updated output from dmd, or if this is all ddox, so I don't know where to file this feature request. Does one file ddox requests on issues.dlang.org? -Steve
Re: Class Hierarchy Graphs
On 3/26/15 10:41 AM, w0rp wrote: Hello everyone. I was talking in the IRC channel today and I mentioned something small I wrote a couple of years ago which generates a Graphviz DOT file based on ModuleInfo, so you can see a visual class hierarchy with interfaces included. There was some interest in this in the channel at the time. The code doesn't do much more than that at the moment, it could offer a few more options including outputing the hierarchy in other formats, and the graph it generates could perhaps look better. I'm just wondering if anyone here is interested in having a tool like this. If enough people are interested and have a few suggestions for some features they like which aren't crazy massive feature lists, I'd be willing to expand it a bit, add some documentation, and offer it as a DUB package. That would definitely be of interest. Also, if some of that can be reused to show inter-module dependencies that would be even better. Thanks! -- Andrei
Re: Release D 2.067.0
On Wednesday, 25 March 2015 at 21:13:14 UTC, Andrei Alexandrescu wrote: On 3/25/15 1:32 PM, Andrei Alexandrescu wrote: On 3/25/15 12:39 PM, Andrei Alexandrescu wrote: On 3/24/15 10:07 AM, Martin Nowak wrote: Glad to announce D 2.067.0. Spreading the news: [snip] Nice, we seem to be on HackerNews' front page: https://news.ycombinator.com/ And apparently we did something wrong - somehow we fell in minutes from position 11 to position 41. -- Andrei maybe people don't give a s**t? now over 80
Re: Did D will try to get the vulkan opportunity?
On Wednesday, 25 March 2015 at 18:46:51 UTC, bioinfornatics wrote:
Dear,
I would like to know if D dev have a plan with vulkan :
https://www.khronos.org/vulkan/ ?
D lang will be at same level than others language, nothing
exists !
D could try to provide API and an environment around vulkan. To
become a language need to be used in this field.
Regards
I'm not one of the D devs, but I'm working on a lib that builds
shaders from composable templates (in a very pre-alpha stage
still, but this is a tough thing to get right).
I was going to do GPGPU through openGL compute shaders, but as
soon as there are actual details on the Vulkan API, I will
probably go after that instead.
Maybe not what you were looking for, but if it works out, D will
be the only language that I know of with something like this.
What I mean by composable templates:
alias affine_transform = vertex_shader!(
`translation`, `rotation`, `scale`, q{
gl_Position.x = gl_Position.x * cos (rotation) -
gl_Position.y * sin (rotation);
gl_Position.y = gl_Position.x * sin (rotation) +
gl_Position.y * cos (rotation);
gl_Position.xy *= scale;
gl_Position.xy += translation;
}
);
and basically you tack stuff like that together using UFCS,
auto boxes = Lifetime.Shared!Texture (resolution)
.fill (transparent);
auto sq = square (1f).VertexBuffer;
borrow (sq).basic_shader (green (0.5))
.affine_transform (fvec (0, 0), 0,
(resolution[1]*1.5f/resolution[0])*vector (1f, 1f/3))
.line_loop.render_to (boxes);
and once you attach the shader to a canvas, it'll deduce the
argument types, generate the rest of the shader code, compile,
link, upload uniforms and attributes, and save the shader in a
global AA for recall in case you're visiting it in a loop. It's
designed to be as much like calling r.map!(x = ...) and friends
as possible; functional programming with the GPU.
Still working out how to get it to play nicely with compute
shaders (IO works differently than for regular shaders) but maybe
the Vulkan spec will reveal an easier way to unify them.
So, there you go; someday, it could be D's own ArrayFire +
graphics (with a good bit more work).
I've been incubating it as a private repo since its still so raw,
and I don't want to unveil before its ready and have it get a
reputation as being half-baked, but if there's legitimate
interest from people who have a good idea of what they would like
to see from a graphics/compute API of this nature, I can open it
up publicly. Or I can send invites, if anyone wants to help
incubate it by tossing use-cases my way, I'll gladly take them
and do my best to build this thing out to meet the needs.
Re: A reason to choose D over Go
On Saturday, 21 March 2015 at 23:14:58 UTC, Ola Fosheim Grøstad
wrote:
This is a funny workaround:
http://bouk.co/blog/idiomatic-generics-in-go/
And someone found a hole to implement it:
https://www.reddit.com/r/golang/comments/2hw356/idiomatic_generics_in_go/ckwpfms
The interpretation of the ImportPath is implementation-dependent
but it is typically a substring of the full file name of the
compiled package and may be relative to a repository of installed
packages. -- Go Spec
import (
templates.Map{int, string}
)
Hahahaha.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 08:53:31 UTC, Ola Fosheim Grøstad wrote: There is a difference between claiming that language A makes this and that difficult and claiming that language B is better than A. We have different interpretations of the article. My reading was I hate these properties of Go. If you aren't making a research language (and D most certainly would fail in that arena) the only thing that matters is how it fares in a production setting by programmers who do full time programming in the language. You're making a big assumption about which programmers and projects count and which don't. I wonder if outside of Google if there are even 100 programmers working full time exclusively with Go. I don't work full time with D, but I work with it a lot, and I don't see why my experience shouldn't count.
Re: A reason to choose D over Go
On Thursday, 26 March 2015 at 18:33:17 UTC, Jesse Phillips wrote:
import (
templates.Map{int, string}
)
Hahahaha.
It is crazy stuff like that that makes fringe languages more fun
to read about than the big serious ones. ;)
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/25/2015 11:11 PM, lobo wrote: Overall the blog post is a bit immature with little rigor and too much emotion. I can't comment on the accuracy of the comparisons, but FWIW, I'd take immature and emotional over dry, corporate and PC any day. :) Life's too short to be bland.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thu, 2015-03-26 at 14:37 -0400, Nick Sabalausky via Digitalmars-d-announce wrote: On 03/26/2015 04:38 AM, Russel Winder via Digitalmars-d-announce wrote: I paraphrase the common theme thus: Go is successful in the market, D isn't, therefore Go is a better language than D. I love how Go's very own reasoning there naturally suggests that PHP, C++, and Java must all be vastly superior to Go. Did I mention sophistry and casuistry? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
How does the D compiler get updated on travis-ci.org?
Now that we have a new D compiler version released how does the D compiler on travis-ci.org get updated? I've recently fixed some issues (in my code) that were hampered by a bug in the last version. Now that it's fixed the older version on travis-ci.org is crashing because of it. I've raised an issue here: https://github.com/travis-ci/travis-ci/issues/3472
Human unreadable documentation - the ugly seam between simple D and complex D
There is a discussion about D vs Go going on in several threads(yey for multithreading!), and one thread is about an article by Gary Willoughby that claims that Go is not suitable for sophisticated programmers(http://forum.dlang.org/thread/mev7ll$mqr$1...@digitalmars.com). What's interesting about this one is the reddit comments, which turned into an argument between simple languages that average programmers can use and complex languages that only the top 1% of intelligent programmers can use, but they can extract more out of them. But the thing is - the world of the top programmers is not really separate from that of average programmers. Professional development teams can have a few top programmers and many average one, all be working on the same project. Open source projects can have top programmers working on the core while allowing average programmers to contribute some simple features. Top programmers can write libraries that can be used by average programmers. To allow these things, top programmers and average programmers should be able to work on the same language. Of course, any language that average programmers can master should be easy for a top programmer to master - but the thing is, we also want the top programmer to be able to bring more out of the language, without limiting them by it's over-simplicity. This will also benefit the average programmers, since they also improve the quality of the libraries and modules they are using. This idea is nothing new, and was mentioned in the main(=biggest) current D vs Go thread(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=3#post-jeuhtlocousxtezoaqqh:40forum.dlang.org). What I want to talk about here is the seams. The hurdles that in practice make this duality harder. Let's compare it to another duality that D(and many other languages, mainly modern systems languages) promotes - the duality between high-level and low-level. Between write-code-fast and write-fast-code. The transition between high-level and low-level code in D consists by a change of the things uses - which language constructs, which idioms, which functions. But there aren't any visible seams. You don't need to use FFI or to dynamically load a library file written in another language or anything like that - you simply write the high-level parts like you would write high-level code and the low-level parts like you would write low-level code, and they just work together. The duality between high-level D and low-level D is seamless. The duality between simple D and complex D - not so much. The seams here exist mainly in understanding how to use complex code from simple code. Let's take std.algorithm(.*) for example. The algorithms' implementations there are complex and use advanced D features, but using them is very simple. Provided, of course, that you know how to use them(and no - not everything that you know becomes simple. I know how to solve regular differential equations, but it's still very complex to do so). The problem, as Andrei Alexandrescu pointed out(http://forum.dlang.org/thread/mdtago$em9$1...@digitalmars.com?page=6#post-mduv1i:242169:241:40digitalmars.com), is learning how to use them. Ideally you'd want to be able to look at a function's signature and learn from that how to use it. It's name and return type should tell you what it does and it's argument names and types should tell you what to send to it. The documentation only there for a more through description and to warn you about pitfalls and edge cases. But when it comes to heavily templated functions - understanding the signature is HARD. It's hard enough for the top programmers that can handle the complex D features - it's much harder for the average programmers that could have easily used these functions if they could just understand the documentation. Compare it, for example, to Jave. Even if a library doesn't contain a single documentation comment, the auto-generated javadoc that contains just the class tree and method signatures is usually enough to get an idea of what's going where. In D, unless the author has provided some actual examples, you are going to have a hard time trying to sort out these complex templated signatures... That's quite an hurdle to go though when wanting to use complex code from simple code(or even from other complex code). That's the ugly seam I'm talking about. Now, if you are working on a big project(be it commercial or open-source), you can find lot's of examples how to use these complex functions, and that's probably how you'd tackle the problem. When you are using some library you usually don't have that luxury - but these libraries usually have the generated ddoc at their website. Of course - that generated ddoc is full with complex templated signatures, so that's not very helpful... So, what can be done? Maybe the ddoc generator, instead of writing the whole
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/26/2015 02:00 PM, Nick Sabalausky wrote: And seriously, the article in question barely mentions D at all. Sorry, what I meant is it doesn't rely on D, and D Go is very clearly NOT the point the article is trying to make. It's just used for contrast, to illustrate the points. It could've been other languages as well.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/26/2015 02:04 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky wrote: So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. == digitalmars.D.announce Oh, so you were merely objecting to it being posted on D.announce rather than objecting to the article itself? Nevermind then.
Re: between and among: worth Phobosization? (reprise)
On Sunday, 15 March 2015 at 01:48:53 UTC, Andrei Alexandrescu
wrote:
On 12/16/13 12:38 PM, Andrei Alexandrescu wrote:
bool between(T, U1, U2)(T v, U1 lo, U2 hi)
{
return v = lo v = hi;
}
Add?
Looks like among() has proven its worth since we introduced it.
Now I somehow forgot between() didn't make it, and reviewed
some code at work assuming it exists!
I don't know if it's been mentioned yet, but there exists an
optimization for between with integer arguments:
bool between(T, U1, U2)(T v, U1 lo, U2 hi)
if (is(T:long) is(U1:long) is(U2:long))
{
return cast(Unsigned!T )v - cast(Unsigned!U1)lo
= cast(Unsigned!U2)hi - cast(Unsigned!U1)lo;
}
For this reason, I think this makes between non-trivial, so it
is worth adding.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On Thursday, 26 March 2015 at 18:07:39 UTC, Nick Sabalausky wrote: On 03/26/2015 02:04 PM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: On Thursday, 26 March 2015 at 18:00:29 UTC, Nick Sabalausky wrote: So no, this is NOT some sort of D community piece attacking another language as some comments seem to imply. It is merely an isolated critique of one language by someone who happens to be *using* the given language. == digitalmars.D.announce Oh, so you were merely objecting to it being posted on D.announce rather than objecting to the article itself? Nevermind then. I was merely pointing out that the D community comes through as desperate. Whether that is objectionable depends on how one wants to be perceived? Maybe it is the truth? In that case it is a good thing that it comes through as desperate!! ;^) And yes, when it is posted to the announcement list by one of the D language designers it is given a different status than merely being a random rant using toy examples. Obvious ranting is okish if it doesn't pretend to be more than that, but then it isn't something to be announced... is it? http://en.wiktionary.org/wiki/people_who_live_in_glass_houses_shouldn%27t_throw_stones
Re: Release D 2.067.0
On Thursday, 26 March 2015 at 16:13:11 UTC, Jack Death wrote: On Wednesday, 25 March 2015 at 21:13:14 UTC, Andrei Alexandrescu wrote: On 3/25/15 1:32 PM, Andrei Alexandrescu wrote: On 3/25/15 12:39 PM, Andrei Alexandrescu wrote: On 3/24/15 10:07 AM, Martin Nowak wrote: Glad to announce D 2.067.0. Spreading the news: [snip] Nice, we seem to be on HackerNews' front page: https://news.ycombinator.com/ And apparently we did something wrong - somehow we fell in minutes from position 11 to position 41. -- Andrei maybe people don't give a s**t? now over 80 they can and do move things up and down.
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
Btw, I have nothing against people complaining about Go's lack of productivity features and pointing out that they have competition from D. After all, I too did some ranting on the topic back in 2009: https://groups.google.com/forum/#!topic/golang-nuts/TTCaIpSxn2U%5B1-25%5D «I think Go has set off onto a very nice track, but it doesn't seem like you guys have really managed to communicate in which direction you are heading. I expect Go to improve, but if it isn't going to provide for more error-catching facilities then it probably isn't worth the trouble. Go has more competition than C and C++: D comes to mind along with other smaller competitors.» Nothing is new under the sun etc...
Re: Gary Willoughby: Why Go's design is a disservice to intelligent programmers
On 03/26/2015 04:38 AM, Russel Winder via Digitalmars-d-announce wrote: I paraphrase the common theme thus: Go is successful in the market, D isn't, therefore Go is a better language than D. I love how Go's very own reasoning there naturally suggests that PHP, C++, and Java must all be vastly superior to Go.
Re: Linkage runaround
On Thursday, 26 March 2015 at 12:37:32 UTC, Steve Teale wrote: If I link my DMD 2.066.1/ GtkD (latest version) app with static Phobos2 I get Linking executable: ../bin/Debug/compo ../objdir/mainwin.o: In function `_D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv': /usr/include/dmd/druntime/import/core/runtime.d:233: undefined reference to `rt_loadLibrary' collect2: ld returned 1 exit status If I change the link spec to use libphobos2.so, then the app links, and runs, but it crashes the first time I try to read something from a file with stream.File.readString. Does this ring a bell with anyone. Does your code call Runtime.loadLibrary anywhere? It looks like rt_loadLibrary is only implemented when on Windows or with version(Shared).
Re: Release D 2.067.0
On Tuesday, 24 March 2015 at 17:08:03 UTC, Martin Nowak wrote: Glad to announce D 2.067.0. This release comes with many improvements. The GC is a lot faster for most use-cases, we have improved C++ interoperability and fixed plenty of bugs. See the changelog for more details. http://dlang.org/changelog.html Download pages and documentation will be updated within the next few hours. http://downloads.dlang.org/releases/2.x/2.067.0/ http://ftp.digitalmars.com/ Until the binaries are mirrored to the official site, you can get them here. https://dlang.dawg.eu/downloads/dmd.2.067.0/ -Martin This is an awesome release. Thanks to all involved! :)
