[your code here]

[Lionello Lunesu via Digitalmars-d]

Thought this code ended up really concise and readable:

https://gist.github.com/lionello/60cd2f1524c664d4d8454c01a05ac2c8

Suitable for dlang.org?

L.

Re: Need a Faster Compressor

[Lionello Lunesu via Digitalmars-d]

On 22/5/2016 05:51, Stefan Koch wrote:

On Saturday, 21 May 2016 at 21:12:15 UTC, Walter Bright wrote:

The current one is effective, but slow:

https://github.com/dlang/dmd/blob/master/src/backend/compress.c

Anyone want to make a stab at making it faster? Changing the format is
fair game, as well as down and dirty assembler if that's what it takes.

So really, how good are you at fast code?


Is LZ4 acceptable ?
If so the current C implementation is hard to beat.
And maybe it's best to just copy it in.


Agree. I've had the best results with LZ4. We can either link to the C 
code, or port it to D. It's very trivial.


L.

Re: Killing the comma operator

[Lionello Lunesu via Digitalmars-d]

On 13/5/2016 20:44, Nick Treleaven wrote:

On Thursday, 12 May 2016 at 02:51:33 UTC, Lionello Lunesu wrote:

I'm trying to think of a case where changing a single value into a
tuple with 2 (or more) values would silently change the behavior, but
I can't think of any. Seems to me it would always cause an error, iff
the result of the comma operator gets used.


int x,y;
auto f() {return (x=4,y);}
...
auto z = f();
static if (!is(typeof(z) == int)
   voteForTrump();

;-)

In practice, this is more plausible with function overloading - i.e.
z.overload() calling a different function. If the comma operator returns
void, the `auto z` line and f().overload() both fail.


Good point. Thanks.

Re: CRLF in wysiwyg string literals?

[Lionello Lunesu via Digitalmars-d]

On 12/5/2016 16:38, Kagamin wrote:

For HTTP you can't use anything but escape sequences. AFAIK, they apply
only to protocol headers, the content can be anything.


Not just HTTP, MIME multipart/mixed content also requires CRLF, as does 
application/http content.

Re: Killing the comma operator

[Lionello Lunesu via Digitalmars-d]

On 11/5/2016 21:13, deadalnix wrote:

On Wednesday, 11 May 2016 at 10:50:47 UTC, Lionello Lunesu wrote:

On 10/5/2016 22:16, deadalnix wrote:

On Tuesday, 10 May 2016 at 10:09:40 UTC, Andrei Alexandrescu wrote:

On 5/10/16 12:52 PM, Mathias Lang wrote:

So, following DConf2016, I raised a P.R. to deprecate usage of the
comma
expressions, except within `for` loops increment [5].


The agreed-upon ideea was to allow uses that don't use the result
(including for loops). No? -- Andrei


Let's just make it of void type, there was plan to recycle the syntax
maybe, but whatever we do in the future, this is the sensible first
step.


Acutally, we can do two-birds-one-stone: instead of making it void,
make it a value tuple!



No. You can't change semantic to something that'll still work under the
feet of the user. If this syntax is to be recycled to tuple, the value
needs to be void for a while as to shake out uses.

It is safe to go from void to something else, it isn't not to go from
something to something else.



I agree with you when the 1st something and 2nd something are somehow 
compatible. void is also a something, but it'd work because it'd never 
silently change the meaning of code.


I'm trying to think of a case where changing a single value into a tuple 
with 2 (or more) values would silently change the behavior, but I can't 
think of any. Seems to me it would always cause an error, iff the result 
of the comma operator gets used.

CRLF in wysiwyg string literals?

[Lionello Lunesu via Digitalmars-d]

Writing a lot of server side D code lately, and bummed the usual `string 
literals` (or r"string literals") will only use '\n' as the End of line 
character, while HTTP (and others too) use CRLF for EOL.


One way is to create a CTFE function that replaces all \n with \r\n, and 
call this on all string literals.


Another idea I just had was to reserve the rn prefix for such strings, 
ie. rn"This string

uses CRLF new lines."

The rn prefix would reflect the usual \r\n CRLF pairs. (Perhaps 
confusing, since the r doesn't actual mean CR, and there's no n prefix 
either.)


Just a thought. How have others solved this? Short of using \r\n\r\n, 
that is.


L.

Re: Killing the comma operator

[Lionello Lunesu via Digitalmars-d]

On 10/5/2016 22:16, deadalnix wrote:

On Tuesday, 10 May 2016 at 10:09:40 UTC, Andrei Alexandrescu wrote:

On 5/10/16 12:52 PM, Mathias Lang wrote:

So, following DConf2016, I raised a P.R. to deprecate usage of the comma
expressions, except within `for` loops increment [5].


The agreed-upon ideea was to allow uses that don't use the result
(including for loops). No? -- Andrei


Let's just make it of void type, there was plan to recycle the syntax
maybe, but whatever we do in the future, this is the sensible first step.


Acutally, we can do two-birds-one-stone: instead of making it void, make 
it a value tuple!


If the result of the comma operator gets used in a bug prone matter it 
would cause a compile error! How is that for "Yeah, sorry, we broke your 
code, but look what you got in return!"


Win-win!

Re: dmd not building with dmd

[Lionello Lunesu via Digitalmars-d]

On 10/5/2016 14:39, Jacob Carlborg wrote:

On 2016-05-10 06:49, Lionello Lunesu wrote:


Well, it's either wrong phobos or wrong dmd. I assumed phobos was
mismatched, but perhaps DMD was mismatched? Installing with brew suggest
it's installing 2.071.0, but DMD appears to be 2.070:


The issue Steven is having is that the symbol doesn't exist in the
default C++ runtime. This has been fixed in master. He installed DMD
using DVM so it's not a Brew packaging problem.

Rolling back to 2.70.0 can be used as a workaround.



Yeah, I see now. I thought it was because of the version "mismatch". 
Didn't know it was an actual bug. I had build my own and it worked. I 
guess I had gotten the fix.


Thanks for correcting me.

Re: dmd not building with dmd

[Lionello Lunesu via Digitalmars-d]

On 10/5/2016 16:24, John Colvin wrote:

On Tuesday, 10 May 2016 at 04:49:33 UTC, Lionello Lunesu wrote:

Well, it's either wrong phobos or wrong dmd. I assumed phobos was
mismatched, but perhaps DMD was mismatched? Installing with brew
suggest it's installing 2.071.0, but DMD appears to be 2.070:

$ brew install dmd
==> Downloading
https://homebrew.bintray.com/bottles/dmd-2.071.0.el_capitan.bottle.tar.gz
Already downloaded:
/Library/Caches/Homebrew/dmd-2.071.0.el_capitan.bottle.tar.gz
==> Pouring dmd-2.071.0.el_capitan.bottle.tar.gz
🍺  /usr/local/Cellar/dmd/2.071.0: 561 files, 65.0M

$ /usr/local/bin/dmd --version
DMD64 D Compiler v2.070
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright


That's because for some reason the VERSION file is wrong in the dmd
github release.

Should be fixed by https://github.com/Homebrew/homebrew-core/pull/1040


Ah, I see. Thanks!

Re: dmd not building with dmd

[Lionello Lunesu via Digitalmars-d]

On 9/5/2016 20:19, John Colvin wrote:

On Monday, 9 May 2016 at 07:57:33 UTC, Lionello Lunesu wrote:

On 8/5/2016 14:43, Steven Schveighoffer wrote:

[...]


I ran into this as well. It's a bug in the package from brew: it
shipped with the wrong phobos. You can build your own DMD:

$ make -f posix.mak AUTO_BOOTSTRAP=1


In what way do you mean "shipped with the wrong phobos"?


Well, it's either wrong phobos or wrong dmd. I assumed phobos was 
mismatched, but perhaps DMD was mismatched? Installing with brew suggest 
it's installing 2.071.0, but DMD appears to be 2.070:


$ brew install dmd
==> Downloading 
https://homebrew.bintray.com/bottles/dmd-2.071.0.el_capitan.bottle.tar.gz
Already downloaded: 
/Library/Caches/Homebrew/dmd-2.071.0.el_capitan.bottle.tar.gz

==> Pouring dmd-2.071.0.el_capitan.bottle.tar.gz
🍺  /usr/local/Cellar/dmd/2.071.0: 561 files, 65.0M

$ /usr/local/bin/dmd --version
DMD64 D Compiler v2.070
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

Re: Compiler benchmarks for an alternative to std.uni.asLowerCase.

[Lionello Lunesu via Digitalmars-d]

On 9/5/2016 12:01, Jon D wrote:

On Monday, 9 May 2016 at 00:15:03 UTC, Peter Häggman wrote:

On Sunday, 8 May 2016 at 23:38:31 UTC, Jon D wrote:

I did a performance study on speeding up case conversion in
std.uni.asLowerCase. Specifics for asLowerCase have been added to
issue https://issues.dlang.org/show_bug.cgi?id=11229. Publishing here
as some of the more general observations may be of wider interest.

[...]


Nice, it seems that you would have enough material to advocate a pull
request in phobos then ;)


Thanks! I haven't yet taken the time to go through the 'becoming a
contributor' steps, when I have the time I'll do that. In this case, I'd
want to start by validating with the library designers that the approach
makes sense. It by-passes what appears to a basic primitive,
std.uni.toCaser. There may be reasons this is not desirable.


Less code, and faster, and using existing building blocks. Win, win, 
win, if you ask me!


+1

Re: dmd not building with dmd

[Lionello Lunesu via Digitalmars-d]

On 8/5/2016 14:43, Steven Schveighoffer wrote:

I went to create a PR, and did a git pull on all my repositories. After
make clean on OSX, dmd would not build:

/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src -f posix.mak
no cpu specified, assuming X86
CC=c++ dmd idgen.d
Undefined symbols for architecture x86_64:
   "__Unwind_GetIPInfo", referenced from:
   ___dmd_personality_v0 in libphobos2.a(dwarfeh_5c8_811.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

I had to revert to dmd 2.070 as the build tool to get it to build.

My question is: is this expected behavior, or should I file a bug?

-Steve


I ran into this as well. It's a bug in the package from brew: it shipped 
with the wrong phobos. You can build your own DMD:


$ make -f posix.mak AUTO_BOOTSTRAP=1

For the Weka guys: this fixes your casts

[Lionello Lunesu via Digitalmars-d]

I just saw Shachar's lightning talk and wanted to point them to this 
feature that I had done for enhancing Value Range Propagation.


By adding "const" to the index variable, the compiler will actually 
enforce the value-range for a foreach iterator. But, this still requires 
the range to known, so only works for static arrays:



void main() {
  immutable ubyte PARITIES_START = 10;
  ubyte[4] parities = [1, 2, 4, 5];

  foreach(const ubyte i, ref parity; parities) {
ubyte diskId = PARITIES_START + i;   // look ma, no cast
  }

}


This has been in D for over year now. Try it.

L.

Re: How are you enjoying DConf? And where to go next?

[Lionello Lunesu via Digitalmars-d]

On 6/5/2016 22:13, Andrei Alexandrescu wrote:

The atmosphere here is great, and I'm curious how it feels for those who
are watching remotely. Is the experience good? What can we do better?

Also: we're talking about the DConf 2017 location. Please share any
initial thoughts!


Thanks,

Andrei


I enjoyed watching remotely, some live, some from the archives. Live 
stream had some hickups, so when I started hampering I'd go do something 
else and rewatch the talk on the archive.


As for location: I attended CodeConf Hong Kong last November, hosted at 
Hong Kong University of Science and Technology. It was a great venue and 
they're very open to hosting similar events! Show Asia some love! I'll 
chase down the responsible people.


L.

Re: The end of curl (in phobos)

[Lionello Lunesu via Digitalmars-d]

On 6/5/2016 20:17, qznc wrote:

On Friday, 6 May 2016 at 09:21:43 UTC, Andrei Alexandrescu wrote:

On 5/6/16 10:32 AM, Robert burner Schadek wrote:

As discussed yesterday at DConf, curl in phobos must go.

The plan is as follows.

1. undocument everything curl related in may 2016
2. deprecate everything curl related in may 2017
3. delete everything curl related in may 2018
3.1 move curl stuff to undead

PR: https://github.com/dlang/phobos/pull/4283


0. Write curl replacement


Could we simply move it into a dub package? Or does that clash symbols
or anything somehow?


Just tried this, works fine! Try it yourself:

$ sed -i '' 's/curl //' phobos/posix.mak
$ make -C phobos -f posix.mak clean
$ make -C phobos -f posix.mak

$ dub init undead-curl
$ echo 'targetType "sourceLibrary"' >> undead-curl/dub.sdl
$ mkdir -p undead-curl/source/etc/c undead-curl/source/std/net/
$ mv phobos/etc/c/curl.d undead-curl/source/etc/c/
$ mv phobos/std/net/curl.d undead-curl/source/std/net/
$ dub add-local undead-curl

Tested with an app I had made not long ago (guess what it does!)

$ cd sciamspider
$ echo 'dependency "undead-curl" version="~master"' >> dub.sdl
$ dub

Ran without any changes!

Re: Implement the "unum" representation in D ?

[Lionello Lunesu via Digitalmars-d]

On 17/11/15 07:52, Nick_B wrote:

On Sunday, 15 November 2015 at 04:19:21 UTC, Lionello Lunesu wrote:

On 09/11/15 04:38, Richard Davies wrote:

Yeah, I got curious too. I spend some time on it yesterday and had a
stab at writing it in D.


Hi. I send a email to John Gustafson yesterday, re this thread.

He replied as follows:

"There are efforts underway worldwide to support unums in C, Python,
Julia, Java, and now D. And the book has only been out for nine months!"

Nick


Ha, and I think we can do a better job than the others! Surely in terms 
of performance!


Funny, I was indeed looking at the Julia and Python (and John's 
Matematica code) to learn how some of the operations on Unums work.


Still a lot to do though. I've basically only declared the type, still 
needs all the calculations.


L.

Re: Persistent list

[Lionello Lunesu via Digitalmars-d]

On 16/11/15 22:45, Andrei Alexandrescu wrote:

On 11/16/2015 08:51 AM, Marc Schütz wrote:

On Monday, 16 November 2015 at 02:26:29 UTC, Andrei Alexandrescu wrote:

Yah, I agree with that argument. Probably @mutable is a more
principled way to go about things.


Glad to here that. I think the current transitive const system is really
good and shouldn't be watered down beyond necessity. And a @mutable
keyword, too, shouldn't just mean "immutability or const-ness end here",
thus allowing any kind of mutation. What we actually need for
immutable/const refcounting etc. is _non-observable mutation_, i.e.
physical mutability, but without observable effects outside of the
type's implementation (better yet, restricted to very short parts of it,
just like @trusted).


The challenge is proving that a mutation is not observable. Got an
attack on that? -- Andrei


Forgive me, I haven't followed the RC discussions closely, so I miss a 
lot of context. Feel free to point me to existing threads/articles.


If it's RC we want, then @mutable is an axe when what we need is a scalpel.

The non-observability comes from the fact the refcount is changed when 
the caller has lost its (const) reference and constness is a moot point. 
Changing refcount is fine now, provided the object is not immutable. As 
far as other outstanding const references go, these already expect 
changes to happen.


This is what makes refcount special and provably safe to mutate. As long 
as we can ensure the object is not immutable, the object is allowed to 
change its own refcount. But refcount needs to be special cased, 
somehow, or else we'll end up with some C++ like `mutable`.


Perhaps const-but-not-pure is the solution here. The object must be able 
to store (and have stored) a mutable reference, so it can use that 
reference to change the refcount. (This could be optimized to be a flag, 
since the mutable and const reference would refer to the same instance.) 
It means keeping track of const-but-mutable vs const-and-immutable 
references, and somehow telling the compiler that refcount is special.


L.

Re: Bitfield bug

[Lionello Lunesu via Digitalmars-d]

On 16/11/15 18:05, deadalnix wrote:

https://issues.dlang.org/show_bug.cgi?id=15305

Any taker ? I don't think this is that hard to fix, and this is really bad.


https://github.com/D-Programming-Language/phobos/pull/3815

Re: Implement the "unum" representation in D ?

[Lionello Lunesu via Digitalmars-d]

On 09/11/15 04:38, Richard Davies wrote:

On Friday, 18 September 2015 at 03:19:26 UTC, Nick B wrote:

On Thursday, 17 September 2015 at 23:53:30 UTC, Anthony Di Franco wrote:



I read the whole book and did not regret it at all, but I was already
looking for good interval arithmetic implementations. I found that
the techniques are not too different (though improved in important
ways) from what is mainstream in verified computing.




Hi,

I haven't finished the book but have read over half of it and browsed
the rest. I wanted to add that an implementation of unums would have
advantages beyond verifiable computing. Some examples that spring to
mind are:

Using low precision (8-bit) unums to determine if an answer exists
before using a higher precision representation to do the calculation
(example briefly discussed in the book is ray tracing).

More generally, unums can self-tune their precision which may be
generally useful in getting high precision answers efficiently.

It is possible for the programmer to specify the level of accuracy so
that unums don't waste time calculating bits that have no meaning.

Parallelisation - floating point ops are not associative but unum ops are.

Tighter bounds on results than interval arithmetic or significance
arithmetic.

These are just a few areas where a software implementation could be
useful. If you've ever had any issues with floating point, I'd recommend
reading the book, not just because of the approach it proposes to solve
these but also because it's very clearly written and quite entertaining
(given the subject matter).

Richard


Yeah, I got curious too. I spend some time on it yesterday and had a 
stab at writing it in D. I was playing with the idea of using native 
floating point types to store Unums. This would not have the full 
benefit of the dynamically sized Unums, but would allow for the accuracy 
benefits.


Still need to implement the basic arithmetic (interval) stuff:
https://github.com/lionello/unumd

L.

Re: Possible issue with isInputRange

[Lionello Lunesu via Digitalmars-d]

On 24/09/15 07:10, Maor Ben Dayan wrote:

 static assert(is(typeof((inout int = 0) { R r = R.init; h =
r.front; })));  /* B fails */


What is `h`?

Re: Scoped in a foreach loop.

[Lionello Lunesu via Digitalmars-d]

On 05/06/15 05:07, Yuxuan Shui wrote:

I tried something like this:

foreach(e; scoped!SomeRangeType(args)) {
}

And my program segment faults. But this works:

{
 auto x = scoped!SomeRangeType(args);
 foreach(e; x) {
 }
}

Shouldn't the range be alive until the end of the loop?



Looks like a bug. I can repro it as well.

Filed as https://issues.dlang.org/show_bug.cgi?id=14653

L.

Re: [dconf] Share a ride SLC-hotel?

[Lionello Lunesu via Digitalmars-d]

On 25/05/15 10:39, Andrei Alexandrescu wrote:

I'm arriving in SLC on Tue at 11:39 pm. Anyone up for sharing a ride?
I'm thinking http://www.expressshuttleutah.com/. -- Andrei


I took the Green TRAX (light rail) from airport to downtown for $2.50.

From there you can apparently take the train or "front runner" down to 
Orem Central Station, but I haven't checked those details yet.


I plan to do some sightseeing downtown before heading South tonight.

L.

Re: Make const, immutable, inout, and shared illegal as function attributes on the left-hand side of a function

[Lionello Lunesu via Digitalmars-d]

On 09/10/14 17:32, francesco cattoglio wrote:

On Thursday, 9 October 2014 at 08:50:52 UTC, Martin Nowak wrote:

Kenji just proposed a slightly controversial pull request so I want to
reach out for more people to discuss it's tradeoffs.
It's about deprecating function qualifiers on the left hand side of a
function.

I'm all for it


Then at some future point we could apply the left hand side qualifiers
to the return type, e.g. `const int foo();` == `const(int) foo();`

I know it's not happening anytime soon, but I'm against this second
idea. This will be an extra annoyance when "porting" old D code to a new
version. Just removing the currently ambiguous attribute on the left
should be plenty. No need to try to mimic C in this regard.


+1

Re: C++ interop - class vs struct

[Lionello Lunesu via Digitalmars-d]

On 11/09/14 14:32, Daniel Murphy wrote:

pragma(cpp_mangle_as_struct)
class Foo
{
}


and/or?

pragma(cpp_mangle_as_class)
struct Bar
{
}

Re: Worrying attitudes to the branding of the D language

[Lionello Lunesu via Digitalmars-d]

On 03/07/14 02:08, Gary Willoughby wrote:

Here is one of my all time favourite talks from Steve Yegge (Senior
Engineer at Google) at OSCON 2007 entitled "How to Ignore Marketing and
Become Irrelevant in Two Easy Steps".

This is sage advice:

http://tvuol.uol.com.br/video/oscon--how-to-ignore-marketing--0402D0C90386/


Great share. Thanks.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

Latest [1] now also supports CTFE:

const i = foo ? -1 : 33;

if (i)
  static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
  static assert(i == 0); // Works now!
  static assert(__traits(intrange, i) == Tuple!(0, 0));
}

if (i == 33)
{
  static assert(i == 33); // Works now!
  static assert(__traits(intrange, i) == Tuple!(33, 33));
}
else
  static assert(__traits(intrange, i) == Tuple!(-1, 32));


Next up: support for immutable/const members and "if (i) static assert(i)"

L.

[1] https://github.com/lionello/dmd/tree/if-else-range

Re: Few recent dmd pull requests

[Lionello Lunesu via Digitalmars-d]

On 30/06/14 15:27, bearophile wrote:

Lionello Lunesu:


I've closed the "valueRange" PR because I now think it's not a good
idea, since the values it returns are not stable and any code using it
can break in the future as VRP gets smarter. The obvious cases
("valueRange of ubyte returning 0 and 255 resp.") can already be
tested by using implicit integer casts, as @yebblies has mentioned in
that PR.


OK. But the other idea (value range for if/then, and for pre/post
conditions) is still useful.

Bye,
bearophile


I'm actively developing that in my if-else-range branch. It's also part 
of the PR for issue 259, 
https://github.com/D-Programming-Language/dmd/pull/1913


It needs to get smarter still if I expect Walter to accept my fix to 
issue 259.


L.

Re: Few recent dmd pull requests

[Lionello Lunesu via Digitalmars-d]

On 26/06/14 18:38, bearophile wrote:



https://github.com/D-Programming-Language/dmd/pull/3679

This introduces __traits(valueRange, expr), and I think it introduces
range values to the ?: expressions too.

The __traits(valueRange, expr) is meant to be useful for debugging range
values, that is meant to be improved in future. Currently this patch
seems stalled because Lionello seems to not provide few small things
Walter has asked.




I feel I did address his points, but more importantly there was not much 
feedback (from anyone) whether this is desirable in the first place. As 
others have noted, success rate of PRs is not that high, so it's 
defensible that the "boilerplate" tasks (such as updating the 
documentation) are left until last.


I've closed the "valueRange" PR because I now think it's not a good 
idea, since the values it returns are not stable and any code using it 
can break in the future as VRP gets smarter. The obvious cases 
("valueRange of ubyte returning 0 and 255 resp.") can already be tested 
by using implicit integer casts, as @yebblies has mentioned in that PR.


L.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 23/06/14 04:51, "Nordlöw" wrote:

That will only work now if you use an "else".


So you mean something like

  if(xbyte.max)
  throw new InvalidArgumentException("...
  else {}

?

That seems like a strange restriction. Why is that?


I meant, else return x;

Because it's easy to see what the value of x is within the if and else 
body. It's not trivial to find out that the if body never exits (because 
of the throw) and therefor the code after the if is in essence the else 
body.


L.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 20/06/14 15:53, Don wrote:

On Wednesday, 18 June 2014 at 06:40:21 UTC, Lionello Lunesu wrote:

Hi,



https://github.com/lionello/dmd/compare/if-else-range

There, I've also added a __traits(intrange, ) which
returns a tuple with the min and max for the given expression.



Destroy?


The compiler uses value range propagation in this {min, max} form, but I
think that's an implementation detail. It's well suited for arithmetic
operations, but less suitable for logical operations. For example, this
code can't overflow, but {min, max} range propagation thinks it can.

ubyte foo ( uint a) {
   return (a & 0x8081) & 0x0FFF;
}

For these types of expressions, {known_one_bits, known_zero_bits} works
better.
Now, you can track both types of range propagation simultaneously, and I
think we probably should improve our implementation in that way. It
would improve the accuracy in many cases.

Question: If we had implemented that already, would you still want the
interface you're proposing here?



You could have different __traits in that case:
__traits(valueRange,...) // for min/max
__traits(bitRange,...) // mask

You example seems rather artificial though. IRL you'd get a compiler 
warning/error and could fix it by changing the code to "& 0xFF". I 
personally have not yet had the need for these bit-masks.


L.

Re: Can't debug dmd binary

[Lionello Lunesu via Digitalmars-d]

On 20/06/14 11:00, Jerry wrote:

Hi folks,

I'm unable to debug binaries built with dmd 2.065.  The platform is
x86-64 Ubuntu 14.04.  This is gdb 7.7.

If I have a simple program:

nodebug.d:

void main() {
   int i;
   i = 3;
}

dmd -g nodebug.d

jlquinn@wyvern:~/d$ gdb nodebug
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from nodebug...done.
(gdb) b main
Breakpoint 1 at 0x416ecc
(gdb) run
Starting program: /home/jlquinn/d/nodebug
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x00416ecc in main ()
(gdb) l
1   dl-debug.c: No such file or directory.
(gdb)


Using dmd -gc doesn't help at all.  Any suggestions?

Thanks
Jerry



$gdb nodebug
(gdb) b _Dmain
(gdb) r

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 19/06/14 15:59, Timon Gehr wrote:

On 06/18/2014 09:54 PM, Meta wrote:

...

This could be a bad thing. It makes it pretty enticing to use contracts
as input verification instead of logic verification.


The following is doable as well with a standard range analysis:

byte foo(immutable int x){
 if(xbyte.max)
 throw new InvalidArgumentException("...");
 return x; // ok
}


That will only work now if you use an "else".

Re: Adding the ?. null verification

[Lionello Lunesu via Digitalmars-d]

On 19/06/14 00:17, Etienne wrote:

I want non-null in the type system! To put a nullable reference into a
non-null variable you need to check first, but from then on the compiler
can ensure it's never null!


That would be great but useless for my situation involving some complex
AST's

class AEntity
{
 Module head;
 string ident;
 Type type;
 AEntity typeInfo;
 AEntity[] members; // for definitions
 AEntity[] parameters; // if parameterized
...
}

It's very useful to descend through parts of a complex tree without
adding plenty of bool checks

foreach (AEntity member; entity.members)
{
 if (member.typeInfo !is null)
 {
 AEntity curr = member;
 member.ident ~= member.typeInfo.ident;
 curr = member.typeInfo;
 while (curr.typeInfo !is null)
 {
 member.ident ~= "." ~ curr.typeInfo.ident;
 curr = curr.typeInfo;
 }
 }
}


And all of those references can be null at any time? Non-null would 
force you to initialize some/all of those values to a non-null 
reference, with the compiler ensuring that that is really the case.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 18/06/14 16:42, Sönke Ludwig wrote:

Or even better, "valueRange", to be consistent with the general naming
convention.


That's what I ended up calling it.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 18/06/14 16:28, bearophile wrote:

Lionello Lunesu:


ubyte foo(immutable int x)
in {
assert(x >= 0 && x <= ubyte.max);
} body {
return x;
}


Yeah, I wanted to support "assert" as well, but it doesn't create a
scope so it'll be a bit trickier to implement.


If you have an assert in a pre-condition and the argument is const, then
the body{} is the scope you look for.

Bye,
bearophile


That's a good point! I checked the DMD code and it seems doable. I can 
reuse the "ConditionVisitor" that I wrote for if-else.


Will play with it.

Re: Adding the ?. null verification

[Lionello Lunesu via Digitalmars-d]

On 18/06/14 23:42, Etienne wrote:

I find myself often repeating this boilerplate:

if (obj.member !is null)
{
 if (obj.member.nested !is null)
 {
 if (obj.member.nested.val !is null)
 {
 writeln(obj.member.nested.val);
 }
 }
}

I have to admit it's a little frustrating when you see swift's ?. syntax
notation, it would be a little more practical to be able to write

writeln(obj.member?.nested?.val);


Based on http://appventure.me/2014/06/13/swift-optionals-made-simple/


Any thoughts?


I want non-null in the type system! To put a nullable reference into a 
non-null variable you need to check first, but from then on the compiler 
can ensure it's never null!

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 18/06/14 20:46, "Nordlöw" wrote:

Very cool. With your new trait I can simplify and, in turn, reduce
compilation time for usages of


Actually, if I'm not mistaken, with this trait, we can inhibit range
value range checking in run-time when and get all the benefits Ada range
types currently delivers.

Yet another sales point for D!


I submitted a pull request with the trait, without the if-else stuff! 
This should be faster to make it in.


https://github.com/D-Programming-Language/dmd/pull/3679

L.

Re: RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

On 18/06/14 15:53, bearophile wrote:

I've also added a __traits(intrange, ) which returns a
tuple with the min and max for the given expression.


I'd like a name like integral_range, and perhaps it's better for it to
return a T[2] (fixed size array) instead of a tuple.


Most other traits return tuples, so it seemed like a good fit.


I presume your proposal allows this code to compile:

int x = 100;
void main() {
 if (x >= 0 && x <= ubyte.max) {
 ubyte y = x;
 }
}


Yes, provided 'x' is immutable or const. It can be extended for mutable 
values as well, but then mutations/gotos must be tracked.



If your proposal is extended to contracts, you can also write:


ubyte foo(immutable int x)
in {
 assert(x >= 0 && x <= ubyte.max);
} body {
 return x;
}


Yeah, I wanted to support "assert" as well, but it doesn't create a 
scope so it'll be a bit trickier to implement.


L.

RFC: Value range propagation for if-else

[Lionello Lunesu via Digitalmars-d]

Hi,

I got this thing working and I think it's about time I get some comments 
on it.


I've been wanting to extend Value Rang Propagation (VRE) for some time 
now. Mostly because of the fix to the troublesome "signed-unsigned 
comparisons" issue. Enabling VRE for if-else and "&&" will fix many of 
the false-positive warnings given out by the fix to bug 259 by allowing 
code like this: if (signed > 0 && signed < unsigned) { .. }


Have a look at the branch:
https://github.com/lionello/dmd/compare/if-else-range

There, I've also added a __traits(intrange, ) which returns 
a tuple with the min and max for the given expression. It's used in the 
test case as follows:



const i = foo ? -1 : 33;

if (i)
  static assert(__traits(intrange, i) == Tuple!(-1, 33));
else
{
  //static assert(i == 0); TODO
  static assert(__traits(intrange, i) == Tuple!(0, 0));
}

if (i == 33)
{
  //static assert(i == 33); TODO
  static assert(__traits(intrange, i) == Tuple!(33, 33));
}
else
  static assert(__traits(intrange, i) == Tuple!(-1, 32));

if (10 <= i)
  static assert(__traits(intrange, i) == Tuple!(10, 33));
else
  static assert(__traits(intrange, i) == Tuple!(-1, 9));


It would be nice if this can be used by CTFE as well.

Destroy?

L.

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 18/05/14 08:46, Dragos Carp wrote:

On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:

Hi all,

After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible
is this?

I'll be staying at Aloft. Would be great if there's someone I can
share a ride with. I've also seen there's a public bus going more or
less to FB and back, so I should be good there. (Right?)

But how about getting to SFO or down town? Am I causing myself a whole
lot of pain (albeit of a different kind) by not renting a car? To be
clear, I'm not looking for an economical option, just peace of mind.

Lio.


Hi all,

I will also stay at Aloft and have a car (at least 3 seats
available). Also if somebody arrives on Tuesday, May 20th around
5:00 pm at San Francisco International Airport and needs to get
to Aloft, please leave me a message.

Dragos


I'll arrive at 6:24 PM (not 6:40) from Chicago.

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 20/05/14 09:27, Iain Buclaw via Digitalmars-d wrote:

FYI I was stuck at border control for 2 hours - incase anyone else is an
alien.



I just passed customs in Chicago. Never entered the US so easily.

Interestingly, it was much easier this time (leisure) than when I used 
to fly to US for business when working for Microsoft(!).


L.

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 18/05/14 08:46, Dragos Carp wrote:

On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:

Hi all,

After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible
is this?

I'll be staying at Aloft. Would be great if there's someone I can
share a ride with. I've also seen there's a public bus going more or
less to FB and back, so I should be good there. (Right?)

But how about getting to SFO or down town? Am I causing myself a whole
lot of pain (albeit of a different kind) by not renting a car? To be
clear, I'm not looking for an economical option, just peace of mind.

Lio.


Hi all,

I will also stay at Aloft and have a car (at least 3 seats
available). Also if somebody arrives on Tuesday, May 20th around
5:00 pm at San Francisco International Airport and needs to get
to Aloft, please leave me a message.

Dragos


I'll arrive at 6:40pm, no check-in luggage, no customs. But don't wait 
on my account, I'll try to catch one of them shuttles I heard so much about.


L.

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 20/05/14 07:21, Iain Buclaw via Digitalmars-d wrote:


On 19 May 2014 23:07, Lionello Lunesu via Digitalmars-d
mailto:digitalmars-d@puremagic.com>> wrote:

On 19/05/14 15:37, Lionello Lunesu wrote:

Have inquired further how to recognize the shuttles at SFO.


FYI: http://www.flysfo.com/to-from/__ebs/shared-ride-vans
<http://www.flysfo.com/to-from/ebs/shared-ride-vans>


Yeah, shuttles is how Manu got to Aloft last year.  IIRC it's useful
only if you are shared with people going in the same direction.

FYI:  BART is $11, and taxi from Union -> Aloft is $20.


Yeah, it's cheap if you are part of 1 "party", then it's $10 for any 
additional person.


I'll arrive at SFO on May 20, 6:24 PM. I can stick around SFO for an 
hour or so if there's others in that time frame that want to share a 
shuttle to Aloft. Email me lio@lunesu, or wechat 'lionello'.


L.

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 19/05/14 15:37, Lionello Lunesu wrote:

Have inquired further how to recognize the shuttles at SFO.


FYI: http://www.flysfo.com/to-from/ebs/shared-ride-vans

Re: [OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

On 07/05/14 06:11, Mike wrote:

On Tuesday, 6 May 2014 at 02:20:46 UTC, Lionello Lunesu wrote:

Hi all,

After last year's incident with my tires getting slashed, I'm really
hoping I can do without a car during this year's DConf. How feasible
is this?

I'll be staying at Aloft. Would be great if there's someone I can
share a ride with. I've also seen there's a public bus going more or
less to FB and back, so I should be good there. (Right?)

But how about getting to SFO or down town? Am I causing myself a whole
lot of pain (albeit of a different kind) by not renting a car? To be
clear, I'm not looking for an economical option, just peace of mind.

Lio.


I'm wondering about this myself.

My current plan to get from SFO to the Aloft is via BART (SFO -> Balboa
Park -> Bay Fair -> Freemont) and then take a bus or a taxi from
Freemont to the hotel.

It looks like one could take bus 200 from the Aloft to the Ardenwood
Park-and-ride, transfer to bus DB, and cross the bridge to Facebook.

But, thinking about it a little more, a car is starting to look pretty
good.

Mike


The GM from Aloft replied to my inquiry about transportation:

"There are shuttles at the airport and you can always arrange for one to 
take you back from the hotel as well.  Public transportation options 
would be the BART which is our local subway system.  This can take you 
from SFO to the Union City Bart Station which has cabs posted outside 
and it is then just a 10-15 cab ride to the hotel."


Have inquired further how to recognize the shuttles at SFO.

L.

[OT] DConf - How to survive without a car?

[Lionello Lunesu via Digitalmars-d]

Hi all,

After last year's incident with my tires getting slashed, I'm really 
hoping I can do without a car during this year's DConf. How feasible is 
this?


I'll be staying at Aloft. Would be great if there's someone I can share 
a ride with. I've also seen there's a public bus going more or less to 
FB and back, so I should be good there. (Right?)


But how about getting to SFO or down town? Am I causing myself a whole 
lot of pain (albeit of a different kind) by not renting a car? To be 
clear, I'm not looking for an economical option, just peace of mind.


Lio.

Re: DIP56 Provide pragma to control function inlining

[Lionello Lunesu]

On 23/02/14 20:07, Walter Bright wrote:

http://wiki.dlang.org/DIP56

Manu has needed always inlining, and I've needed never inlining. This
DIP proposes a simple solution.


void A()
{
}

void B()
{
  pragma(inline, true) A();
}

void C()
{
  B();
}

Reading that code, I would guess that within B(), the call to A() would 
get inlined. Reading the DIP, it appears that the pragma controls 
whether B() gets inlined.


When the pragma is used outside of the scope at the function declaration 
it would work more like "inline" or "__inline" in C++, correct?


L.

Re: DIP56 Provide pragma to control function inlining

[Lionello Lunesu]

On 24/02/14 06:12, Walter Bright wrote:

On 2/23/2014 1:41 PM, Namespace wrote:

pragma(inline, true);
pragma(inline, false);
pragma(inline, default);


'default' being a keyword makes for an ugly special case in how pragmas
are parsed.



Aren't true and false keywords as well?

Re: between and among: worth Phobosization?

[Lionello Lunesu]

On 12/17/13, 4:38, Andrei Alexandrescu wrote:

bool between(T, U1, U2)(T v, U1 lo, U2 hi)
{
 return v >= lo && v <= hi;
}


The expression apeople expect.




uint among(T, Us...)(T v, Us vals)
{
 foreach (i, U; Us)
 {
 if (v == vals[i]) return i + 1;
 }
 return 0;
}


"in"?

assert("a" in ["a":1, "b":1]);

Again, with little compiler magic we could allow that to be written as

assert("a" in ["a", "b"]);

Note that I'm not advocating for O(n) "in" for regular arrays, but 
merely for the compiler to recognize the "in []" pattern and Do The 
Right Thing.


L.

Re: between and among: worth Phobosization?

[Lionello Lunesu]

Finally able to update the posts from the newsserver and saw both got 
mentioned before.


I agree with the "Don't change semantics of C code", so that rules out 
a

L.

Re: dlang.org appears to be blocked in China

[Lionello Lunesu]

On 12/14/13, 19:44, Kagamin wrote:

unblocksit.es ?


Did not know that one, but there's plenty of solutions for getting 
around the firewall. I was looking for a thing I could quickly 
copy-paste into an email that I send out to attendees.


L.

Re: dlang.org appears to be blocked in China

[Lionello Lunesu]

On 12/14/13, 20:44, Domain wrote:

On Saturday, 14 December 2013 at 10:15:35 UTC, Lionello Lunesu wrote:

...and I'm having this D workshop tomorrow. Is there a mirror with the
latest DMD binaries for all platforms?

If not, I will copy the binaries over to my personal server as a temp
mirror.

L.


我在中国，可以访问dlang.org啊！
I can access dlang.org in China, although it's slow.


Yeah, seems to be on again, off again.

Re: dlang.org appears to be blocked in China

[Lionello Lunesu]

On 12/14/13, 19:13, "Théo B" " wrote:

On Saturday, 14 December 2013 at 10:15:35 UTC, Lionello Lunesu wrote:

...and I'm having this D workshop tomorrow. Is there a mirror with the
latest DMD binaries for all platforms?

If not, I will copy the binaries over to my personal server as a temp
mirror.

L.


http://dlang-fr.org/files/


Great!

Re: dlang.org appears to be blocked in China

[Lionello Lunesu]

On 12/15/13, 12:23, Orvid King wrote:

On Sat, 14 Dec 2013 20:55:28 -0600, Puming  wrote:


On Saturday, 14 December 2013 at 10:15:35 UTC, Lionello Lunesu wrote:

...and I'm having this D workshop tomorrow. Is there a mirror with
the latest DMD binaries for all platforms?

If not, I will copy the binaries over to my personal server as a temp
mirror.

L.


dlang.org is slow and seems to be blocked because of the twitter part
in the front page. The download page is actually not blocked.

you can access it by url: http://dlang.org/download.html

or as I always does, by accessing the forum first, and click on the
Download &Tools link in the side bar.



You can also solve this problem more perminately on your own machine by
simply adding pbs.twimg.com, twitter.com, platform.twitter.com, and
cdn.syndication.twimg.com to your hosts file, and having them resolve to
localhost.


That's a good tip.

Who knows how to do asynchronous javascript or what-do-the-kids-call-it, 
so that the page doesn't block when one script/image blocks.

Re: dlang.org appears to be blocked in China

[Lionello Lunesu]

On 12/14/13, 18:25, Joseph Rushton Wakeling wrote:

On 14/12/13 11:15, Lionello Lunesu wrote:

...and I'm having this D workshop tomorrow. Is there a mirror with the
latest
DMD binaries for all platforms?


Use an ssh proxy?


Yes, that works for me, but not for [all] the attendees :)

L.

dlang.org appears to be blocked in China

[Lionello Lunesu]

...and I'm having this D workshop tomorrow. Is there a mirror with the 
latest DMD binaries for all platforms?


If not, I will copy the binaries over to my personal server as a temp 
mirror.


L.

Re: Checking function parameters in Phobos

[Lionello Lunesu]

On 11/20/13, 18:45, Lars T. Kyllingstad wrote:

I think we should use ubyte[] to a greater extent for data which is
potentially *not* valid UTF.  Examples include interfacing with C
functions, where I think there is a tendency towards always translating
C char to D char, when they are in fact not equivalent.  Another example
is, again, std.file.read(), which currently returns void[].  I guess it
is a matter of taste, but I think ubyte[] would be more appropriate
here, since you can actually use it for something without casting it first.


+1

Especially the windows APIs, they never take UTF-8(*) but consistently 
get translated to taking D char :(


In fact, if we want a good translation from C to D, we should be using D 
byte. On most platforms I've run into have C char is signed. (To be 
honest, you don't see 'byte' much in D code, so it would make the ported 
code stand out even more.)


* except from MultiByteToWideChar

Re: C++ namespace support (@Walter)

[Lionello Lunesu]

On 11/8/13, 22:01, bearophile wrote:

Luís Marques:


Is there a document that explains how the C++ namespace support is
going to look like?


In the D world sometimes people implement first, and discuss later...

Bye,
bearophile


;)

Re: C++ namespace support (@Walter)

[Lionello Lunesu]

On 11/8/13, 0:17, Dejan Lekic wrote:

After a year and a half (
https://d.puremagic.com/issues/show_bug.cgi?id=7961 ) I have to remind
Walter and Co. about this enhancement request. :) This is becoming
increasingly important not just to me, but to the D community in general.


I already looked into how this would get done. I assigned the bug to myself.

Re: std.allocator ready for some abuse

[Lionello Lunesu]

On 10/27/13, 7:10, Andrei Alexandrescu wrote:

The second problem is that the logged file/line is always in
std.allocator.d. It's probably not easy to get this working in all
cases (especially regarding polymorphism).


Uhm, that /is/ a problem.


This is supported by using default values:

1:import std.stdio;
2:void w(int l = __LINE__){writeln(l);}
3:void main(){w();}

outputs:
3

By design :)

Re: Tristate - wanna?

[Lionello Lunesu]

On 10/26/13, 17:42, Andrei Alexandrescu wrote:

unittest
{
 Tristate a;
 assert(a == Tristate.no);


Why not have '0' map to unknown? Seems to more useful, like float.nan 
and the like.


L.

Re: dmd 2.064 beta 4 badly broken: dirEntries segfaults + other regressions

[Lionello Lunesu]

On 10/31/13, 2:19, Timothee Cour wrote:

see my recent regressions I posted on bugzilla.


Ugh, you don't want to know how much time I wasted on this. I was 
convinced it was something I had done, some old phobos somewhere.

Re: Tristate - wanna?

[Lionello Lunesu]

On 10/27/13, 11:07, Timon Gehr wrote:

On 10/27/2013 02:11 AM, Andrei Alexandrescu wrote:

On 10/26/13 5:13 PM, Timon Gehr wrote:

The following implementation does not use conditionals; probably
not minimal.


Thanks! Fixed two minor bugs:


this(bool b) { value = b; }

void opAssign(bool b) { value = b; }


These should shift b so it becomes 2 if true. ...


Good point.


Pushed your code with the fixes and a full truth table unittest:

https://github.com/andralex/phobos/blob/allocator/std/allocator.d#L236




Nice work. I'd say this is nontrivial enough to be put in the standard

library.


Andrei




Thanks!


Couldn't this be optimized further, by doubling the constants?

(A>>(a+b)&3)<<1 ==> A2>>(a+b)&6 ?

Re: Delegate is left with a destroyed stack object

[Lionello Lunesu]

On 10/30/13, 10:56, David Nadlinger wrote:

---
void main() {
   import std.stdio;

   void delegate()[] dgs;
   foreach (i; 0 .. 5) dgs ~= { writeln(i); };

   foreach (dg; dgs) dg();
}
---

If structs behaved like you want them to, the snippet would (have to)
print 0, 1, 2, 3, 4 as well,


Did NOT know that. Thanks for letting me know :)


and tht's definitely too big a language change to consider at this stage.


Well, that's a separate issue, whether to change the language or not. 
It's still valuable to discuss unexpected behavior when one runs into it.


L.

Re: Delegate is left with a destroyed stack object

[Lionello Lunesu]

On 10/29/13, 22:42, David Nadlinger wrote:

On Tuesday, 29 October 2013 at 21:41:25 UTC, Lionello Lunesu wrote:

So a copy should have been made of the live object, not the destructed
one. Correct?


No. There should only be one struct instance, the one living (forever)
in the closure context.

David


Why? It's a struct. It should be completely fine to create a copy [on 
the heap] for the closure context.


The way I see closure is that any referenced locals become hidden 
arguments. Imagine an implicit ", S s" in the closure's parameter list. 
Everybody would expect 's' (being a value type) to be a copy.


If you want to ensure there's only one instance, you either need to use 
class instead of struct, or allocate 's' on the heap and use a pointer to S.


L.

Re: Delegate is left with a destroyed stack object

[Lionello Lunesu]

On 10/29/13, 22:37, Ali Çehreli wrote:

To add to that, Maxim Fomin notes in the D.learn forum that there are
the following conflicting requirements:


So a copy should have been made of the live object, not the destructed 
one. Correct?


Sounds like the destruction and the copy are happening in the wrong order.

Re: C to D bindings: how much do you D-ify the code?

[Lionello Lunesu]

On 10/26/13, 12:54, Jacob Carlborg wrote:

2. Slightly D-ify the C bindings. I.e. be able to pass D strings instead
of C strings


Hadn't even mentioned that one, but yeah, that's one of my favorite 
overloads!


L.

Re: C to D bindings: how much do you D-ify the code?

[Lionello Lunesu]

On 10/25/13, 15:34, Dicebot wrote:

I think best approach is to have 2-step bindings. First step is pure
1-to-1 translation with no D-ification at all. Second step is D wrapper
that expresses same functionality in more native syntax (probably even
more type-safe). Step-2 module imports Step-1 module of course.

Benefit of such approach is that you can generate bindings using
automatic tool when new header version is out without wasting time on
adjusting those to D style again and again - you only need to change
step-2 module if there are some breaking API changes.


That's a good point. A "diff" is much more manageable with a 1:1 conversion.

L.

Re: C to D bindings: how much do you D-ify the code?

[Lionello Lunesu]

On 10/25/13, 18:22, John Colvin wrote:

On Friday, 25 October 2013 at 13:26:33 UTC, John Colvin wrote:

On Friday, 25 October 2013 at 13:10:05 UTC, Lionello Lunesu wrote:

There's a lot of expressiveness that can be added to D bindings, when
compared to the C or C++ headers, for a particular library:

1. enum names vs prefixes
enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}

2. enum vs int parameters (based on a lib's documentation)
void takefoo(int) -> void takefoo(FOO)

3. "in" for input buffers (again, based on docs)
int puts(char*) -> puts(in char*)

4. "out" or "ref" for output parameters
void getdouble(double*) -> void getdouble(out double value)

5. D arrays vs length+pointer pairs
void bar(size_t len, int* ptr) -> void bar(int[] a)

6. D array wrappers
void bar(int* ptr, int size) ->
void bar(int[] a) { bar(a.ptr, cast(int)a.length; }

6. library specific sized-int typedefs to D natives
png_uint_16 -> short


These are some of the more trivial ones, but I'd like to see how
other people go about making bindings. Do you keep as close to C as
possible? Or do you "add value" by using more D style constructs?

L.


I would go for a two stage approach:

1) Write bindings that map as closely as possible to the C API, only
adding anything extra by necessity and/or where it is transparent in
correct usage.


As an aside, I would suggest that function overloads that take arrays
instead of pointer + length is normally a harmless addition to an
otherwise 1:1 set of bindings.


Thanks for the feedback, but your last reasoning could be applied to the 
other points just as well :)


L.

C to D bindings: how much do you D-ify the code?

[Lionello Lunesu]

There's a lot of expressiveness that can be added to D bindings, when 
compared to the C or C++ headers, for a particular library:


1. enum names vs prefixes
enum FOO { FOO_A, FOO_B }; -> enum FOO {A,B}

2. enum vs int parameters (based on a lib's documentation)
void takefoo(int) -> void takefoo(FOO)

3. "in" for input buffers (again, based on docs)
int puts(char*) -> puts(in char*)

4. "out" or "ref" for output parameters
void getdouble(double*) -> void getdouble(out double value)

5. D arrays vs length+pointer pairs
void bar(size_t len, int* ptr) -> void bar(int[] a)

6. D array wrappers
void bar(int* ptr, int size) ->
void bar(int[] a) { bar(a.ptr, cast(int)a.length; }

6. library specific sized-int typedefs to D natives
png_uint_16 -> short


These are some of the more trivial ones, but I'd like to see how other 
people go about making bindings. Do you keep as close to C as possible? 
Or do you "add value" by using more D style constructs?


L.

Re: More on C++ stack arrays

[Lionello Lunesu]

On 10/23/13, 23:30, John Colvin wrote:

On Tuesday, 22 October 2013 at 21:05:33 UTC, Lionello Lunesu wrote:

Careful! Alloca doesn't get cleaned up when used in loops!


scope(exit) works in a loop, so you can automatically clean it up like
that.

Destructors are also called on each iteration so RAII is an option.


You can't clean up alloca'ed memory, AFAIK.

Re: More on C++ stack arrays

[Lionello Lunesu]

On 10/23/13, 21:36, Denis Shelomovskij wrote:

23.10.2013 1:05, Lionello Lunesu пишет:

Careful! Alloca doesn't get cleaned up when used in loops!


And I don't use `alloca`.



Ah, indeed. I got your post mixed up with the one using alloca.

Re: More on C++ stack arrays

[Lionello Lunesu]

On 10/21/13 15:04, Manu wrote:

On 21 October 2013 21:24, Denis Shelomovskij
mailto:verylonglogin@gmail.com>> wrote:

21.10.2013 14:30, Manu пишет:

System interface functions that pass zero-terminated strings
through to
the OS are the primary offender, needless garbage, those should
be on
the stack.

I like to use alloca too where it's appropriate. I'd definitely
like if
D had a variable-sized static array syntax for pretty-ing alloca.
I thought about something similar using alloca via a mixin
template, but
that feels really hackey!


No hacks needed. See `unstd.c.string` module from previous post:

http://forum.dlang.org/thread/__lqdktyndevxfcewgthcj@forum.__dlang.org?page=2#post-l42evp:__241ok7:241:40digitalmars.com




Super awesome! Phobos devs should be encouraged to use these in
non-recursive functions (particularly OS pass-through's).


Careful! Alloca doesn't get cleaned up when used in loops!

foreach(t; 0..1000) { int[t] stack_overflow; }

Re: An interesting way to teach someone a library

[Lionello Lunesu]

On 10/21/13 20:33, Iain Buclaw wrote:

http://nodeschool.io/


Some of the phrases are taken from learnyouahaskell.com - but it is
still a good idea for a teaching tool.

By the way, how's dtutor coming along?  Haven't seen much activity in a
while...


Regards
Iain.


dtutor!

Re: core.bitop.bt semantics

[Lionello Lunesu]

On 10/20/13 21:23, David Nadlinger wrote:

The documentation [1] for core.bitop.bt just says "Tests the bit."

With the function returning an int, the question is whether the return
value is guaranteed to be 0 or 1, as ensured by the current
implementation, or whether it can be any non-zero integer if the bit is
set (as documented for the related bts function).

The std.bitmanip.BitArray formatting functions in 2.064 assume the
former, and are thus currently broken with LDC. LDC will probably end up
switching to simply using the D implementation anyway as LLVM recognizes
the pattern just fine, but I'd like to know what to fix first.

David


[1] http://dlang.org/phobos/core_bitop.html


bt, bts, btr, btc all have the same return value. They only differ in 
what happens with the tested bit. The fact that they return "int" 
amplifies the zero / non-zero pattern.


I think BitArray should get fixed to support that definition. But you 
might want to keep "bt" on LDC the same as on DMD, just to prevent 
similar bugs in user's code.


L.

Re: More on C++ stack arrays

[Lionello Lunesu]

On 10/20/13 16:25, bearophile wrote:

More discussions about variable-sized stack-allocated arrays in C++, it
seems there is no yet a consensus:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf

I'd like variable-sized stack-allocated arrays in D.

Bye,
bearophile


Good read, but many of the problems don't apply to D ;)

The problem is that it'll probably be like using alloca, which doesn't 
get cleaned up until after the function exits. Using it within a loop is 
bound to cause a stack overflow. I wonder if there's something we can do 
to 'fix' alloca in that respect.


L.

Re: I don't like slices in D

[Lionello Lunesu]

On 10/17/13 22:03, Vitali wrote:

   // but what is the purpose of this?


auto arr1 = [1,2,3];
auto arr2 = arr1;
arr2.length--;
arr2 ~= 4;  // append 4

What do you expect arr1[2] is?


|
|
|
|
|
|
|
|
|
|
v

It's the original value 3! Which makes sense: why would the slice affect 
the original array? If that were the case you wouldn't be able to safely 
pass a slice of a big array to any function.

Re: Improved Phobos dox

[Lionello Lunesu]

On 9/15/13 15:14, Andrei Alexandrescu wrote:

I finally gathered strength to rebase
https://github.com/D-Programming-Language/dlang.org/pull/271 manually,
which was every bit as involved as I feared.

I hope I didn't mess up anything, reviews appreciated.

That diff includes a new page navigation scheme. (Wasn't the main
purpose of the diff but found it a nice perk.) I see it as a
transitional stage toward the larger transition to one-page-per-entity
that Sönke has proposed.

Check out the new navigation at
http://erdani.com/d/phobos/std_array.html. The ugly "Jump to" list as
the top gets replaced by a slick drop-down. Once you jump to a name, you
can go back by pressing the up arrow on the right or simply go to top.


Andrei


Could you have a look at 
https://github.com/D-Programming-Language/dmd/pull/2121 ?


I'm not sure what's holding that PR up, no concerns were raised, but it 
would greatly improve the quality of the documentation.


L.

Re: dub: should we make it the de jure package manager for D?

[Lionello Lunesu]

On 9/11/13 5:01, Brad Anderson wrote:

I vote yes but only if Sönke feels it is ready. I suspect he has a few
things he'll probably want done before this happens (the potential
switch from JSON to SDL comes to mind).


SD-what?! Why would alienate people even more than we already do?

L.

Re: dmd2 mac os x compilation problem

[Lionello Lunesu]

On 9/8/13 18:56, "Batuhan Göksu" " wrote:

Hi Friends,

dmd2 files downloaded at this address.

I took the files to the destination directory in this way.

/usr/dmd2
/usr/dmd2/bin
/usr/dmd2/lib
/usr/dmd2/man
/usr/dmd2/src

edited config file.

[Environment]

DFLAGS=-I/usr/dmd2/src/phobos -I/usr/dmd2/src/druntime/import
-L/usr/dmd2/lib

A simple example code.

import std.stdio;

void main()
{
 writeln("Hello World");
}

Giving this error when I want to compile.

ld: library not found for -lphobos2
collect2: ld returned 1 exit status
--- errorlevel 1

needed to do to solve this problem?

.dmg file in the destination directory and the installation does not
want to set up.

sincerely.


Can you try with -m64? You might only have the 64-bit phobos library.

L.

Re: Enum alias members: yay or nay?

[Lionello Lunesu]

On 9/8/13 8:08, Andrej Mitrovic wrote:

I've recently ran into a bug that was very hard to track down for me.
I've had a good set of unittests, but I kept getting the wrong results
out of my functions, which was very bizarre.

To boil it down, when you introduce a member in an enum which
initializes itself to another member of that enum, the next member
after it will be initialized to + 1 of the previous member. So:

enum E
{
 a,
 b = a,
 c
}

Here, a equals 0, b equals 0 as well, and c equals b + 1, so it's 1.
There's nothing problematic here.

The real problem appears when you need to make sure each member is
unique, except for any members which are either convenience members or
are deprecated members (there's no "deprecated" member feature
yet[2]).

Here's an example:

enum MouseAction
{
 ///
 press,

 ///
 release,

 /** Convenience - equal to $(D press). */
 click = press,

 ///
 double_click,
}

Notice how introducing the convenience member has re-set the enum
initializer counter, meaning double_click will be equal to (click +
1), which is really (press + 1), which becomes (1). But (1) is also
the intializer for "release", so by mistake I made "double_click"
equal "release", and hence my bug.

So to work around this, I thought about introducing an alias feature to enums:

enum MouseAction
{
 press,

 release,

 alias click = press,  // does not reset the counter!

 double_click,  // equals release + 1
}

The alias member would not re-set the counter and instead the next
non-alias member would initialize itself to the previous non-alias
member + 1.

This would also lend itself well with the "deprecated" keyword, where
we could add deprecated aliases for old enum members when we want to
rename the members. For example, if you want to rename a Phobos enum
you can currently do :

enum SpanMode
{
 shallow,
 deep,
 depth = deep;  /// $(RED Deprecated, please use .deep)
 breadth,
}


I won't deny the possibility of human error here, but I don't think it's 
worth complicating the language for this case. It's easily fixed by 
putting the 'alias' after the 'good' enum value.


The case for 'deprecate' is much stronger, though. It's impossible to 
deprecate enum values now.

Re: new DIP47: Outlining member functions of aggregates

[Lionello Lunesu]

On 9/8/13 1:00, Walter Bright wrote:

Outlining of member functions is the practice of placing the declaration
of a member function in the struct/class/union, and placing the
definition of it at global scope in the module or even in another module.

http://wiki.dlang.org/DIP47


I would restrict it to a single module for the time being.

We can always open it up to other modules later, but we wouldn't be able 
to restrict it back to a single module, since that would be a breaking 
change.


L.

Re: Move VisualD to github/d-programming-language ?

[Lionello Lunesu]

On 9/8/13 3:04, Walter Bright wrote:

Recent threads here have made it pretty clear that VisualD is a critical
piece of D infrastructure. (VisualD integrated D usage into Microsoft
Visual Studio.)

Andrei, myself and Rainer (VisualD's champion) are all in agreement on
this.

What do you think?


Oh, yes!

Not only is VisualD the best D IDE [on Windows], but it has crucial 
pieces of software in it. Check out its C++ to D conversion tools!


L.

Re: Structs can't be zero bytes in size?

[Lionello Lunesu]

On 9/3/13 10:59, Andrej Mitrovic wrote:

On 9/3/13, Lionello Lunesu  wrote:

struct Z {};
Z a, b;
assert(&a != &b);


Since the structs are declared empty, their 1-byte values don't
matter. So their addresses don't really matter either.



It has to do with the ol' 'identity vs equality'. In the example above, 
a and b are not identical ("do not refer to the same thing") and so 
their addresses should not be equal.


The address of two 'named things' is the same if-and-only-if the names 
refer to the same thing.


L.

Re: Replacing std.xml

[Lionello Lunesu]

On 8/29/13 15:25, w0rp wrote:

Hello everybody. I've been wondering, what are the current plans to
replace std.xml? I'd like to help with the effort to get a final XML
library in phobos. So, I have a few questions.

First, and most importantly, what do we except out of a D XML library?
I'd really like to have a discussion of the form, "Here is exactly the
interface the structs/classes need to implement, go forth and
implement." The general idea in my mind is "something SAX-like, with
something a little DOM-like." I'm aware that std.xml has some issues
support different encodings, so obvious that's included.

Second, is there an existing library that has gotten close to meeting
whatever we need for the first point? If so, how far away is it from
being able to meet all of the requirements and become the standard
library version?


Having been the lead programmer on the Microsoft XML team for three 
years, I can easily say that the most popular XML API [on MS stack] is 
the XmlReader and XLinq in .NET. (This has nothing to do with LINQ, by 
the way.)


I'd be willing to help make D versions of that, but my time is limited. 
But as usual, I don't think it's the actual coding that will take time. 
Designing a good interface is the hardest part, and I'd consider that 
part done.


L.

Re: Structs can't be zero bytes in size?

[Lionello Lunesu]

On 9/3/13 8:34, Vladimir Panteleev wrote:

On Tuesday, 3 September 2013 at 00:05:04 UTC, Walter Bright wrote:

On 9/2/2013 4:57 PM, Dylan Knutson wrote:

Can someone shed some light on this?


It comes from C. This was done in C so that addresses of struct
instances will always be unique.


Why is that important, and why does D need it?

In C, this might make some sense, however empty structs are much more
useful in D, e.g. for metaprogramming.


struct Z {};
Z a, b;
assert(&a != &b);

Re: Feature request: Optional, simplified syntax for simple contracts

[Lionello Lunesu]

On 6/16/13 8:42, Timon Gehr wrote:

On 06/16/2013 02:19 AM, Manu wrote:

Super awesome idea! How about coma separated expressions to perform
multiple asserts?

int func(int i, int j) in(i<5, j<10)
{
   return i + j;
}
...


Use &&.



Not the same. && won't tell you which one failed.

Re: File compare/merge

[Lionello Lunesu]

On 4/2/13 3:53, Walter Bright wrote:

Life has gotten a lot easier for me trying to manage multiple branches
of D since I've been using file compare/merge tools.

I use winmerge for Windows, and meld for Linux. They are both free, and
work great.

What do you use?


Under Windows I use TortoiseMerge, part of TortoiseGit/TortoiseSVN but 
also works standalone.

Under OSX/linux I use git diff --color --word-diff :S

L.

Re: Walter: htod on github?

[Lionello Lunesu]

On 5/28/13 12:11, Walter Bright wrote:

On 5/27/2013 8:35 PM, Lionello Lunesu wrote:

On 5/28/13 11:08, Diggory wrote:

On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:

Walter,

Any chance we can get the source of htod? If found it a very useful
little utility, although there are many issues with it.

VisualD also include a similar utility to convert header files to D,
but it is more tuned to Windows header files. Perhaps we can combine
the two into a new utility?

Lio.


I think htod is based on dmc so open sourcing it would be a problem.


Ah, right. I remember now :) HTOD is using the DMC frontend for C/H
parsing and
that's not open sourced. Got it.


I've been thinking about making it "source available".



What about keeping the DMC frontend code in a (static) library? Would 
that work for the time being?


L.

Re: Walter: htod on github?

[Lionello Lunesu]

On 5/28/13 11:08, Diggory wrote:

On Tuesday, 28 May 2013 at 02:32:24 UTC, Lionello Lunesu wrote:

Walter,

Any chance we can get the source of htod? If found it a very useful
little utility, although there are many issues with it.

VisualD also include a similar utility to convert header files to D,
but it is more tuned to Windows header files. Perhaps we can combine
the two into a new utility?

Lio.


I think htod is based on dmc so open sourcing it would be a problem.


Ah, right. I remember now :) HTOD is using the DMC frontend for C/H 
parsing and that's not open sourced. Got it.


L.

Walter: htod on github?

[Lionello Lunesu]

Walter,

Any chance we can get the source of htod? If found it a very useful 
little utility, although there are many issues with it.


VisualD also include a similar utility to convert header files to D, but 
it is more tuned to Windows header files. Perhaps we can combine the two 
into a new utility?


Lio.

Re: Transition for removing functions from Object [Compiler devs in particular, please read]

[Lionello Lunesu]

On 5/27/13 9:20, Jonathan M Davis wrote:

class D : C
{
 void foo() { writeln("D"); }
 void bar() { writeln(super.foo()); }
}


I think this works just fine, you just have to drop the writeln(). foo() 
doesn't return anything, but prints itself.


But yet, super should just work: it should be a variable of type C and 
treated as such.


L.

Re: DConf 2013 official car/room sharing thread

[Lionello Lunesu]

"Andrei Alexandrescu"  wrote in message 
news:kk6llv$29sl$1...@digitalmars.com...


I'll stay at Aloft (http://goo.gl/CHmzw) and will drive a compact
rental. Will gladly pick up people to and fro that hotel.

Andrei


Hey Andrei, you still got room in your car? I'm thinking of staying at a 
hotel nearby. (Aloft is full.)


Lio.

Re: Question about D, garbage collection and fork()

[Lionello Lunesu]

On 10-3-2011 6:56, Jerry Quinn wrote:

Where I work, we find it very useful to start a process, load data, then fork() 
to parallelize.  Our data is large, such that we'd run out of memory  trying to 
run a complete copy on each core.  Once the process is loaded, we don't need 
that much writable memory, so fork is appealing to share the loaded pages.  
It's possible to use mmap for some of the data, but inconvenient for other 
data, even though it's read-only at runtime.

So here's my question:  In D, if I create a lot of data in the 
garbage-collected heap that will be read-only, then fork the process, will I 
get the benefit of the operating system's copy-on-write and only use a small 
amount of additional memory per process?

In case you're wondering why I wouldn't use threading, one argument is that if 
you have a bug and the process crashes, you only lose one process instead of N 
threads.  That's actually useful for robustness.

Thoughts?




D's try-catch will catch all errors, even access violations and stack 
overflow:


import std.stdio;
void so() {
  so();
}
void main() {
  try {
so();
  }
  catch {
  }
  writeln("graceful exit");
}

By wrapping each thread's code in try-catch you can handle each thread 
going down. Of course, a thread can still corrupt the memory of another 
thread. To share memory between processes you'd have to use an OS 
specific API. On Windows you'd use a file mapping.


L.

Re: Build farm(er)

[Lionello Lunesu]

On 2010-08-06 5:44, Andrei Alexandrescu wrote:

On 08/06/2010 12:00 AM, BCS wrote:

Hello Andrei,


Hello,

I was talking yesterday with Walter and Brad about enacting a build
farm and the build master who would tend to it.



I'd be interested in partaking in such an endeavor. I was actually
thinking of doing something related (automatic regression testing). I
don't think I'd be a good candidate for maintaining the whole things but
I'd be willing to help.


That's great, thanks for volunteering. Automatic regression testing
sounds like a good starting point, feel free to start on it as you find
fit and post your progress. You may want to get familiar with the build
and test processes of dmd and phobos if you aren't.

In terms of machines, if anyone could volunteer ssh accounts to stable
machines (e.g. preferably not laptops and not connected via dynamic IP,
though the latter is satisfactorily fixed by dyndns.org), please chime in!

Andrei


I can offer shell access to my VPS: Ubuntu 8.04 LTS with static IP. 
Regular user access is enough?


L.

Re: [OT] CMS recommendation for these criteria...?

[Lionello Lunesu]

On 2010-07-27 13:58, Nick Sabalausky wrote:

I was going to try to whip up a simple thing myself, but I'm thinking if
there's something that'll already do what I need, why bother? So, does
anyone know of a CMS or blog system they can recommend that can be easily
set up to fit these requirements?:

- Works on Linux x86 / Apache 1.3.
- Uses either PHP5 or CGI.
- Uses MySQL (or even just flat files).
- Allows me to easily put up posts/articles.
- Public comments on the posts/articles.
- Anonymous comments, BUT requires a CAPTCHA for them (I've had nothing but
trouble with any other form of anti-spam).
- Everything is fully-functional without JS (Although, if the admin panel is
the only thing that requires JS, I can deal with that.)
- Passwords are never sent in the clear, even with JS off (I have an SSL
cert, so https is no problem, plus I'm not worried about https overhead).
- Doesn't have that session sidejacking exploit.
- Naturally, all the basic expected stuff, like editing posts, deleting bad
comments, etc.



PMWiki, no contest. http://www.pmwiki.org/

Re: This just in: authorless TDPL becomes collector's edition

[Lionello Lunesu]

On 2010-06-02 1:59, Andrei Alexandrescu wrote:

Due to a pretty odd mistake at the printer, the first 1000 copies of
TDPL will not have the name of the author on their cover. (The name
still appears on the back cover and the spine.)

The history of printing is rife with rare printing mistakes that have
become collector's editions. Preorder now to be among the first 1000
readers who get the authorless TDPL edition.


Andrei


Yeey! Got mine after 3+ weeks of waiting, and a 'collector's edition' no 
less!

OT: anybody up for a beer?

[Lionello Lunesu]

Unfortunately, I haven't been very active on the list lately (new city, 
new job) but I was wondering if anyone here's up for a beer (or, 
whatever) in the Seattle area a few weeks from now?


I'll be in Seattle from 7/19 to 8/7. Very exciting, since I've never 
been to that part of the world before. I'll have to get some work done 
there as well, but would love to meet some fellow D-ers in real life.


L.

Re: need clarification: will typedef, C struct initialization, etc.

[Lionello Lunesu]

On 4-6-2010 1:17, Adam Ruppe wrote:
>
> This strikes me as being a supremely elegant solution, not a hack.

struct Typedef( T, T init = T.init, Type type = Type.Sub, string _f =
__FILE__, int _l = __LINE__ ) { ...

Yes, that's a hack.

And it's great that we can do sub, super, independent and parallel, but
the question is: are they needed?

I thought I had found a compelling use case for typedef. Perhaps,
instead of throwing it out because it was ill defined, we should define
what's it supposed to solve and then make sure that's exactly what it
does, and nothing more.

L.

Re: need clarification: will typedef, C struct initialization, etc.

[Lionello Lunesu]

On 3-6-2010 14:58, Lars T. Kyllingstad wrote:
> On Thu, 03 Jun 2010 00:02:03 +0200, Simen kjaeraas wrote:
> 
>> On Wed, 02 Jun 2010 23:12:38 +0200, Adam Ruppe
>>  wrote:
>>
>>> On 6/2/10, Simen kjaeraas  wrote: *snip*
>>>
>>> I haven't tried your code, but it looks similar to my own code, which
>>> had this problem:
>>>
>>> alias Typedef!Int Handle;
>>> alias Typedef!Int OtherHandle;
>>>
>>> void foo(Handle h) { }
>>>
>>> OtherHandle b;
>>>
>>> foo(b); // compiles, but shouldn't. Problem is that Handle and
>>> OtherHandle are both alias of the same underlying thing, so the
>>> compiler considers them the same thing! With the old typedef, I'm
>>> pretty sure it would (correctly IMO) complain here.
>>
>> My code sidesteps that by including instantiation line and file, making
>> each instantiation unique (as long as you don't do multiple typedefs on
>> one line).
> 
> Cool trick! :)
> 
> -Lars

Cool trick indeed, but why do we need a trick for something so basic!?

A few years from now we'll wonder why compiling moderately sized D
projects takes a long time.

When you can do something, it doesn't mean that you should.

L.