Re: UTF8 + SIMD = win

[Guillaume Chatelet]

On 07/30/12 21:13, deadalnix wrote:
> http://woboq.com/blog/utf-8-processing-using-simd.html
> 
> All in the article. As D include Unicode as a language feature, I think
> it is interesting to mention here.

Very interesting, thx for sharing. This NG definitely is a horn of plenty :)

Re: Can you do this in D?

[captaindet]

On 2012-07-30 00:11, captaindet wrote:

What happened to __traits(allMembers, module_name)? It doesn't list
the contents of the current scope, but instead that of a module
(including the current one).



that could have saved me too ... now i tried getting it working, but to no 
avail. i mean, __traits(allMembers, X) works for class X fine, but fails on 
modules. using dmd 2.059 for win and some 2.060-ish phobos from some weeks ago.

could anyone provide a working code example pls?

cheers,

det


my bad, figured it out

Re: Incomprehensible compiler errors

[Bernard Helyer]

On Tuesday, 31 July 2012 at 03:28:40 UTC, bearophile wrote:

Walter Bright:

Elsewhere you have said:
http://forum.dlang.org/thread/50171a5b.7030...@digitalmars.com

"DFL won't compile" It doesn't matter if the fix is trivial, 
easy, whatever. It does not compile, therefore D sux.<


If you have noted the OP has not said D sucks, the opposite:


The language is fine:<


I agree that having a language perfectly finished is a good 
thing, no one likes broken programs, but programmers can't 
expect D to work as C89, with no changes since many years ago.


A problem is that most people don't understand mangled linker 
errors. I agree with you that linkers are not magic, but modern 
programmers coming from many other languages are not used to 
them and their mangled errors. So we have suggested to filter 
those messages, to help programmers.


If they won't learn the compilation model, they won't be good 
programmers.
I'm not saying that good messages are a bad thing, but if they 
don't
understand the basic concept of source -> object file -> linker 
-> exe or dll,

then they will have a very hard time with D, pretty error messages
or no.

Re: Incomprehensible compiler errors

[bearophile]

Andrei Alexandrescu wrote:

On 7/30/12 7:32 PM, Stuart wrote:

On Monday, 30 July 2012 at 23:07:35 UTC, bearophile wrote:

Take a look at the Rebol language.


I took a quick look. It didn't look like anything suitable for 
creating

native GUI applications. It looked totally insane.


Yah, that came outta nowhere. I've also had a "wtfits" reaction.


It's a language born in 1997, and it's sometimes used as a more 
modern replacement for TCL to create small programs with GUIs:

http://en.wikipedia.org/wiki/Rebol

It semantics is clean, it has everything built-in, its syntax is 
readable and very short. There are many persons that don't think 
of it as insane. I have used it to quickly create GUIs for 
programs written in other languages too.


And it doesn't spit mysterious linker errors. It's far simpler to 
understand than D.


Bye,
bearophile

Re: What is rape?

[Era Scarecrow]

On Monday, 30 July 2012 at 20:01:19 UTC, Peter Alexander wrote:

Don't feed the troll.


Pretty sure said troll is a bot, it doesn't need feeding.


 Then perhaps the admins can use that ID and ignore it.. Then 
again, the bot may later start selecting any of our ID's and 
posting crap in our place. That would be scary.


 I suddenly feel like I should be selling Viagra... How strange..

Re: Different results for uniform random number generation between D and Boost

[Nick Sabalausky]

On Tue, 31 Jul 2012 00:33:43 +0100
Joseph Rushton Wakeling  wrote:

> Hello all,
> 
> A little curiosity I noticed when comparing fine-detailed results
> from simulations where I had code in both C++ and D.
> 
> Here's a little program that prints out the first 10 results of the
> Mersenne Twister RNG, and then uses the same sequence to generate 10 
> uniformly-distributed numbers in [0, 1).
> 
> 
> import std.random, std.range, std.stdio;
> 
> void main()
> {
>   auto rng = Random(12345);
> 
>   foreach(x; takeExactly(rng, 10))
>   writeln(x);
> 
>   writeln();
>   writeln("Min: ", rng.min);
>   writeln("Max: ", rng.max);
>   writeln();
>   
>   rng.seed(12345);
> 
>   foreach(i; 0..1000)
>   writefln("%.64f", uniform!("[)", double, double)(0.0,
> 1.0, rng)); }
> 
> 
> And now here's something similar written in C++ and using the Boost
> RNGs:
> 
> 
> #include 
> #include 
> #include 
> 
> int main(void)
> {
>   boost::mt19937 rng(12345);
> 
>   for(int i=0;i<10;++i)
>   std::cout << rng() << std::endl;
>   
>   std::cout << std::endl;
>   std::cout << "Min: " << rng.min() << std::endl;
>   std::cout << "Max: " << rng.max() << std::endl;
>   std::cout << std::endl;
> 
>   rng.seed(12345);
> 
>   for(int i=0;i<10;++i)
>   std::cout << std::setprecision(64) <<
> boost::uniform_real(0.0, 1.0)(rng) << std::endl;
> }
> 
> 
> When I run these on my 64-bit machine I get different results for the
> uniform doubles, which show up round about the 15th or 16th decimal
> place.
> 
> If I replace double with float, I get a similar result, but now with
> the difference starting at about the 7th or 8th decimal place.
> 
> I've tried tweaking the internals of std.random's uniform() just to
> confirm it's not a rounding error down to subtly different
> arithmetical order; D's results remain unchanged.  So I'm curious why
> I see these differences -- OK, floating point is a minefield, but I
> thought these were hardware-implemented variables and operations
> which I'd expect to match between C++ and D.
> 
> OK, it's not the end of the world and these numbers are identical to
> a high degree of accuracy -- but I'm just curious as to why the
> difference.  It's also slightly frustrating to not have precise
> agreement between the output of 2 libraries that are so obviously
> designed to produce an identical API and feature set.
> 
> Best wishes,
> 
>  -- Joe

My (limited) understanding is that it's almost practically impossible to
get consistency in x86 floating point unless you're using SSE:

http://www.yosefk.com/blog/consistency-how-to-defeat-the-purpose-of-ieee-floating-point.html

Maybe the effect you're observing could be related to what he
describes?

Re: Incomprehensible compiler errors

[Bernard Helyer]

Oh, and if there are complaints of LoadLibraryA or whatever not 
being nothrow, remove any trace of nothrow from those modules.

Re: Incomprehensible compiler errors

[Jonathan M Davis]

On Tuesday, July 31, 2012 01:40:02 Stuart wrote:
> Well, perhaps someone can explain why I can't compile DFL?

Is it even maintained? The page that appears to be its home page ( 
http://www.dprogramming.com/dfl.php ) doesn't appear to have been updated since 
2008.

- Jonathan M Davis

Re: Incomprehensible compiler errors

[Bernard Helyer]

On Monday, 30 July 2012 at 23:40:02 UTC, Stuart wrote:
On Monday, 30 July 2012 at 23:31:14 UTC, Andrei Alexandrescu 
wrote:


I empathize. The one thing that may be different is that the 
forums at forum.dlang.org tend to be a bit more responsive and 
to the point.


Well, perhaps someone can explain why I can't compile DFL?


Compiling from here,

https://github.com/Rayerd/dfl

the problem is winapi.d, wincom.d utf.d (not internal\utf.d) are 
all obsolete, and won't compile. Remove those and don't use them 
in your code. Other than that, all I did was


dmd -lib -ofdfl *.d internal/*.d -I..

From win32/dfl in a MinGW bash shell, because DMD doesn't expand 
wildcards.


Then I tested my new dfl.lib with

import dfl.all;

int main()
{
Form myForm;
Label myLabel;

myForm = new Form;
myForm.text = "DFL Example";

myLabel = new Label;
myLabel.font = new Font("Verdana", 14f);
myLabel.text = "Hello, DFL World!";
myLabel.location = Point(15, 15);
myLabel.autoSize = true;
myLabel.parent = myForm;

Application.run(myForm);

return 0;
}

with

dmd test.d dfl.lib gdi32.lib ole32.lib oleaut32.lib comdlg32.lib 
comctl32.lib


This took me about two minutes to figure out with no prior 
experience with DFL.

Re: One against binary searches

[bearophile]

Xinok:

I've added it to my todo list. I still haven't taken the time 
to familiarize myself with Phobos' conventions, so I don't feel 
comfortable contributing anything yet.


Thank you. The code we are talking about (like a quaternary 
search) is a small amount of code. And I think other people in 
GitHub are willing to show you where you are not following the 
conventions.


Bye,
bearophile

Re: Incomprehensible compiler errors

[Stuart]

On Tuesday, 31 July 2012 at 00:06:43 UTC, cal wrote:

On Monday, 30 July 2012 at 23:40:02 UTC, Stuart wrote:
I have no problem with DMD. DMD is a perfectly reasonable 
Windows executable. I am objecting to the frustrating way DFL 
is compile-it-yourself and doesn't work; and also the 
frustrating way there isn't a single working IDE or GUI 
designer for D.


If you're willing try yet another IDE, I use Code::Blocks on 
both windows and linux, and while the intellisense or whatever 
C::B calls it is usually a waste of time it is at least 
completely stable and integrates OK with ddbg (which itself is 
not perfect, but...). It recognizes D syntax and it doesn't 
take 5 minutes to start-up. People also seem to like Mono-D.


I couldn't get C::B to compile anything - either D or C. Mono-D 
didn't work for me either. I guess I'm just cursed.

Re: Incomprehensible compiler errors

[cal]

On Monday, 30 July 2012 at 23:40:02 UTC, Stuart wrote:
I have no problem with DMD. DMD is a perfectly reasonable 
Windows executable. I am objecting to the frustrating way DFL 
is compile-it-yourself and doesn't work; and also the 
frustrating way there isn't a single working IDE or GUI 
designer for D.


If you're willing try yet another IDE, I use Code::Blocks on both 
windows and linux, and while the intellisense or whatever C::B 
calls it is usually a waste of time it is at least completely 
stable and integrates OK with ddbg (which itself is not perfect, 
but...). It recognizes D syntax and it doesn't take 5 minutes to 
start-up. People also seem to like Mono-D.


Like Dmitry said, rdmd can be a big help, since you just compile 
your main and it will find the dependencies.

Re: Incomprehensible compiler errors

[Andrei Alexandrescu]

On 7/30/12 7:32 PM, Stuart wrote:

On Monday, 30 July 2012 at 23:07:35 UTC, bearophile wrote:

Take a look at the Rebol language.


I took a quick look. It didn't look like anything suitable for creating
native GUI applications. It looked totally insane.


Yah, that came outta nowhere. I've also had a "wtfits" reaction.

Andrei

Re: Incomprehensible compiler errors

[Stuart]

Let me be clear: I have no problem with the language of D. It 
looks quite decent. It's just not feasible to actually write a 
PROGRAM in it. Sure, if I want a quick-and-dirty commandline tool 
or something, no problem; but a Windows application? Without an 
IDE or GUI designer? No way. Even MFC has a dialog designer.


The language is fine: Now the developers need to turn their 
attention to the TOTAL AND UTTER LACK OF RELIABLE DEVELOPMENT 
TOOLS.

Re: One against binary searches

[Xinok]

On Monday, 30 July 2012 at 19:52:35 UTC, bearophile wrote:

Xinok:

I also tried a quaternary search, but it was 25-30ms slower 
than a ternary search, albeit it was a bit faster than a 
binary search.


I see. are you willing to add some of those searches here?
http://dlang.org/phobos/std_range.html#SearchPolicy


I've added it to my todo list. I still haven't taken the time to 
familiarize myself with Phobos' conventions, so I don't feel 
comfortable contributing anything yet.

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 23:31:14 UTC, Andrei Alexandrescu 
wrote:


I empathize. The one thing that may be different is that the 
forums at forum.dlang.org tend to be a bit more responsive and 
to the point.


Well, perhaps someone can explain why I can't compile DFL?

I'm getting the same problem as 
[http://www.digitalmars.com/d/archives/digitalmars/D/DFL_167579.html]. 
This forum post is over two months old, and yet nobody has fixed 
the problem.


The suggested solutions either [a] didn't help or [b] didn't make 
sense, depending.


It's really getting on my tits. Even using MFC is easier than 
this.


The irony there is that dmd has started as a Windows program.


I have no problem with DMD. DMD is a perfectly reasonable Windows 
executable. I am objecting to the frustrating way DFL is 
compile-it-yourself and doesn't work; and also the frustrating 
way there isn't a single working IDE or GUI designer for D.

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 23:07:35 UTC, bearophile wrote:

Stuart:

I'm about ready to give up here. I like the idea of D, but 
it's like using fucking Linux:


I understand. The troubles you find are present in widely used 
languages. D is a young language and it's not widespread, so 
you are going to find even more problems.


The problem isn't that it's a young language; the problem is that 
it follows the Linux ideology - which, in a nutshell, is "make 
the user compile every damn thing, and make the user type 
everything longhand in emacs".


It's not D itself I have a problem with. It's the complete lack 
of reliable tools for it. No IDE. No GUI designer. No nothing. 
Coding a real application in D is like using Cobra, or Nemerle - 
in short, frustrating and slow.


All I want is to be able to write a GUI application using 
phrases like "button1.dock = Fill". Is that so much to ask? 
Apparently it is.


Take a look at the Rebol language.


I took a quick look. It didn't look like anything suitable for 
creating native GUI applications. It looked totally insane.

Re: Incomprehensible compiler errors

[Andrei Alexandrescu]

On 7/30/12 6:54 PM, Stuart wrote:

Ah, it would seem that my problem is with DFL not compiling. Look guys,
I'm about ready to give up here. I like the idea of D, but it's like
using fucking Linux: Absolutely everything needs to be compiled before
you can use it; and nothing will compile because you need to do fifty
other goddamn things that aren't mentioned in the readme, so you have to
post on dozens of sodding forums for a week hoping someone throws you a
bone.


I empathize. The one thing that may be different is that the forums at 
forum.dlang.org tend to be a bit more responsive and to the point.



All I want is to be able to write a GUI application using phrases like
"button1.dock = Fill". Is that so much to ask? Apparently it is.

DFL won't compile. D-IDE doesn't work at all. VisualD crashes all the
time. The Eclipse IDE plugin doesn't work either. None of the IDEs have
any kind of reliable intellisense. The optional "module" keywords aren't
optional. The whole fucking thing's a shambles, just like everything
else designed for Linux.

It's really getting on my tits. Even using MFC is easier than this.


The irony there is that dmd has started as a Windows program.


Andrei

Different results for uniform random number generation between D and Boost

[Joseph Rushton Wakeling]

Hello all,

A little curiosity I noticed when comparing fine-detailed results from 
simulations where I had code in both C++ and D.


Here's a little program that prints out the first 10 results of the Mersenne 
Twister RNG, and then uses the same sequence to generate 10 
uniformly-distributed numbers in [0, 1).



import std.random, std.range, std.stdio;

void main()
{
auto rng = Random(12345);

foreach(x; takeExactly(rng, 10))
writeln(x);

writeln();
writeln("Min: ", rng.min);
writeln("Max: ", rng.max);
writeln();

rng.seed(12345);

foreach(i; 0..1000)
writefln("%.64f", uniform!("[)", double, double)(0.0, 1.0, 
rng));
}


And now here's something similar written in C++ and using the Boost RNGs:


#include 
#include 
#include 

int main(void)
{
boost::mt19937 rng(12345);

for(int i=0;i<10;++i)
std::cout << rng() << std::endl;

std::cout << std::endl;
std::cout << "Min: " << rng.min() << std::endl;
std::cout << "Max: " << rng.max() << std::endl;
std::cout << std::endl;

rng.seed(12345);

for(int i=0;i<10;++i)
		std::cout << std::setprecision(64) << boost::uniform_real(0.0, 
1.0)(rng) << std::endl;

}


When I run these on my 64-bit machine I get different results for the uniform 
doubles, which show up round about the 15th or 16th decimal place.


If I replace double with float, I get a similar result, but now with the 
difference starting at about the 7th or 8th decimal place.


I've tried tweaking the internals of std.random's uniform() just to confirm it's 
not a rounding error down to subtly different arithmetical order; D's results 
remain unchanged.  So I'm curious why I see these differences -- OK, floating 
point is a minefield, but I thought these were hardware-implemented variables 
and operations which I'd expect to match between C++ and D.


OK, it's not the end of the world and these numbers are identical to a high 
degree of accuracy -- but I'm just curious as to why the difference.  It's also 
slightly frustrating to not have precise agreement between the output of 2 
libraries that are so obviously designed to produce an identical API and feature 
set.


Best wishes,

-- Joe

Re: Incomprehensible compiler errors

[bearophile]

Stuart:

I'm about ready to give up here. I like the idea of D, but it's 
like using fucking Linux:


I understand. The troubles you find are present in widely used 
languages. D is a young language and it's not widespread, so you 
are going to find even more problems.



All I want is to be able to write a GUI application using 
phrases like "button1.dock = Fill". Is that so much to ask? 
Apparently it is.


Take a look at the Rebol language. Unlike D it imposes you big 
limits, but it's a language designed for the programmer, and not 
for the machine:


http://rebol.com/

Bye,
bearophile

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 21:40:35 UTC, Walter Bright wrote:


A ModuleInfo is generated for each compiled module and inserted 
into its corresponding .obj file. If the linker cannot find it, 
then it is likely that you need to specify that .obj on the 
link command.


Ah, it would seem that my problem is with DFL not compiling. Look 
guys, I'm about ready to give up here. I like the idea of D, but 
it's like using fucking Linux: Absolutely everything needs to be 
compiled before you can use it; and nothing will compile because 
you need to do fifty other goddamn things that aren't mentioned 
in the readme, so you have to post on dozens of sodding forums 
for a week hoping someone throws you a bone.


All I want is to be able to write a GUI application using phrases 
like "button1.dock = Fill". Is that so much to ask? Apparently it 
is.


DFL won't compile. D-IDE doesn't work at all. VisualD crashes all 
the time. The Eclipse IDE plugin doesn't work either. None of the 
IDEs have any kind of reliable intellisense. The optional 
"module" keywords aren't optional. The whole fucking thing's a 
shambles, just like everything else designed for Linux.


It's really getting on my tits. Even using MFC is easier than 
this.

Re: Incomprehensible compiler errors

[Walter Bright]

On 7/30/2012 9:31 AM, Stuart wrote:

I'm trying to write an actual program in D, but no matter what I do I get stupid
errors that mean nothing to me. (Reminds me of C++)

Error 42: Symbol Undefined
_D8infinity8standard7runtime4IApp4IApp11__InterfaceZ


This means module infinity, and standard.runtime.Iapp ...



Huh? This usually happens if I omit the module statement at the top of EVERY
DAMN FILE (why???) but in this case I haven't omitted it, yet I'm still getting
the error.


It's likely that you aren't presenting the compiled version of inifinity.obj to 
the linker.




Also, I get the following error:

Error 42: Symbol Undefined
_D3dfl8internal6winapi12__ModuleInfoZ

The code producing this second error is:

 int Run() {
 import core.sys.windows.windows;
 import dfl.internal.winapi;
 MSG msg;
 while (GetMessageA(&msg, null, 0, 0)) {
 TranslateMessage(&msg);
 DispatchMessageA(&msg);
 if (msg.hwnd && !IsWindow(msg.hwnd)) break;
 }
 return 0;
 }

What the HELL is this "ModuleInfo", why is it necessary, why is it always
missing when a "module" statement is not present, and why is it missing NOW?


A ModuleInfo is generated for each compiled module and inserted into its 
corresponding .obj file. If the linker cannot find it, then it is likely that 
you need to specify that .obj on the link command.

Re: Impressed

[Nick Sabalausky]

On Mon, 30 Jul 2012 22:22:22 +0200
"Paulo Pinto"  wrote:

> On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:
> > On Mon, 30 Jul 2012 07:04:21 +0100
> > Russel Winder  wrote:
> >>
> >> My experience from various training courses I have given is 
> >> that in
> >> the large corporate Web applications world, the average 
> >> programmer
> >> knows Java, just enough Java, and isn't that interested in 
> >> anything
> >> else. Gross oversimplification but a good indicator.
> >
> > Ugh, such "programmers" don't deserve a paycheck. It's like 
> > hiring
> > someone who never learned arithmetic as an accountant. Makes no
> > fucking sense at all - they just simply *can't* do their 
> > fucking trade,
> > period. The "programmer" and the hiring manager should both be 
> > fired
> > and pointed to nearest (possibly hiring) fast food joint.
> >
> > (Incarceration for "impersonating a programmer" would perhaps 
> > be more
> > appropriate ;) )
> 
> Sadly this is how many well known consulting companies with a big 
> client portfolio of Fortune 500 companies work.
> 

It's no surprise then as to why, outside of management circles,
consulting companies have gained a reputation for not knowing what
they're doing.

Re: Impressed

[Paulo Pinto]

On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:

On Mon, 30 Jul 2012 07:04:21 +0100
Russel Winder  wrote:


My experience from various training courses I have given is 
that in
the large corporate Web applications world, the average 
programmer
knows Java, just enough Java, and isn't that interested in 
anything

else. Gross oversimplification but a good indicator.


Ugh, such "programmers" don't deserve a paycheck. It's like 
hiring

someone who never learned arithmetic as an accountant. Makes no
fucking sense at all - they just simply *can't* do their 
fucking trade,
period. The "programmer" and the hiring manager should both be 
fired

and pointed to nearest (possibly hiring) fast food joint.

(Incarceration for "impersonating a programmer" would perhaps 
be more

appropriate ;) )


Sadly this is how many well known consulting companies with a big 
client portfolio of Fortune 500 companies work. I happen to work 
in one of them, you would be amazed what managers and clients 
look for as developers.


As a guy I know says, pay for a FIAT while expecting to get a 
Ferrari in the end.


--
Paulo

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 20:08:34 UTC, Stuart wrote:
Well I'm using VisualD, and have both projects in my solution. 
Is there some option I ought to be setting? I can't go running 
arbitrary commandlines all over the shop.


Nvm, I got it. "Project Dependencies" dialog.

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 20:04:25 UTC, Dmitry Olshansky wrote:

On 30-Jul-12 23:45, Stuart wrote:
No, that doesn't help. Because I'm getting this same shit when 
I import

my OWN .d files:


It doesn't matter whose these file are. You need all of them 
passed to compiler (then it will link them together) or split 
them in packs and compile to libraries and then pass to linker.


D compiler doesn't link in dependencies automatically the 
reason for this was "too much magic" and "hard to override"


Well I'm using VisualD, and have both projects in my solution. Is 
there some option I ought to be setting? I can't go running 
arbitrary commandlines all over the shop.

Re: Incomprehensible compiler errors

[Dmitry Olshansky]

On 30-Jul-12 23:45, Stuart wrote:

On Monday, 30 July 2012 at 19:03:13 UTC, Dmitry Olshansky wrote:

Why would you use internal module of library is beyond me


Perhaps because nobody saw fit to define IsWindow() in module
"core.sys.windows.windows"?


Yeah, it's woefully lacking. There is Win32 bindings project that covers 
all of WinAPI/DirectX/etc. (not sure about modern extensions as in 
Win7/8 but far better then built-in).



dmd your_module.d dfl.lib


No, that doesn't help. Because I'm getting this same shit when I import
my OWN .d files:


It doesn't matter whose these file are. You need all of them passed to 
compiler (then it will link them together) or split them in packs and 
compile to libraries and then pass to linker.


D compiler doesn't link in dependencies automatically the reason for 
this was "too much magic" and "hard to override" (e.g. what if it picks 
 up wrong libraries and/or files?).



So for humans the way to go is to use rdmd tool that deduces all 
dependencies if you pass it one main file.


This will compile all files and execute you app (it also rebuilds only 
if files change):

rdmd mymain.d

or to only build app (not execute):
rdmd --build-only mymain.d


--
Dmitry Olshansky

Re: What is rape?

[Peter Alexander]

On Monday, 30 July 2012 at 16:27:37 UTC, Simen Kjaeraas wrote:
On Mon, 30 Jul 2012 18:23:57 +0200, Stuart  
wrote:




What. The. Fuck?


Don't feed the troll.


Pretty sure said troll is a bot, it doesn't need feeding.

Re: Impressed

[Andrei Alexandrescu]

On 7/30/12 3:33 PM, Alex Rønne Petersen wrote:

There are probably lots of other features that I have forgotten. I don't
think calling F# unoriginal is fair...


I stand corrected!

Andrei

Re: Incomprehensible compiler errors

[Stuart]

On Monday, 30 July 2012 at 19:03:13 UTC, Dmitry Olshansky wrote:

Why would you use internal module of library is beyond me


Perhaps because nobody saw fit to define IsWindow() in module 
"core.sys.windows.windows"?



dmd your_module.d dfl.lib


No, that doesn't help. Because I'm getting this same shit when I 
import my OWN .d files:


---

module infinity.standard.runtime.IApp;
interface IApp { int Run(); }

---

module infinity.standard.runtime.StandardApplication;
import infinity.standard.runtime.IApp;

mixin template StandardApplication(TApp : IApp) {
import core.runtime, core.sys.windows.windows;
extern (Windows)
	int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR 
lpCmdLine, int nCmdShow) {

 int result;
 void exceptionHandler(Throwable e) { throw e; }
 try {
  Runtime.initialize(&exceptionHandler);
			  result = myWinMain(hInstance, hPrevInstance, lpCmdLine, 
nCmdShow);

  Runtime.terminate(&exceptionHandler);
 } catch (Throwable o) {
			  MessageBoxA(null, cast(char *)o.toString(), "Error", MB_OK | 
MB_ICONEXCLAMATION);

  result = 0;   // failed
 }
 return result;
}

	int myWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
LPSTR lpCmdLine, int nCmdShow) {

TApp app;
return app.Run();
}
}
---

Error 42: Symbol Undefined 
_D8infinity8standard7runtime4IApp4IApp11__InterfaceZ

Re: One against binary searches

[Xinok]

On Monday, 30 July 2012 at 17:20:54 UTC, bearophile wrote:

Xinok:

My stable sort makes heavy use of binary searches [1], so just 
for fun, I tried inserting a ternary search before the binary 
search.


I think in the end he suggests to use a "offseted binary" or a 
"quaternary search", over both binary and ternary searches (if 
the array is not too much small).


An offseted binary search wouldn't work in this case. The "binary 
search" is actually comparing elements in two adjacent ranges 
which are equidistant from the center, so it's impossible to 
align in both ranges.


I also tried a quaternary search, but it was 25-30ms slower than 
a ternary search, albeit it was a bit faster than a binary search.

Re: Impressed

[Alex Rønne Petersen]

On 28-07-2012 18:07, Andrei Alexandrescu wrote:

On 7/28/12 10:04 AM, Paulo Pinto wrote:

On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:

On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:


I tend to favour F# instead of OCaml due to three things


I've never really seen the point of F#. Aside from maths, what is F#
good for that a standard imperative language is not? Especially when
you consider that all flavours of .NET have native support for LINQ.


Let me see:

- Symbolic code manipulation;
- Metaprogramming;
- Easy parallelization of code thanks to immutable data structures and
workflows
- Type providers (comming in F# 3.0) to manipulate remote data as
language data types
- The right way of doing type inference (shared by all ML languages)
- Asynchronous programming builtin without having to wait for ..NET 4.5
- Algebraic data types

Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth
it, Microsoft is a business, not a language charity company.


It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty
cool (just not all that original as a language).

Andrei


What makes you say that?

I guess that opinion stems from F# being based on OCaml's syntax? (But 
then to be fair, we would have to call D very unoriginal too...)


Either way, F# adds a *ton* of stuff on top of OCaml that makes it a far 
superior language:


* Reified generics: 
http://msdn.microsoft.com/en-us/library/dd233215(v=vs.110)
* Inline functions (I'm still amazed D doesn't have this yet): 
http://msdn.microsoft.com/en-us/library/dd548047(v=vs.110)
* Type extensions, a (IMO) much cleaner approach to artificially 
extending types: http://msdn.microsoft.com/en-us/library/dd233211(v=vs.110)
* Pattern matching (oh how I miss this in compiler code): 
http://msdn.microsoft.com/en-us/library/dd547125(v=vs.110)

* Annotations: http://msdn.microsoft.com/en-us/library/dd233179(v=vs.110)
* Units of measure: 
http://msdn.microsoft.com/en-us/library/dd233243(v=vs.110)
* Computation expressions (F#'s humanly understandable take on monads): 
http://msdn.microsoft.com/en-us/library/dd233182(v=vs.110)
* Code quotations, making for metaprogramming that can do things even 
D's metaprogramming can't: 
http://msdn.microsoft.com/en-us/library/dd233212(v=vs.110)
* Async workflows (actually a library solution built through computation 
expressions): http://msdn.microsoft.com/en-us/library/dd233250(v=vs.110)
* Query expressions (again, based on computation expressions): 
http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110)
* Automatic generalization: 
http://msdn.microsoft.com/en-us/library/dd233183(v=vs.110).aspx
* Type providers (type-safe data access): 
http://msdn.microsoft.com/en-us/library/hh156509(v=vs.110).aspx


There are probably lots of other features that I have forgotten. I don't 
think calling F# unoriginal is fair...


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: Impressed

[Nick Sabalausky]

On Mon, 30 Jul 2012 07:04:21 +0100
Russel Winder  wrote:
>
> My experience from various training courses I have given is that in
> the large corporate Web applications world, the average programmer
> knows Java, just enough Java, and isn't that interested in anything
> else. Gross oversimplification but a good indicator.

Ugh, such "programmers" don't deserve a paycheck. It's like hiring
someone who never learned arithmetic as an accountant. Makes no
fucking sense at all - they just simply *can't* do their fucking trade,
period. The "programmer" and the hiring manager should both be fired
and pointed to nearest (possibly hiring) fast food joint.

(Incarceration for "impersonating a programmer" would perhaps be more
appropriate ;) )

Re: UTF8 + SIMD = win

[bearophile]

deadalnix:

http://woboq.com/blog/utf-8-processing-using-simd.html


So many things to do, so little time to do them :-)

Bye,
bearophile

UTF8 + SIMD = win

[deadalnix]

http://woboq.com/blog/utf-8-processing-using-simd.html

All in the article. As D include Unicode as a language feature, I think 
it is interesting to mention here.

Re: Impressed

[deadalnix]

Le 28/07/2012 18:07, Andrei Alexandrescu a écrit :

Microsoft wouldn't have brought F# into Visual Studio if it wasn't worth
it, Microsoft is a business, not a language charity company.


It was for Basic :o). Anyhow, indeed, the tools around it make F# pretty
cool (just not all that original as a language).

Andrei


Indeed, it is damn close to Caml.

Re: Incomprehensible compiler errors

[Dmitry Olshansky]

On 30-Jul-12 22:43, Stuart wrote:

I notice nobody so far seems to have any idea why I'm getting these errors.


Everybody knows it's a linker error.

Your particular message means you have link-in module dfl.internal.winapi.

e.g. by passing all files to dmd:

dmd you_module.d dfl\internal\winapi.d

Why would you use internal module of library is beyond me but 
regardless, a better way would be (if DFL is compiled to dfl.lib file):


dmd your_module.d dfl.lib


--
Dmitry Olshansky

Re: Incomprehensible compiler errors

[Stuart]

I notice nobody so far seems to have any idea why I'm getting 
these errors.

Re: Impressed

[Jonathan M Davis]

On Monday, July 30, 2012 11:23:06 Christophe Travert wrote:
> Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
> > scope on local variables is going away for pretty much the same reason
> > that
> > delete is. They're unsafe, and the fact that they're in the core language
> > encourages their use. So, they're being removed and put into the standard
> > library instead.
> 
> I don't mind scope going away, since it can be replaced with a library
> solution. But scope is not more dangerous than a static array, or simple
> function variables. Slice them, or take their reference, and you're up
> for troubles. Do you think they should be removed as core features of
> the langage?

I don't think that you _can_ implement them in a library.

I _do_ think that implicit slicing of static arrays should go away, since it's 
just begging for bugs. But there's pretty much no way that that's going to 
change at this point.

- Jonathan M Davis

Re: One against binary searches

[Andrei Alexandrescu]

On 7/30/12 1:28 PM, Don Clugston wrote:

On 30/07/12 17:40, bearophile wrote:

This author writes very detailed analyses of low-level computational
matters, that appear on Reddit. This blog post he suggests to introduce
"offseted binary" or "quaternary search" instead of binary search in
Phobos:

http://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/



Bye,
bearophile


Fantastic article, thanks!
The fact that physical addressing can influence L2 cache misses was
completely new to me.


BTW we have alternative searches in sorted ranges that are 
cache-friendly in Phobos, trot and gallop (backwards and forwards): 
http://dlang.org/phobos/std_range.html. They work well if there's a good 
assumption that the searched item is toward the beginning or the end of 
the range, and galloping search has O(log n) complexity.


Andrei

Re: One against binary searches

[bearophile]

Don Clugston:


Fantastic article, thanks!


If you like that, some time ago the same author has written an 
equally nice article on a related topic :-)


http://www.pvk.ca/Blog/2012/07/03/binary-search-star-eliminates-star-branch-mispredictions/

Bye,
bearophile

Re: Incomprehensible compiler errors

[Paulo Pinto]

On Monday, 30 July 2012 at 17:12:11 UTC, Peter Alexander wrote:

On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
For one, it would be mighty polite of the compiler to demangle 
the "_**
D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which 
happens to be

"infinity.standard.runtime.App.App.__Interface".


The linker spits out those errors. It would be unreasonable to
expect linkers to understand D's name mangling scheme.


This problem was already solved by Turbo Pascal in the 80's, by 
making use of smart linkers integrated with the compiler.


Many other languages follow similar module systems.

Re: One against binary searches

[Don Clugston]

On 30/07/12 17:40, bearophile wrote:

This author writes very detailed analyses of low-level computational
matters, that appear on Reddit. This blog post he suggests to introduce
"offseted binary" or "quaternary search" instead of binary search in
Phobos:

http://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/


Bye,
bearophile


Fantastic article, thanks!
The fact that physical addressing can influence L2 cache misses was 
completely new to me.

Re: One against binary searches

[bearophile]

Xinok:

My stable sort makes heavy use of binary searches [1], so just 
for fun, I tried inserting a ternary search before the binary 
search.


I think in the end he suggests to use a "offseted binary" or a 
"quaternary search", over both binary and ternary searches (if 
the array is not too much small).


Bye,
bearophile

Re: Incomprehensible compiler errors

[Andrej Mitrovic]

On 7/30/12, Peter Alexander  wrote:
> On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
>> For one, it would be mighty polite of the compiler to demangle
>> the "_**
>> D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which
>> happens to be
>> "infinity.standard.runtime.App.App.__Interface".
>
> The linker spits out those errors. It would be unreasonable to
> expect linkers to understand D's name mangling scheme.

unilink understands it!

Optlink, well.. we windevs all know optlink too well. :)

Re: Incomprehensible compiler errors

[Adam D. Ruppe]

On Monday, 30 July 2012 at 17:16:04 UTC, bearophile wrote:
Then the output of the linker should be hidden, and the 
programmer should see only some filtered and cleaned error text.


yea the compiler could run something like

linker | demangle

rather than just linker and make it a little prettier.

Re: Incomprehensible compiler errors

[bearophile]

Peter Alexander:


The linker spits out those errors. It would be unreasonable to
expect linkers to understand D's name mangling scheme.


Then the output of the linker should be hidden, and the 
programmer should see only some filtered and cleaned error text. 
It's another little step to pull out of '70 the D compilations :-)


Bye,
bearophile

Re: Incomprehensible compiler errors

[Gor Gyolchanyan]

On Mon, Jul 30, 2012 at 9:12 PM, Peter Alexander <
peter.alexander...@gmail.com> wrote:

> On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
>
>> For one, it would be mighty polite of the compiler to demangle the "_**
>> D8infinity8standard7runtime4IApp4IApp11__InterfaceZ", which happens
>> to be
>> "infinity.standard.runtime.**App.App.__Interface".
>>
>
> The linker spits out those errors. It would be unreasonable to
> expect linkers to understand D's name mangling scheme.
>
>
The compiler calls the linker (in cases where it's linking of course). It
wouldn't be too difficult to intercept the linker's output.

-- 
Bye,
Gor Gyolchanyan.

Re: Incomprehensible compiler errors

[Peter Alexander]

On Monday, 30 July 2012 at 16:38:54 UTC, Gor Gyolchanyan wrote:
For one, it would be mighty polite of the compiler to demangle 
the "_**
D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which 
happens to be

"infinity.standard.runtime.App.App.__Interface".


The linker spits out those errors. It would be unreasonable to
expect linkers to understand D's name mangling scheme.

Re: Incomprehensible compiler errors

[Alex Rønne Petersen]

On 30-07-2012 18:38, Gor Gyolchanyan wrote:

On Mon, Jul 30, 2012 at 8:31 PM, Stuart mailto:stu...@gmx.com>> wrote:

I'm trying to write an actual program in D, but no matter what I do
I get stupid errors that mean nothing to me. (Reminds me of C++)

Error 42: Symbol Undefined
___D8infinity8standard7runtime4IA__pp4IApp11__InterfaceZ

Huh? This usually happens if I omit the module statement at the top
of EVERY DAMN FILE (why???) but in this case I haven't omitted it,
yet I'm still getting the error.

Also, I get the following error:

Error 42: Symbol Undefined
_D3dfl8internal6winapi12ModuleInfoZ

The code producing this second error is:

 int Run() {
 import core.sys.windows.windows;
 import dfl.internal..winapi;
 MSG msg;
 while (GetMessageA(&msg, null, 0, 0)) {
 TranslateMessage(&msg);
 DispatchMessageA(&msg);
 if (msg.hwnd && !IsWindow(msg.hwnd)) break;
 }
 return 0;
 }

What the HELL is this "ModuleInfo", why is it necessary, why is it
always missing when a "module" statement is not present, and why is
it missing NOW?


For one, it would be mighty polite of the compiler


linker


to demangle the
"___D8infinity8standard7runtime4IA__pp4IApp11__InterfaceZ", which
happens to be "infinity.standard.runtime.App.App.__Interface".

The ModuleInfo is a half-working runtime reflection structure, which the
compiler successfully fails to build when you omit the optional module
declaration.

--
Bye,
Gor Gyolchanyan.


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: One against binary searches

[Xinok]

On Monday, 30 July 2012 at 15:40:32 UTC, bearophile wrote:
This author writes very detailed analyses of low-level 
computational matters, that appear on Reddit. This blog post he 
suggests to introduce "offseted binary" or "quaternary search" 
instead of binary search in Phobos:


http://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/

Bye,
bearophile


My stable sort makes heavy use of binary searches [1], so just 
for fun, I tried inserting a ternary search before the binary 
search. After some optimizing, I found it ideal to use ternary 
search on ranges larger than 8KiB (with 32KiB L1D cache) and 
binary search on anything less. While sorting using additional 
space saw no improvement, in-place sorting went from 408ms to 
371ms. As well, there's a very negligible increase in the number 
of comparisons.



[1] https://github.com/Xinok/XSort/blob/master/stablesort.d#L331

Re: Incomprehensible compiler errors

[Gor Gyolchanyan]

On Mon, Jul 30, 2012 at 8:31 PM, Stuart  wrote:

> I'm trying to write an actual program in D, but no matter what I do I get
> stupid errors that mean nothing to me. (Reminds me of C++)
>
>Error 42: Symbol Undefined
>_**D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ
>
> Huh? This usually happens if I omit the module statement at the top of
> EVERY DAMN FILE (why???) but in this case I haven't omitted it, yet I'm
> still getting the error.
>
> Also, I get the following error:
>
>Error 42: Symbol Undefined
>_D3dfl8internal6winapi12__**ModuleInfoZ
>
> The code producing this second error is:
>
> int Run() {
> import core.sys.windows.windows;
> import dfl.internal.winapi;
> MSG msg;
> while (GetMessageA(&msg, null, 0, 0)) {
> TranslateMessage(&msg);
> DispatchMessageA(&msg);
> if (msg.hwnd && !IsWindow(msg.hwnd)) break;
> }
> return 0;
> }
>
> What the HELL is this "ModuleInfo", why is it necessary, why is it always
> missing when a "module" statement is not present, and why is it missing NOW?
>

For one, it would be mighty polite of the compiler to demangle the "_**
D8infinity8standard7runtime4IA**pp4IApp11__InterfaceZ", which happens to be
"infinity.standard.runtime.App.App.__Interface".

The ModuleInfo is a half-working runtime reflection structure, which the
compiler successfully fails to build when you omit the optional module
declaration.

-- 
Bye,
Gor Gyolchanyan.

Incomprehensible compiler errors

[Stuart]

I'm trying to write an actual program in D, but no matter what I 
do I get stupid errors that mean nothing to me. (Reminds me of 
C++)


   Error 42: Symbol Undefined
   _D8infinity8standard7runtime4IApp4IApp11__InterfaceZ 

Huh? This usually happens if I omit the module statement at the 
top of EVERY DAMN FILE (why???) but in this case I haven't 
omitted it, yet I'm still getting the error.


Also, I get the following error:

   Error 42: Symbol Undefined
   _D3dfl8internal6winapi12__ModuleInfoZ

The code producing this second error is:

int Run() {
import core.sys.windows.windows;
import dfl.internal.winapi;
MSG msg;
while (GetMessageA(&msg, null, 0, 0)) {
TranslateMessage(&msg);
DispatchMessageA(&msg);
if (msg.hwnd && !IsWindow(msg.hwnd)) break;
}
return 0;
}

What the HELL is this "ModuleInfo", why is it necessary, why is 
it always missing when a "module" statement is not present, and 
why is it missing NOW?

Re: What is rape?

[Simen Kjaeraas]

On Mon, 30 Jul 2012 18:23:57 +0200, Stuart  wrote:



What. The. Fuck?


Don't feed the troll.

--
Simen

Re: What is rape?

[Gor Gyolchanyan]

On Mon, Jul 30, 2012 at 8:23 PM, Stuart  wrote:

>
> What. The. Fuck?
>

Never mind. Traditional ethanol-driven cow dunk. The usual solution is to
let it sober out.

-- 
Bye,
Gor Gyolchanyan.

Re: What is rape?

[Stuart]

What. The. Fuck?

One against binary searches

[bearophile]

This author writes very detailed analyses of low-level 
computational matters, that appear on Reddit. This blog post he 
suggests to introduce "offseted binary" or "quaternary search" 
instead of binary search in Phobos:


http://www.pvk.ca/Blog/2012/07/30/binary-search-is-a-pathological-case-for-caches/

Bye,
bearophile

What is love?

[FeepingCreature]

What is love, "baby"?

Don't "hurt me". No "more".

Re: Impressed

[FeepingCreature]

On 07/27/12 21:22, Stuart wrote:
> On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
>>
>> Nevertheless, D has gotten to the point where it's powerful enough that most 
>> feature requests can be implemented in a
>> library rather than as a language extension.
> 
> How could Yield be implemented as a library feature? Something like:
> 
>return ITERATOR(
>   { ...setup code ... },
>   { ...loop body code... })
> 
> ?
> 
> I don't see how that would work.

The threading "yield" and the iterator "yield" are actually strongly related. 
By yielding a coroutine, you can effectively suspend a routine
and resume it later. Let me give you an example:

int delegate() genEvenNumbers() {
  // not actual api
  return startCoroutineIterator!int((void delegate(int) yield) {
for (int i = 0; true; i++) if (i % 2 == 0) yield(i);
  });
}

// long form of the above function, so you can see how you gain iterator-style 
behavior via coroutines
int delegate() genEvenNumbers() {
  int* resultp = new int;
  void cofun(void delegate(int) yield) {
for (int i = 0; true; i++) if (i % 2 == 0) yield(i);
  }
  // still not actual api
  auto coroutine = new Coroutine(1024*1024 /* stack size */);
  // set the 'main function' of the coroutine
  coroutine.fun = {
// yield, when called, will cause the coroutine to suspend and run() to 
return
cofun((int i) { *resultp = i; coroutine.yield(); });
  };
  // run the coroutine up to the next yield, then return yielded value
  return { coroutine.run(); return *resultp; };
}

You can fully implement Coroutine as a library, provided you're somewhat 
confident with x86 assembly and stack frame layouts.

Re: std.variant benchmark

[Don Clugston]

On 30/07/12 13:24, Andrei Alexandrescu wrote:

On 7/30/12 4:34 AM, Dmitry Olshansky wrote:

On 30-Jul-12 06:01, Andrei Alexandrescu wrote:

In fact memcpy could and should be replaced with word by word copy for
almost all of struct sizes up to ~32 bytes (as size is known in advance
for this particular function pointer i.e. handler!int).


In fact memcpy should be smart enough to do all that, but apparently it
doesn't.



I'd say array ops could and should do this (since compiler has all the
info at compile-time). On the other hand memcpy is just one tired C
function aimed at fast blitting of any memory chunks.
(Even just call/ret pair is too much of overhead in case of int).


memcpy is implemented as an intrinsic on many platforms. I'm not sure
whether it is on dmd, but it is on dmc
(http://www.digitalmars.com/ctg/sc.html), icc, and gcc
(http://software.intel.com/en-us/articles/memcpy-performance/). But then
clearly using simple word assignments wherever possible makes for a more
robust performance profile.


It is an intrinsic on DMD, but it isn't done optimally. Mostly it just 
compiles to a couple of loads + the single instruction

rep movsd; / rep movsq;
which is perfect for medium-sized lengths when everything is aligned, 
but once it is longer than a few hundred bytes, it should be done as a 
function call. (The optimal method involves cache blocking).

Also for very short lengths it should be done as a couple of loads.

Re: std.variant benchmark

[Andrei Alexandrescu]

On 7/30/12 4:34 AM, Dmitry Olshansky wrote:

On 30-Jul-12 06:01, Andrei Alexandrescu wrote:

In fact memcpy could and should be replaced with word by word copy for
almost all of struct sizes up to ~32 bytes (as size is known in advance
for this particular function pointer i.e. handler!int).


In fact memcpy should be smart enough to do all that, but apparently it
doesn't.



I'd say array ops could and should do this (since compiler has all the
info at compile-time). On the other hand memcpy is just one tired C
function aimed at fast blitting of any memory chunks.
(Even just call/ret pair is too much of overhead in case of int).


memcpy is implemented as an intrinsic on many platforms. I'm not sure 
whether it is on dmd, but it is on dmc 
(http://www.digitalmars.com/ctg/sc.html), icc, and gcc 
(http://software.intel.com/en-us/articles/memcpy-performance/). But then 
clearly using simple word assignments wherever possible makes for a more 
robust performance profile.



I'm thinking more of it and common types are just uint, int, long,
ulong, double, string. In fact most of e.g. int x string and such are
"throw me an exception" entries, they could be merged.
Then we could make 2-stage table to save some space, it sounds like
trie, hm


You can implement it via visitation too (two indirect calls, no search). 
"Modern C++ Design" discusses possible approaches at length.



Andrei

Re: Impressed

[Christophe Travert]

Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
> scope on local variables is going away for pretty much the same reason that 
> delete is. They're unsafe, and the fact that they're in the core language 
> encourages their use. So, they're being removed and put into the standard 
> library instead.
> 

I don't mind scope going away, since it can be replaced with a library 
solution. But scope is not more dangerous than a static array, or simple 
function variables. Slice them, or take their reference, and you're up 
for troubles. Do you think they should be removed as core features of 
the langage?

Re: std.random and mersenne twister

[monarch_dodra]

On Tuesday, 24 July 2012 at 16:09:15 UTC, monarch_dodra wrote:
That said, I don't think it would be a bad idea to add a Lagged 
Fibonacci generator first. The generator already exists in 
boost, and is much more documented. The actual development 
would just require a port.


Hi There!

I wrote the port.
https://github.com/D-Programming-Language/phobos/pull/727

It works as intended, AFAIK, as it generates the exact same 
sequence that boost does.


I'd be mighty pleased to have code review done on it.

The details are on the pull page, but I guess you can also leave 
some feedback here.

Re: Impressed

[Paulo Pinto]

On Sunday, 29 July 2012 at 22:22:33 UTC, Walter Bright wrote:

On 7/27/2012 7:38 PM, Jonathan M Davis wrote:
True, but I'm kind of shocked that anything 16-bit even still 
exists. _32-bit_
is on its way out. I thought that 16-bit was dead _years_ ago. 
I guess that
some embedded stuff must use it. But really, I wouldn't expect 
the lack of 16-
bit support to be much of an impediment - if any at all - and 
in the long run,

it'll mean absolutely nothing.


For those who may not realize it, C++ is simply not suitable 
for 16 bit systems either. It theoretically supports 16 bit 
code, but in practice, full C++ will never work on them.


So, you might ask, why was 16 bit C++ popular on 16 bit MSDOS 
in the 80's? That was C++ before exception handling and RTTI, 
both of which were unimplementable on 16 bit machines. (Yes, 
you could do it, but the result was practically unusable.)


I remember using both features with Borland compilers.

But then I was around 16 years old and was not doing anything 
serious

with C++, besides getting to know the language.

On those days, Turbo Pascal was my number one choice for serious 
software.




C and 16 bits go reasonably well together, but even so, the 
best programs were written all in asm.

What is rape?

[ProHeckler]

A "president" with your attention and raping you for property taxes?

"Vote" for a militant? Is "shasha" the next body bag? Mayve you get your 
dick out of others' live's rapist? Help me to understand that your dick 
lives and other people die. I'm drunk, but I want to know why your sperm is 
safe. or something. I cannot get drunk as often as you would want to rape 
me. So take your rape, and shove it up your ass.

Re: Impressed

[Paulo Pinto]

On Monday, 30 July 2012 at 07:57:47 UTC, Era Scarecrow wrote:

On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:

On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:

On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
The problem is that in the enterprise world with expendable 
programmers, is very hard to do JVM based projects with 
anything other than Java.


My experience from various training courses I have given is 
that in the large corporate Web applications world, the 
average programmer knows Java, just enough Java, and isn't 
that interested in anything else. Gross oversimplification 
but a good indicator.


That is actually the case.


 The only thing I walked away with after I learned java as part 
of a programming course, was how polymorphism and interfaces 
worked in OO programming.


 I just really wish they would change their courses for 'this 
is inheritance with animals!' which although logically makes 
sense (in a dictionary wikipedia way) but structurally and 
programming-wise doesn't. Describing it as a building block for 
a game (like item) would have made much more sense.


It always depends how lucky you get with who teaches you. I 
learned OO with

Turbo Pascal 6.0, as I prepared a class about OO in high school.

Afterwards it was time to learn with OO the C++ way.

Before Java I was exposed to OO in Smalltalk, CLOS, Eiffel, 
Modula-3, Oberon,

Python.

Not only the languages, but OO abstract design in the form of 
Boochs and UML methods.


So when I came to lean Java, many things felt natural, and I was 
not contaminated like many, with the idea that OOP == Java.


--
Paulo

What is war, "mr president"?

[ProHeckler]

Define it. I think it means you get to live while others die. Oh, what is 
the "definition" ("the law") of "president"?

I assure you there is no war. I assure you that no one wants your or anyone 
else's hell.

You're fired. You're not the best that the system can produce. Else you'd 
die for it. Take your fucking politics and shove it up Shasha's ass, "Mr 
president".  I don't want you to "put up or shut up".  There is no war, and 
you take your fucking politcs and shove it up your daughter's ass.

It is easy to say when drunk. That is not to say it is irrelevanat. That is 
not to say it is bad. Ah, in my whole life, I am not afraid of you? Why 
don't you shut the fuck up, stand the fuck down, and get the fuck out of my 
face?

(One must be afraid to speak? "freedom of speech" is a criminal defense? 
Fuck you. And the rape ou rode in on.) 

Re: std.variant benchmark

[Dmitry Olshansky]

On 30-Jul-12 06:01, Andrei Alexandrescu wrote:

In fact memcpy could and should be replaced with word by word copy for
almost all of struct sizes up to ~32 bytes (as size is known in advance
for this particular function pointer i.e. handler!int).


In fact memcpy should be smart enough to do all that, but apparently it
doesn't.



I'd say array ops could and should do this (since compiler has all the 
info at compile-time). On the other hand memcpy is just one tired C 
function aimed at fast blitting of any memory chunks.

(Even just   call/ret pair is too much of overhead in case of int).


I've found something far more evil:

[snip]

So to boot in order to get to int + int _detected_ it needs 4 calls to
fptr(OpID.testConversion, null, &info) == 0 and acquire TypeInfo each
time. Not counting 2 gets to obtain result. It's just madness.


Heh, this all gives me a new, humbling perspective on my earlier self
running my mouth about other designs :o). As always, history and context
makes one much more empathic.

Variant has a very old design and implementation. It is, in fact, the
very first design I've ever carried in D; I'd decided, if I can't do
that, D isn't powerful enough. The compiler was so buggy back then,
implementation needed to take many contortions, and it was a minor
miracle the whole house of cards stood together.



These were indeed very rough days. I think it's a minor miracle I 
haven't gave up on D after seeing tons of bugs back in 2010.



The basic approach was to use a pointer to function (instead of an
integral) as a discriminator. The pointer to function was taken from the
instantiation of a template function. That means Variant could work with
any type, even types not yet defined. I'd made it a clear goal that I
must not enumerate all types in one place, or "register" types for use
with Variant - that would have been failure. Using a pointer to template
function naturally associated a distinct tag with each type,
automatically. I think it was a good idea then, and it's a good idea now.


It's indeed nice trick and design sounds great (no register function, yay!).
The only piece missing is that e.g. arithmetic operations are binary 
thus requiring double-dispatch or something like 
arithmeticHandler!(T1,T2) to archive optimal performance.


The virtual handcrafted C competition would do it via nested switches.

[snip]

We can use the pointer to function as a tag for improving performance on
primitive types.



Indeed we can though it won't be as fast as simple tag - pointers
have quite big and sparse addresses giving us the same as:

if(ptr == handler!int)

else if(ptr == handler!uint)

else



Yes, and what we gain is speed for select known types. As long as the
number of those is relatively small, using simple test and branch should
serve us well. And we get to keep the generality, too.



OK I'll try it for opArithmetic that should help a lot.


Another way to go is make 2-d function table for all built-ins and all
operations on them. It's in fact a bunch of tables:
Type1 x Type2 for all of important basic operations. Tables are static
so it won't be much of a problem. At least int + int then would be
1 memory read, 1 call, 2 (casted as needed) reads & 1 store.


I think that's not worth it, but hey, worth a try.



I'm thinking more of it and common types are just uint, int, long, 
ulong, double, string. In fact most of e.g. int x string  and such are 
"throw me an exception" entries, they could be merged.
Then we could make 2-stage table to save some space, it sounds like 
trie, hm



--
Dmitry Olshansky

Is "a president" a wanker?

[ProHeckler]

Is "the president" beyond his own fantasy of "law"?

Is there a war? Ask your "president to prove it". I think that creep will 
step down. 

Re: Impressed

[Era Scarecrow]

On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:

On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:

On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
The problem is that in the enterprise world with expendable 
programmers, is very hard to do JVM based projects with 
anything other than Java.


My experience from various training courses I have given is 
that in the large corporate Web applications world, the 
average programmer knows Java, just enough Java, and isn't 
that interested in anything else. Gross oversimplification but 
a good indicator.


That is actually the case.


 The only thing I walked away with after I learned java as part 
of a programming course, was how polymorphism and interfaces 
worked in OO programming.


 I just really wish they would change their courses for 'this is 
inheritance with animals!' which although logically makes sense 
(in a dictionary wikipedia way) but structurally and 
programming-wise doesn't. Describing it as a building block for a 
game (like item) would have made much more sense.

Re: A successful Git branching model

[Brad Anderson]

On Sun, Jul 29, 2012 at 11:53 PM, Russel Winder wrote:

> I don't really see the advantage of separating develop and master.
>
>
master isn't strictly necessary since everything is tagged anyway.  It just
serves as a nice way to see the current release's source code (a pointer to
the latest release). You could just use "master" in place of "develop" and
have a "production" branch fill the role that "master" does in this model
just as easily.


> And personally I am not a great fan of having feature branches in the
> mainline repository.
>
>
They aren't in this model. If you need to share a feature branch with
someone else prior to a pull request they can just pull from your branch on
GitHub directly.


> There is a lot about the document and the ideas that are good, but I
> don't follow the whole model. For me master is the development branch –
> and if using continuous delivery can always be branched and released.
> All major and minor releases have separate maintenance branches. with
> bugfix releases being tags on that.  This seems enough, I am not sure of
> the usefulness of anything more complex. But I may be missing something.
>

It can be modified to fit whatever the need is, of course, but there is a
lot of value in how well it is documented.  Any changes made or alternative
models used should be well documented too to lower the barrier to entry for
contributors. Everyone needs to be working from the same mental model.

Regards,
Brad Anderson

Re: std.variant benchmark

[Gor Gyolchanyan]

On Mon, Jul 30, 2012 at 6:07 AM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:

> On 7/29/12 11:20 AM, Gor Gyolchanyan wrote:
>
>> On Sun, Jul 29, 2012 at 6:43 PM, Dmitry Olshansky > **> wrote:
>> This should be more relevant then:
>>
>> //fib.d
>> import std.datetime, std.stdio, std.variant;
>>
>> auto fib(Int)()
>> {
>>  Int a = 1, b = 1;
>>  for(size_t i=0; i<100; i++){
>>  Int c = a + b;
>>  a = b;
>>  b = c;
>>  }
>>  return a;
>> }
>>
>> void main()
>> {
>>  writeln(benchmark!(fib!int, fib!long, fib!Variant)(10_000));
>> }
>>
>>
>> dmd -O -inline -release fib.d
>>
>> Output:
>>
>> [TickDuration(197), TickDuration(276), TickDuration(93370107)]
>>
>> I'm horrified. Who was working on std.variant enhancements? Please
>> chime in.
>>
>> --
>> Dmitry Olshansky
>>
>>
>> Thank you for demonstrating my point. :-)
>>
>
> I don't think he demonstrated your point (even leaving aside that the
> benchmark above is also flawed). I don't think there was a point, unless it
> was you wanted to vent and looked for a pretext - which is, by the way,
> entirely reasonable.
>
> You mentioned you need "a very fast typeless storage with maximum
> performance and type safety." Well if it's typeless then it means you're
> using it for storage, not for computationally-intensive operations, as the
> code above does. So what you'd presumably want to test is the speed of data
> storage and retrieval. A loop that does a bunch of adds on Variant does not
> go in that direction.
>
> Benchmarks are notoriously hard to get right. You need to think of
> reasonable baselines - if you want to use Variant for typeless storage,
> what is your vanilla implementation, the "obvious contender"? What are the
> primitives of which speed is important? Then you need to make sure you
> subtract noise from all your comparisons. Then you need to figure whether
> the issue is with the design or with the implementation of Variant. In the
> former case, maybe Variant isn't for you. In the latter, bug reports are
> always welcome.
>
>
> Andrei
>

You're right. I'm trying to make a subject-oriented system, where there are
nodes and accessors and each accessor has access to a specific part of the
node. I must have the data stored in typeless manner and cast to the
appropriate type (depending on the accessor). This is all necessary for my
very flexible graph data structure.

-- 
Bye,
Gor Gyolchanyan.

Re: D language and .NET platform

[ProHeckler]

Mike Parker wrote:
> On 7/30/2012 12:30 AM, EngineerSpock wrote:
>> There is a couple of questions.
>
>> 4. Are there many libraries for D? Can D just use C\C++ dll's without
>> pain for programmer?
>>
>
> There are a number of libraries covering different domains,

More ammo for a war that does not exist?

Re: D language and .NET platform

[ProHeckler]

David Piepgrass wrote:
> On Sunday, 29 July 2012 at 16:32:10 UTC, Alex Rønne Petersen
> wrote:
>> On 29-07-2012 17:36, bearophile wrote:
 .NET is too limited to represent the language,
>>> Can you tell us why?
>> Array slices. The .NET type system has no way to represent them
>> because it's designed for precise GC, and array slices allow
>> interior pointers in the heap (as opposed to the stack when
>> passing a field of an object by reference to a function, or
>> whatever).
>
> D is theoretically designed

That is to say it is non-designed.

Re: D language and .NET platform

[ProHeckler]

Vladimir Panteleev wrote:
> On Sunday, 29 July 2012 at 17:11:55 UTC, Timon Gehr wrote:
>> This could get a little hairy:
>>
>> struct S{
>> int x,y;
>> }
>>
>> void main(){
>> S s;
>> auto p = &s.y;
>> // ...
>> }
>
> How does C++ for .NET handle this?

It didn't. Microsoft is about to do that. I'm thinking I should be a little 
asheamed. What do you think? 

Re: D language and .NET platform

[ProHeckler]

Chad J wrote:

> I still always thought it funny that we didn't reach for it anyways.

"we"? Surely you meant you ("I"). Hmm? You saw the movie (?). "The Quick, 
and the Dead". You cannot be quick, for you are not "quick". Thank you, you 
are not a gunslinger. (Romance, timeout please). "They" "love" the quick 
shooter, huh. Analogyy to "those who gab, have nothing to say"? (I don't 
know 'analogy' from 'metaphor'). What does "reach for it" mean? Something 
about 1984 chimes true.

Oh, but "they" "didn't know". Isn't *that* convenient. Because if you as an 
individual don't know, it is a crime. But if those in on the take do wrong, 
it's a free ride to being the next horror, and it becomes "law".

Re: Impressed

[Paulo Pinto]

On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:

On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
[…]
The problem is that in the enterprise world with expendable 
programmers, is very hard to do JVM based projects with 
anything other than Java.


My experience from various training courses I have given is 
that in the
large corporate Web applications world, the average programmer 
knows
Java, just enough Java, and isn't that interested in anything 
else.

Gross oversimplification but a good indicator.


That is actually the case.

Re: D language and .NET platform

[ProHeckler]

Timon Gehr wrote:
> On 07/29/2012 06:32 PM, Alex Rønne Petersen wrote:
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
 .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them
>> because it's designed for precise GC, and array slices allow
>> interior pointers in the heap (as opposed to the stack when passing
>> a field of an object by reference to a function, or whatever).
>>
>
> I think all of CTFE-D should map to .NET without much hassle.
>

No, you cannot wank as an adolescent forever. There are too many males and 
you know it so you are afraid of "growing up", but it really is not up to 
you. 

Re: D language and .NET platform

[ProHeckler]

Timon Gehr wrote:

>
> This could get a little hairy:
>

A boy's dream? 

Re: D language and .NET platform

[ProHeckler]

Simen Kjaeraas wrote:
> On Sun, 29 Jul 2012 18:32:08 +0200, Alex Rønne Petersen
>  wrote:
>
>> On 29-07-2012 17:36, bearophile wrote:
>>> Alex Rønne Petersen:
>>>
 .NET is too limited to represent the language,
>>>
>>> Can you tell us why?
>>>
>>> Bye,
>>> bearophile
>>
>> Array slices. The .NET type system has no way to represent them
>> because it's designed for precise GC, and array slices allow
>> interior pointers in the heap (as opposed to the stack when passing
>> a field of an object by reference to a function, or whatever).
>
> So one couldn't simply use a two-level system, with a slice
> referencing an array, and holding an offset and a length?

D is a programming language. Why don't you go to your metrosexual sushi bar 
and "talk programming", bitch? 

Re: D language and .NET platform

[ProHeckler]

bearophile wrote:
> Alex Rønne Petersen:
>
>> .NET is too limited to represent the language,
>
> Can you tell us why?
>

He's playing you, sucker. 

Re: D language and .NET platform

[ProHeckler]

Alex Rønne Petersen wrote:
> On 29-07-2012 17:30, EngineerSpock wrote:
>> There is a couple of questions.
>>
>> 1. What about interoperability of D and .NET platform?
>
> You should be able to write C routines in D that .NET's P/Invoke can
> call.
>> 2. What is the difference between pure D and D for .NET?
>
> D for .NET is dead because .NET is too limited to represent the
> language, so describing this isn't really worthwhile. :)

That is "a lie" (save for you may not know). .net is a Microsoft product at 
the API-ish level. It "strikes a cord" with "real" programmers, surely. Alex 
needs to be more careful when he posts.  .net is not dead. Not even NOT 
relevant for D. D is at the language level. (AKA, "the language level"). 
"It", cannot address higher level concerns, for it is not even evolved or 
relevant as a child. "Lord of the Flies" and D, have something in common? 
Learning perhaps? Is D an island of childish thought "promogulated" with the 
zeal of an adolescent "guitar hero", "re"inventing "rock-n-roll" and wanking 
his pecker? The island is overloaded with comers. "freedom reigns", and then 
you grow up. Then what? The drug stops. You realize your enemy is 
formidable. Your scope has been small. But your enemy knew that all along. 
And you might even realize that pissing in the wind and beating it, was your 
same old spiel. The wind is not your enemy. And neither is time. You battle, 
and are too quick to battle, that which you do not know. I assure you that 
all you battle is time. And time is not interested in your childish games. 
You are going to lose. A war that does not exist, save for only your 
"lordness", which begs the question is D a lemon tree worthy of pissing on? 
I think it is dismissabke without conjecture. Exclude the masturbatory 
adolescnet males and you have... tada! What? Nothing? Guitar hero. Lord of 
the flies?

Close this wank room.