date:20140226

On Wednesday, 26 February 2014 at 07:00:33 UTC, Brian Schott 
wrote:

On Monday, 24 February 2014 at 19:05:35 UTC, Dicebot wrote:
Brian, do you have benchmarks for this proposal similar to 
ones you have provided in old review threads? (vs DMD frontend 
lexer)


Not yet, but I can create them before the review period ends.


Thanks, that will be very interesting information to consider in 
context of DDMD.

Re: Top-3 for 2.066

2014-02-26 Thread Tofu Ninja


On Wednesday, 26 February 2014 at 14:59:53 UTC, Tofu Ninja wrote:

a 10 ten does hold more value than a top 50 or top 100. But

top 10*

Re: Top-3 for 2.066

On Wednesday, 26 February 2014 at 12:19:32 UTC, Daniel Murphy 
wrote:
it simply means "I have encountered this bug"/"I have seen this 
bug report".


But it is also quite useful statistis on its own - how often 
specific issue is encountered by random D user.

Re: Manual Memory Management Example for dlang.org Docs (Code Review)


On Wednesday, 26 February 2014 at 04:43:30 UTC, Mike wrote:

Please review this (http://dpaste.dzfl.pl/2377217c7870) instead.



throw new Exception("Out of memory");


I don't think it is a good thing to do. Of course GC is likely to 
have some memory left in hs internal pools but in general once 
you hit out-of-memory state last thing you want is not allocate 
even more.



// Deallocate test
heapDeallocate(test);


More idiomatic D is to put `scope(exit) heapDeallocate(test);` 
immediately after allocation line.

Re: Formal review of std.lexer

2014-02-26 Thread Andrei Alexandrescu


On 2/25/14, 10:58 PM, Brian Schott wrote:

On Tuesday, 25 February 2014 at 23:17:56 UTC, Meta wrote:

std.lexer could be the umbrella for a bunch of different lexers. Then
we could have std.lexer.xml, std.lexer.json, etc.


I think that's a bit backwards. I'd rather have

std.d.lexer
std.d.ast
std.d.parser

than

std.lexer.d
std.parser.d
std.ast.d


I think we wouldn't want to add one more package for each language 
supported.


Andrei

Re: Top-3 for 2.066


On Wednesday, 26 February 2014 at 10:36:14 UTC, Per Nordlöw wrote:
Make it possible to defined implicit conversions between 
wrapped types in order to, for instance, correctly implement 
NotNull for reference types.


I'm pretty sure multiple alias this would do the trick.

interface A {}
interface B {}
class C : A, B {}
class D : C {}

NotNull!D should implicitly cast to NotNull!C AND to D (the 
latter gives access to the methods here too so it should be 
preferred).


NotNull!C should implicitly cast to C (the first one to try), 
NotNull!A, NotNull!B, and NotNull!Object.


Multiple alias this would allow that.

https://d.puremagic.com/issues/show_bug.cgi?id=6083

Re: Cumulative

2014-02-26 Thread Steve Teale

On Wednesday, 26 February 2014 at 13:30:15 UTC, Leandro Motta 
Barros wrote:

Hello,

I'm coming late to the discussion, but I believe that you can 
use the

following idiom to achieve the same results in a different way:


Yes we went through that, if you go back a page you'll find a 
post I did that makes the thing work better using a class 
variable in the base class that is an array of delegates.


That way you don't have to do super, super, super back to root, 
you just have to iterate over the delegates until you find one 
that accepts the command.


It does just what I wanted to do in the first place without 
compiler assistance

 ;=).

Steve

Re: Typed GC

2014-02-26 Thread evansl


On 02/12/14 06:11, Shammah Chancellor wrote:

With all the talk of garbage collection.  I was wondering if it would be
useful to make the GC typed.  If it was typed, it maybe be possible to
make it more efficient via type information, (such as only scanning
reference fields).   Also, it could have access to attribute information
if applicable.

-S.


Hi Shammah,

In an earlier thread, Andrei proposed:

  I suspect that allocating and manipulating objects on the GC heap in
  particular may have certain restrictions. One possibility to avoid
  such restrictions is to have a function typify(T)(void* p) which
  ascribes type T to heap location p.

which would be one way to at least record the type of each memory 
location.  However, later posts in that thread indicated there

were problems with where to store that information.  I thought
you could store it in the heap along side the pointed to object;
however, that seemed to have problems, according to this post:

http://forum.dlang.org/thread/lao9fn$1d70$1...@digitalmars.com?page=12#post-jgommvkndygzcpxxotly:40forum.dlang.org

So, the idea seems good, but I'd guess implementation is problematic.
At least that's what I guess from the referenced posts.

-regards,
Larry

Re: A Proposal to Add 2D Graphics Rendering and Display to C++

2014-02-26 Thread Andrej Mitrovic


On Wednesday, 26 February 2014 at 16:40:59 UTC, NA wrote:

This is an updated document and is quite interesting.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf

NA


Design by committee? :)

A Proposal to Add 2D Graphics Rendering and Display to C++

2014-02-26 Thread NA


This is an updated document and is quite interesting.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf

NA

Re: Typed GC

2014-02-26 Thread evansl


On 02/26/14 10:25, evansl wrote:

On 02/12/14 06:11, Shammah Chancellor wrote:

With all the talk of garbage collection.  I was wondering if it would be
useful to make the GC typed.  If it was typed, it maybe be possible to
make it more efficient via type information, (such as only scanning
reference fields).   Also, it could have access to attribute information
if applicable.

-S.


Hi Shammah,

In an earlier thread, Andrei proposed:

   I suspect that allocating and manipulating objects on the GC heap in
   particular may have certain restrictions. One possibility to avoid
   such restrictions is to have a function typify(T)(void* p) which
   ascribes type T to heap location p.

which would be one way to at least record the type of each memory
location.  However, later posts in that thread indicated there
were problems with where to store that information.  I thought
you could store it in the heap along side the pointed to object;
however, that seemed to have problems, according to this post:

http://forum.dlang.org/thread/lao9fn$1d70$1...@digitalmars.com?page=12#post-jgommvkndygzcpxxotly:40forum.dlang.org


So, the idea seems good, but I'd guess implementation is problematic.
At least that's what I guess from the referenced posts.

-regards,
Larry


OOPS.  Just read Benjamin's post:

http://forum.dlang.org/post/ldhquc$11ec$1...@digitalmars.com

and then the druntime code:

https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/object_.d#L2629

which contains:

immutable(void)* m_RTInfo; // data for precise GC

override @property immutable(void)* rtInfo() const
{ return m_RTInfo; }

So, I guess m_RTInfo contains information from which the pointers
within the object can be precisely found.

Sorry for noise :(

-Larry

Re: Practical Problems with distribution D projects

2014-02-26 Thread Assaf Gordon


On 02/25/2014 05:41 PM, Dicebot wrote:


I see, your requirements do not match use case of a typical desktop
application.


This is the root cause of our different POVs - I should have explained it more 
clearly.

My users are people who have access to Linux machines which they do not control.
I can expect them to be able to handle the standard/easy steps of compiling 
software, but not much more.

This is the case in many universities, were the computer "cluster" is made of 
whatever Linux the IT department used.
You won't get root access on those servers. And many time the distribution is 
very old and not updated on purpose (for the sake of stability).
To make matters more complicated, many additional programs are installed in places like 
"/usr/local/" and "/opt/".
It might make you cringe you as a maintainer (it makes me cringe, as a 
root-less user) ... but that's life :)

Now, I have to be realistic:
My program will be useful to some degree, but not a life-changing Killer-App.
If it's easy to use and install, people will use it (and by proxy, perhaps use 
D as well, if they want to hack the code).
If it's too complicated, they'll give up and look for a different solution.

So my goal to begin with, was to find the easiest way to distribute my D 
program to unix platforms.


However, if you are fine with full static linking why
not simply distribute binary tarballs for set of systems you want to
support? It will put burden of having proper D compilation
environment away from the end user.



We've come full circle :)

In my first message in this thread, I wrote (item #3), that unless I'm missing 
something, there is no way to build a statically linked binary with D on Linux. 
If there is a way, I would love to know about it.
I would gladly spend the time to create VMs for each common system setup and 
package a static binary for it.

 

I know it is not very convenient with Debian because of how
conservative it is but in Arch just asking in #archlinux @ freenode
is likely to result in kind soul willing to help with packaging
questions. Or even easier, just contacting me as it is my direct
responsibility to maintain all D-related projects in Arch [community]
;)



I got one package into Debian, and it took some effort. But it was worth it, 
because I learned alot, and it did make my program better (distribution wise).
Arch and Gentoo might be friendlier (and HomeBrew/LinuxBrew even easier), but 
the people I'm aiming for aren't using Arch or Gentoo...

I do have high hopes for HomeBrew/LinuxBrew, as "brew install dmd" and "brew install 
dub" seems to work nicely on some linux systems.

Best,
 -gordon

Re: A Proposal to Add 2D Graphics Rendering and Display to C++

2014-02-26 Thread Russel Winder

On Wed, 2014-02-26 at 16:40 +, NA wrote:
> This is an updated document and is quite interesting.
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf
> 

https://groups.google.com/a/isocpp.org/forum/#!
msg/std-proposals/IaaG316uPjo/9N4YsRYX4nkJ

Is worth a look.

-- 
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

Re: A Proposal to Add 2D Graphics Rendering and Display to C++

2014-02-26 Thread NA

On Wednesday, 26 February 2014 at 17:10:01 UTC, Russel Winder 
wrote:

On Wed, 2014-02-26 at 16:40 +, NA wrote:

This is an updated document and is quite interesting.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3888.pdf



https://groups.google.com/a/isocpp.org/forum/#!
msg/std-proposals/IaaG316uPjo/9N4YsRYX4nkJ

Is worth a look.


The thread you pointed to has a link to the reference 
implementation.


https://github.com/mikebmcl/N3888_RefImpl

NA

Re: Practical Problems with distribution D projects


On Tuesday, 25 February 2014 at 17:04:11 UTC, John Colvin wrote:
If by "works for the end user" you mean that you go to a 
(different for every app) website


I always thought that was the sane way to do it, different 
website for every app, though I loathe and despise chasing down 
library dependencies.


static linking ftw

other program that does the actual installation... then yes, I 
guess it does :)


Eh, my standard is dmd: get a zip and run the program with a 
reasonable expectation that it will just work. I don't like 
installers either.



How can any of those be said to not work for the end user?


yum install php

gets php 5.1, but my other app needs 5.2

something something epel key whatever

yum update php

got php 5.2!  but php-gd isn't in that repo, so it still is 
5.1 and doesn't work.


wget http://php.net/downloads/whatever/php-5.2.tar.gz
tar zxf blah
cd blah
./configure

missing library X

yum install libx-devel

./configure

missing library Y

yum install liby-devel
no such package

*spend half an hour searching teh web*

yum install libwtf-devel # for some reason liby is in there

./configure

missing library Z

yum install libz-devel
no such package

wget http://libz.org/downloads/libz.tar.gz
tar zxf
cd
./configure

missing library


You get the idea. finally get that working

cd php
./configure

library Z is version 3.1 but php requries 2.8


here we go again

*six hours later*


OH NO I FORGOT TO ADD --enable-gd TO CONFIGURE :-( :-( :-( here 
we go again


./configure --enable-gd --enable-whatever-else 

sudo make install

$ php
Segmentation fault



AAaaaAaaAaaaAaaRrrrReGGGHHGH. OK, I admit, I'm combining two 
different horror stories into one here, a php one and a recurring 
hassle I've had with gtk, but still, the point stands.



It's really very very simple and that's without even
discussing the GUIs for the point-and-clickers.


When it works, it is great, when it doesn't, you're in a world of 
pain. Getting into the repo can be a pain too, so can compiling 
everything.


On Windows, you just compile on your box and it tends to work on 
others. On Linux, you need a dozen different distros installed to 
build the compatible binaries to package...

Re: Practical Problems with distribution D projects

On Wednesday, 26 February 2014 at 17:08:38 UTC, Assaf Gordon 
wrote:
In my first message in this thread, I wrote (item #3), that 
unless I'm missing something, there is no way to build a 
statically linked binary with D on Linux.


They really aren't far from it out of the box:

$ dmd hellod.d
$ ldd hellod
linux-gate.so.1 =>  (0xe000)
libpthread.so.0 => /lib/libpthread.so.0 (0xf76db000)
libm.so.6 => /lib/libm.so.6 (0xf76b5000)
librt.so.1 => /lib/librt.so.1 (0xf76ac000)
libc.so.6 => /lib/libc.so.6 (0xf7549000)
/lib/ld-linux.so.2 (0xf773)


It isn't fully static, but those libraries are all pretty basic 
things and generally available on any linux install. The biggest 
problem is probably the libc version not matching on older 
installations.


One option might be to package those .so files right with your 
executable. A poor man's static link.



Anyway, let's try the -static switch we can use to do statically 
linked libc on some programs.


$ dmd hellod.d -c
$ gcc hellod.o -o hellod -m32 
-L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker --export-dynamic 
-l:libphobos2.a -lpthread -lm -lrt -static


undefined reference to `__tls_get_addr'


BTW if you run "dmd -v yourfile.d" the last line of output is the 
linker command line it runs (via gcc). Then you can copy/paste 
that and tweak the arguments. Here, I added -static.



However, that is *not* a D problem per se, that's a libc 
function. Maybe my system just doesn't have the right stuff 
installed to build a static threaded app.


I would gladly spend the time to create VMs for each common 
system setup and package a static binary for it.



If you're doing that, you don't need to do anything special, 
since the vm will link the appropriate libc version anyway, so 
the default build should work.



I betcha if I sent you my binary from my slackware box over to 
your computer it would work even if you are a different distro.

Re: Formal review of std.lexer


On 2014-02-26 07:58, Brian Schott wrote:


I think that's a bit backwards. I'd rather have

std.d.lexer
std.d.ast
std.d.parser

than

std.lexer.d
std.parser.d
std.ast.d


I agree with Brian. Although I would have a common package for all 
languages:


std.language.d.lexer
std.language.d.ast
std.language.d.parser

--
/Jacob Carlborg

Re: Formal review of std.lexer


On 2014-02-26 16:18, Andrei Alexandrescu wrote:


I think we wouldn't want to add one more package for each language
supported.


That's exactly what we want, preferably in a common package:

std.language.d.lexer
std.language.d.ast
std.language.d.parser

std.language.xml.lexer
std.language.xml.parser
std.language.xml.dom

What do you suggest, having multiple lexers for different languages in 
the same module?


--
/Jacob Carlborg

Re: Formal review of std.lexer


On 2014-02-26 00:25, Dicebot wrote:


Don't know if it makes sense to introduce random package categorizatin.
I'd love to see more hierarchy in Phobos too but we'd first need to
agree to package separation principles then.


Then that's what we need to do. I don't want any more top level modules. 
There are already too many.


--
/Jacob Carlborg

Re: Future of D on alternate platforms

2014-02-26 Thread Kai Nacke


On Friday, 21 February 2014 at 20:55:58 UTC, Frustrated wrote:

How difficult is it to port D code to future projects on
alternate platforms(mainly coming from win) and, if needed be, a
compiler for those platforms?

At this point, I'm wondering how difficult code I'm writing for
windows will be to port to, say, the iOS, mac, arm, and more
likely, embedded systems such as the tigerSharc, etc.

I've heard many times the LLVM compiler mentioned in the forums
and it seems to be able to compile D code to any platform the
compiler supports(but somehow independent of D... maybe it
compiles it to an intermediate language?).

My goal at this point is to use D on windows to create some
algorithmic software and then potentially port it to some
embedded system with minimal rewrite of the core code. e.g., I
don't want to have to rewrite the algorithms in C and use the
compiler tools for that system. If that was the case there is
little reason to use D in the first place.

Obviously there is no magic compiler that will do it all. I'm
curious though as to the possibility. In 2 years could one 
expect

D to be more widely used on other systems? I see people already
getting D started on ARM and iOS so it seems feasible that in 
the

near future it would be relatively easy to port the
code(obviously there are functional differences due to the OS 
but

I'm talking about the cpu issues at this point).


Hi Frustrated!

With LDC, you can potential target all platforms supported by 
LLVM. The big problem is the runtime support. Some of the modules 
are very low-level and you have to implement them for every 
platform (e.g. core.thread, the vararg interface or exception 
handling).
This is not always easy. On ARM, there is a bug in the exception 
handling code. PPC64 has good support (there are still bugs, 
too!) but PPC32 requires more work. I currently evaluate if I can 
add support for MIPS64, too.


LDC has still a cross-compiling issue with floating points but I 
already have a fix for this (which requires more testing before 
commit).


If the CPU of your device is already supported by the runtime, 
then you can reach your goal. At Phobos level, the biggest 
difference between devices is accuracy of real data type (may be 
different!).


BTW: Which is your target platform?

Regards,
Kai

Re: Practical Problems with distribution D projects

2014-02-26 Thread Assaf Gordon


On 02/26/2014 12:34 PM, Adam D. Ruppe wrote:

On Wednesday, 26 February 2014 at 17:08:38 UTC, Assaf Gordon wrote:

In my first message in this thread, I wrote (item #3), that unless I'm missing 
something, there is no way to build a statically linked binary with D on Linux.


They really aren't far from it out of the box:

$ dmd hellod.d
$ ldd hellod
 linux-gate.so.1 =>  (0xe000)
 libpthread.so.0 => /lib/libpthread.so.0 (0xf76db000)
 libm.so.6 => /lib/libm.so.6 (0xf76b5000)
 librt.so.1 => /lib/librt.so.1 (0xf76ac000)
 libc.so.6 => /lib/libc.so.6 (0xf7549000)
 /lib/ld-linux.so.2 (0xf773)


It isn't fully static, but those libraries are all pretty basic things and 
generally available on any linux install. The biggest problem is probably the 
libc version not matching on older installations.


This might seem "generally available" on linux, but it's not.
It might be "generally available" when you assume you're dealing with "recent" 
"desktop" versions of linux.
But it's not at all when dealing with servers (as Artem already mentioned 
before: 
http://forum.dlang.org/post/mailman.290.1393304990.6445.digitalmar...@puremagic.com
 ) .

As a quick example, try to download and run the pre-compiled binaries of "ldc2" 
from the dlang.org website on a Stable Debian - they will fail with incompatible libc 
versions.



One option might be to package those .so files right with your executable. A 
poor man's static link.



Now that's what I'd call "windows attitude" - package all dependencies together, in what 
I think was termed "DLL hell" :)

I think that low-level libraries (e.g. ld-linux, libc, linux-gate, librt, 
libpthread) are tightly coupled to the system (and the kernel), you really 
don't want to run incompatible ones on an arbitrary linux system.




Anyway, let's try the -static switch we can use to do statically linked libc on 
some programs.

$ dmd hellod.d -c
$ gcc hellod.o -o hellod -m32 -L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker 
--export-dynamic -l:libphobos2.a -lpthread -lm -lrt -static

undefined reference to `__tls_get_addr'


BTW if you run "dmd -v yourfile.d" the last line of output is the linker 
command line it runs (via gcc). Then you can copy/paste that and tweak the arguments. 
Here, I added -static.


However, that is *not* a D problem per se, that's a libc function. Maybe my 
system just doesn't have the right stuff installed to build a static threaded 
app.



I'd argue the opposite: it is a D problem (or libphobos2/druntime problem, 
which is a major part of D).

The missing symbol "__tls_get_addr" is referenced from the D function getTLSRange() in 
"druntime/src/rt/sections_linux.d".
And the way druntime uses it is apparently not compatible with static linking 
(I know very little about this low-level stuff).




I betcha if I sent you my binary from my slackware box over to your computer it 
would work even if you are a different distro.


You'd be surprised what kind of old versions of linuxes are out there.
I have tried it with C-based projects, and based on my humble experience, 
anything except a real static binary will eventually cause problems to users.

Re: http://www.rust-ci.org/


On 2014-02-26 05:50, Brad Roberts wrote:


The 'build' part of the auto-tester is the easiest part.  The majority
of the logic is in what to build when and the user interface on top of
that state.  None of that exists for this use case.  It's not hard
logic, but it would need to be built.

This use case can likely also ignore the multi-platform part and stick
to just building on one which simplifies the job significantly.  And it
can also likely all be done on one box since it's likely that it can all
be done in a relatively short period of time.

All that, in my mind, suggests that while it could be integrated into
the auto-tester, it gains little in doing so and puts more work on my
plate and more load on already loaded systems.  I think having a new
volunteer involved would be more long term beneficial.


How much worked would it be to rewrite the auto tester to not use the 
proprietary systems it currently does? I'm thinking this would make it 
easier for others to help.


--
/Jacob Carlborg

Re: Practical Problems with distribution D projects

On Wednesday, 26 February 2014 at 17:34:45 UTC, Adam D. Ruppe 
wrote:
Anyway, let's try the -static switch we can use to do 
statically linked libc on some programs.


$ dmd hellod.d -c
$ gcc hellod.o -o hellod -m32 
-L/home/me/d/dmd2/linux/bin32/../lib32 -Xlinker 
--export-dynamic -l:libphobos2.a -lpthread -lm -lrt -static


undefined reference to `__tls_get_addr'


Huh, I was sure this works. Unpleasant surprise.

Have filed a bug report : 
https://d.puremagic.com/issues/show_bug.cgi?id=12268


( I don't have time to properly answer holy war topics, probably 
later :) )

Re: vibe.d & exception performance

2014-02-26 Thread Marc Schütz


The results:

 A) vibe.d 0.7.17  B) vibe.d patched
1) no exceptions  13000 req/s  13000 req/s
2) dynamic exceptions   200 req/s800 req/s
3) static exceptions320 req/s  19000 req/s


New numbers with DMD/Druntime/Phobos git (includes the patch by 
Adam Ruppe):


 A) vibe.d 0.7.17  B) vibe.d patched
1) no exceptions  15000 req/s  16000 req/s
2) dynamic exceptions   120 req/s  19000 req/s
3) static exceptions120 req/s  19000 req/s

Dynamic and static exceptions are now equally fast, provided 
`toString()` is not called on them.

Re: Practical Problems with distribution D projects

On Wednesday, 26 February 2014 at 18:52:55 UTC, Assaf Gordon 
wrote:
It might be "generally available" when you assume you're 
dealing with "recent" "desktop" versions of linux.


I've had good luck with them on my servers too but I haven't used 
many of the distros.


But I have had the same libc version problems you see too.

I think that low-level libraries (e.g. ld-linux, libc, 
linux-gate, librt, libpthread) are tightly coupled to the 
system (and the kernel), you really don't want to run 
incompatible ones on an arbitrary linux system.


If this were true, static linking would be useless! Static 
linking is basically just copying the library functions into your 
binary instead of leaving a reference to the library.


I'd argue the opposite: it is a D problem (or 
libphobos2/druntime problem, which is a major part of D).


I'm not sure because searching the web for people having this 
problem with C++ suggests the fix is to update the libc on their 
development computer. So that might work with us too but then 
again if it breaks on your computer too who knows.


I have tried it with C-based projects, and based on my humble 
experience, anything except a real static binary will 
eventually cause problems to users.


I agree, this is why I prefer distributing Windows exes :) but if 
you know your target computers it might not be a big problem, 
just compile with a libc close enough to them.

Re: RFC: Units of measurement for D (Phobos?)

2014-02-26 Thread Nordlöw


Is somebody waiting for this to be reviewed?

/Per

Re: RFC: Units of measurement for D (Phobos?)

2014-02-26 Thread Kelet


Tangentially related: https://github.com/biozic/quantities

Re: Typed GC

2014-02-26 Thread Shammah Chancellor

On 2014-02-26 16:51:25 +, evansl said:

On 02/26/14 10:25, evansl wrote:

On 02/12/14 06:11, Shammah Chancellor wrote:

With all the talk of garbage collection. I was wondering if it would be
useful to make the GC typed. If it was typed, it maybe be possible to
make it more efficient via type information, (such as only scanning
reference fields). Also, it could have access to attribute information
if applicable.

-S.

Hi Shammah,

In an earlier thread, Andrei proposed:

I suspect that allocating and manipulating objects on the GC heap in
particular may have certain restrictions. One possibility to avoid
such restrictions is to have a function typify(T)(void* p) which
ascribes type T to heap location p.

which would be one way to at least record the type of each memory
location. However, later posts in that thread indicated there
were problems with where to store that information. I thought
you could store it in the heap along side the pointed to object;
however, that seemed to have problems, according to this post:

http://forum.dlang.org/thread/lao9fn$1d70$1...@digitalmars.com?page=12#post-jgommvkndygzcpxxotly:40forum.dlang.org

So, the idea seems good, but I'd guess implementation is problematic.
At least that's what I guess from the referenced posts.

-regards,
Larry

OOPS. Just read Benjamin's post:

http://forum.dlang.org/post/ldhquc$11ec$1...@digitalmars.com

and then the druntime code:

https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/object_.d#L2629

which contains:

immutable(void)* m_RTInfo; // data for precise GC

override @property immutable(void)* rtInfo() const
{ return m_RTInfo; }

So, I guess m_RTInfo contains information from which the pointers
within the object can be precisely found.

Sorry for noise :(

-Larry

No problem, thanks for the reply. However, I was suggesting that new
be given type info at compile time in order to add some optimization to
the GC there.

-SC

Re: RFC: Units of measurement for D (Phobos?)

2014-02-26 Thread Nordlöw


On Wednesday, 26 February 2014 at 21:41:57 UTC, Kelet wrote:

Tangentially related: https://github.com/biozic/quantities


Impressive!

This seems similar to David Nadlingers std.units and std.si.

When will all these efforts on implementing Units/SI be 
synchronized and reviewed?


One question:

I know what angles are but I have never seen them defined like 
this before!


enum radian = meter / meter; // ditto
enum steradian = square(meter) / square(meter); /// ditto

What on earth does this mean?

/Per

Minor std.stdio.File.ByLine rant

I'm writing a CLI program that uses File.ByLine to read input commands,
with optional prompting (if run in interactive mode). One would imagine
that this should be a natural use for ByLine (perhaps not as common
nowadays with the rampant GUI fanboyism, but it still happens in some
niches), but it is fraught with peril.

First of all, the way ByLine works is kinda tricky, even in the previous
releases. The underlying cause is that at least on Posix, the underlying
C feof() call doesn't actually tell you whether you're really at EOF
until you try to read something from the file descriptor. I know there
are good reasons for this, but this special percolates up the standard
library code and causes a problem with D's input range primitives, where
.empty must tell the caller, right now, whether data is available,
*before* .front ever returns anything.

At one time, this problem was worked around by issuing a single fgetc on
the underlying file descriptor in ByLine's .empty method to determine
its EOF state, and then doing a fungetc to put the char back into the
stream.  However, this code is a rather ugly hack, and causes the
problem that when the interactive program needs to output a prompt
before blocking on input, it has to do so *before* it calls ByLine.empty
(since otherwise .empty blocks and the prompt doesn't get printed until
after the user has hit Enter -- clearly unacceptable for an interactive
shell program). If the stream turns out empty after all, then the prompt
is already output, and there's no way to take it back, so an extraneous
prompt is always written.

Understandably, the fungetc hack was subsequently removed from Phobos,
by caching the subsequent line the first time .empty was called, which
eliminated the ugliness of fungetc, and allowed current code to continue
working as before.

Then recently, and also understandably, caching things in .empty was
frowned upon, so the caching was removed from .empty altogether and
pushed into the ByLine ctor. From the standpoint of Phobos code, this is
perhaps the ideal solution: the ctor reads the stream to get the first
line and simultaneously determine the EOF status of the stream, and
there is no need for ugly boolean state flags, fungetc ugliness, and
generally unpleasant code.

However, what happens is that now, ByLine will block on input *upon
construction*. This is rather unpleasant when your program needs to do
something like this:

void main() {
string prompt;
...
ByLine!char input;
if (useStandardInput) {
input = stdin.byLine();
} else if (useScriptFile) {
input = File(filename).byLine();
}
...
if (mode == ProgramMode.modeA) { // mode is an enum
runModeA(input);
} else {
runModeB(input);
}
}

void runModeA(ByLine!char input) {
write("modeA> ");   // display prompt
while (!input.empty) {
...
}
}

void runModeB(ByLine!char input) {
write("modeB> ");   // display prompt
while (!input.empty) {
...
}
}

The problem is, when input is initialized, we don't know what prompt to
use yet, but ByLine's ctor will already block when it tries to read from
stdin!

The current workaround I implemented is to use a wrapper around ByLine
that lazily constructs it when .empty is called.

Who knew something so simple as an interactive prompting program that
reads input lines could turn into such a nightmare when ByLine is used?

:-(


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

Re: Minor std.stdio.File.ByLine rant

2014-02-26 Thread bearophile


H. S. Teoh:

I'm writing a CLI program that uses File.ByLine to read input 
commands,


Isn't using readln() better for that? File.byLine is to read 
lines of files on disk.


Bye,
bearophile

Re: Minor std.stdio.File.ByLine rant

2014-02-26 Thread Jakob Ovrum


On Wednesday, 26 February 2014 at 23:45:48 UTC, H. S. Teoh wrote:
The problem is, when input is initialized, we don't know what 
prompt to
use yet, but ByLine's ctor will already block when it tries to 
read from

stdin!


Ouch, I think I saw this coming... [1]

[1] https://github.com/D-Programming-Language/phobos/pull/1883

Re: Minor std.stdio.File.ByLine rant

2014-02-26 Thread Jakob Ovrum


On Wednesday, 26 February 2014 at 23:59:09 UTC, bearophile wrote:

H. S. Teoh:

I'm writing a CLI program that uses File.ByLine to read input 
commands,


Isn't using readln() better for that? File.byLine is to read 
lines of files on disk.


Bye,
bearophile


Says who? The type system and documentation only assert that it 
works on files, with no reservations about what kind of file. The 
standard input file is as fine a file as any.

Re: Manual Memory Management Example for dlang.org Docs (Code Review)

2014-02-26 Thread Mike


On Wednesday, 26 February 2014 at 15:00:13 UTC, Dicebot wrote:

On Wednesday, 26 February 2014 at 04:43:30 UTC, Mike wrote:
Please review this (http://dpaste.dzfl.pl/2377217c7870) 
instead.



throw new Exception("Out of memory");


I don't think it is a good thing to do. Of course GC is likely 
to have some memory left in hs internal pools but in general 
once you hit out-of-memory state last thing you want is not 
allocate even more.



// Deallocate test
heapDeallocate(test);


More idiomatic D is to put `scope(exit) heapDeallocate(test);` 
immediately after allocation line.


Thanks,

I've made changes and I guess this is the one I'll use for the 
pull.

(http://dpaste.dzfl.pl/31367860c005)

Re: Minor std.stdio.File.ByLine rant

On Wed, Feb 26, 2014 at 11:59:07PM +, bearophile wrote:
> H. S. Teoh:
> 
> >I'm writing a CLI program that uses File.ByLine to read input
> >commands,
> 
> Isn't using readln() better for that? File.byLine is to read lines
> of files on disk.
[...]

Perhaps, but readln() isn't a range. The whole point was to use a
range-based API for the interpreter so that there's no need to write two
separate interfaces for the interpreter, one for stdin, one for a script
file stored on disk.

T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.

Re: Minor std.stdio.File.ByLine rant

2014-02-26 Thread Jakob Ovrum

On Thursday, 27 February 2014 at 00:07:47 UTC, H. S. Teoh wrote:

On Wed, Feb 26, 2014 at 11:59:07PM +, bearophile wrote:

H. S. Teoh:

>I'm writing a CLI program that uses File.ByLine to read input
>commands,

Isn't using readln() better for that? File.byLine is to read 
lines

of files on disk.

[...]

Perhaps, but readln() isn't a range. The whole point was to use 
a
range-based API for the interpreter so that there's no need to 
write two
separate interfaces for the interpreter, one for stdin, one for 
a script

file stored on disk.

T

Just write a function that accepts a std.stdio.File parameter?

Re: Minor std.stdio.File.ByLine rant

On Thu, Feb 27, 2014 at 12:16:21AM +, Jakob Ovrum wrote:
> On Thursday, 27 February 2014 at 00:07:47 UTC, H. S. Teoh wrote:
> >On Wed, Feb 26, 2014 at 11:59:07PM +, bearophile wrote:
> >>H. S. Teoh:
> >>
> >>>I'm writing a CLI program that uses File.ByLine to read input
> >>>commands,
> >>
> >>Isn't using readln() better for that? File.byLine is to read lines
> >>of files on disk.
> >[...]
> >
> >Perhaps, but readln() isn't a range. The whole point was to use a
> >range-based API for the interpreter so that there's no need to write
> >two separate interfaces for the interpreter, one for stdin, one for a
> >script file stored on disk.
> >
> >
> >T
> 
> Just write a function that accepts a std.stdio.File parameter?

Unfortunately, I use string arrays in my unittests (to avoid having to
create separate unittest input files). So passing in File wouldn't work.
Besides, File isn't a range, so that kinda defeats the purpose (my
current hack of lazily constructing ByLine does work). I just find it
unfortunate that such hacks are necessary to get off the ground.


T

-- 
It won't be covered in the book. The source code has to be useful for 
something, after all. -- Larry Wall

Re: TypeInfo in the library

2014-02-26 Thread Mike


On Friday, 14 February 2014 at 00:42:08 UTC, Adam D. Ruppe wrote:
I'd like to see typeinfo moved completely to the library. The 
language would then not depend on it directly. The point of 
this thread is to see how practical it is. Here's the changes I 
have in mind:


1) Stop automatic generation of TypeInfo.

2) typeid(T) in the language now returns a static instance of 
TypeInfoImpl!T. The vtbl entry in a class also points to this. 
If the library doesn't implement TypeInfoImpl(T), these return 
null.


3) Add __traits(classInitializer, Class) which returns what we 
have today through typeid(Class).init. (This would be used to 
make init in the library implementation)



I think the others are already possible:

string TypeInfoImpl!T.toString() { return T.stringof; }
interface TypeInfo {} /* TypeInfoImpl(T) : TypeInfo */

// ElementType used for illustration only, no need to depend on 
phobos since we can do this with an is expression too. that's 
just harder to read/write lol


TypeInfo TypeInfoImpl!T.next() { return typeid(ElementType!T); }

Interfaces and parent class can also be done with traits today, 
so we can auto-generate the with a template too.



And so on, look at druntime's typeinfos now, most of it is just 
doing a bunch of casts of the same code - easily templated.




If I'm not missing anything, these three changes would let us 
completely define (or not define) type info in the library 
without breaking anything we have now!



Functions that depend on typeinfo can be generated the same way 
as they are now, though of course, I'd also enjoy moving more 
of those things (arrays, etc.) to be templates too :)


Added enhancement bugzilla because it's a great idea: 
https://d.puremagic.com/issues/show_bug.cgi?id=12270

Re: RFC: Units of measurement for D (Phobos?)

2014-02-26 Thread Michael


enum radian = meter / meter; // ditto
enum steradian = square(meter) / square(meter); /// ditto

What on earth does this mean?


It has to do with the definition of radian itself. If you draw a 
circle (of any radius) around an angle. The measure of the angle 
is radian is the ratio between the arc length of the circle and 
the radius. This is the reason why one full rotation is 2*pi 
radians: A circle's circumference is always 2*pi times its radius.


Steradian is similar, but in three dimensions.

Re: http://www.rust-ci.org/

2014-02-26 Thread Piotr Szturmaj


On 2014-02-26 05:50, Brad Roberts wrote:

Later,
Brad


Hi, It's kinda hard to reach you by email, I've sent 3 of them :) Would 
you like to accept ARM board for auto tester? Please contact me on NG 
email if you wish.

better error messages on isInputRange, etc.

When isInputRange fails, it doesn't tell us why. Did you not add 
empty? Or misspell popFront? It just tells you it isn't a range.


I'm thinking a better way might be to write the check like this:

// compile a regular function so we get full error from the 
compiler...

bool checkInputRange(T)() {
if(!__ctfe) { // don't want to *actually* run it
T t = void;
if(t.empty) {}
t.popFront();
auto f = t.front;
}
return true;
}

// and isInputRange is basically the same as today, but the
// helper function isn't anonymous
template isInputRange(T) {
enum isInputRange = is(typeof(checkInputRange!T));
}



Consider this:

struct Test {
int[] s;
bool eampty() { return s.length == 0; }
int front() { return s[0]; }
void popFront() { s = s[1 .. $]; }
}
static assert(isInputRange!Test);

cte.d(33): Error: static assert  (isInputRange!(Test)) is false


We know it failed, but we don't know why. Change the assert to 
this:


static assert(checkInputRange!Test);

And we get a more helpful error:
cte.d(4): Error: no property 'empty' for type 'Test', did you 
mean 'eampty'?



Still not perfect, it points to the helper function line, but at 
least the "no property 'empty' for type 'Test'" is a lot more 
specific.


Fix the typo and it all works.



Any better ideas? I just sometimes get frustrated, especially 
with more complex ranges, when the duck type doesn't work and it 
is hard to find why. This is one idea.


On a similar vein, template constraints can lead to some ugly 
messages. Why didn't it match any of them? But I think this has 
to be a compiler change and might spam all kinds of nonsense, 
whereas tweaking isInputRange etc. is a fairly conservative 
change that I think will help a lot too.

Re: better error messages on isInputRange, etc.