Re: D and SCons
On Tue, 2017-05-02 at 15:39 -0700, H. S. Teoh via Digitalmars-d wrote:
>
[…]
> However, I have to confess that I found Russel's D tooling (the last
> time I tried it anyway, which was a while back) not quite up to what
> I'd
> like it to do. As a result, in my recent projects I've resorted
> simply
> to:
If there are no issues, there are no problems. But this leads to an
issue.
Currently the SCons issue tracker is on Tigris. Even though I should, I
rhaven't got back into using it – you have to go there and login, and
then I do not have enough rights to properly manipulate the D-related
issues. Bill and others quite rightly berate me for being recalcitrant,
but I just wish the issue tracker would switch to BitBucket where the
repositories are. Separating repositories and issue tracker doesn't
work in my world.
Talking of repositories, I started the SCons_D_Experiment on GitHub,
but I feel a pressure to move it to BitBucket so as to be on the same
host as the SCons repositories even though SCons uses Mercurial and
SCons_D_Experiment uses Git – BitBucket being a Git host these days,
and only supporting Mercurial for historical reasons.
Are people using SCons_D_Experiment repository to pick up the SCons D
tools?
> env = Environment(DMD = '/path/to/dmd', DMDFLAGS = [ ... ])
> env.Command('myprogram', Split("""
> myprogram.d
> module1.d
> module2.d
> """),
> "$DMD $DMDFLAGS -of$TARGET $SOURCES"
> )
>
> I realize this hamfisted approach doesn't work well in larger
> projects
> or mixed D/C/C++ projects because it doesn't integrate with SCons'
> built-in C/C++ support, but in practice I've found that trying to
> integrate D builds with the C/C++ separate compilation model ends up
> causing more headaches than necessary, so I just opted for the lazy
> way
> out.
I had been doing something similar to get whole source builds so as to
be able to use unit-threaded. It got annoying, so much so I added a new
builder to SCons, for the D tooling anyway, ProgramAllAtOnce.
So the above would now be:
env = Environment(tools=['dmd', 'link'],
DFLAGS=[….],
}
env.ProgramAllAtOnce('myprogram', [
'myprogram.d',
'module1.d',
'module2.d',
])
This is now in the mainline SCons repository and will appear in the
next release. Failing that you can use the SCons_D_Experiment tools
with a current SCons release.
I think people using SCons and D need to hide away less and complain
more, especially if the complaints come with test cases, issues, and
pull requests. Currently stuff only happens when I get irritated and do
stuff. If people don't like the stuff I am doing, but do not say
anything, just hacking away for themselves, then we do not get progress
helpful to the community.
So will people add issues to Tigris (which would be best and what Bill
et al. would prefer) or do we use an issue tracker on
SCons_D_Experiment. Do I stick in GitHub or move to BitBucket?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 06:45:05 UTC, Bastiaan Veelo wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. Likewise! I am at the airport as I type. Bastiaan. are you in Berlin already ? I am going to arrive near 19:00. Anyone up for having a pre-conf drink ?
Re: D and SCons
On Wed, 2017-05-03 at 00:05 +0200, Dmitry Olshansky via Digitalmars-d wrote: > […] > I've come to like SCons for my C++ projects. Way more so than say > CMake. > It would be awesome to have full-fledged support for D there esp. in > mixed C++ with D setup. I had been using SCons, SConsolidator, and Eclipse for C++ projects, or Emacs, but when I found CLion I became a bit of an addict. Sadly though it means using CMake – for now. For GStreamer related projects I am using Meson. SCons has D as a peer to C, C++, and Fortran. I think the D community should make use of this, especially those with mixed C++/D codebases. I am working on a dub tool to access the Dub repository without using Dub as a build system. I have it grabbing unit-threaded and working fine. I suspect though I am the only user. > Not sure what you mean but did a quick look on the text. The > compiler > section and "Some general thoughts" feels a bit copy-pasty. I would > also > replace "to create the system" with "to create the compiler" or some > such. I rushed it off in 10 minutes, so yes, there is a bit of cut-and-paste. The question is does the page have an audience? If yes then it is worth progressing, if not then working on it would be wasted work. > > Could use some from: > http://dlang.org/download.html Good thinking, I wish I had thought of that :-) I'll check licences and if allowable do the copy and use thing. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd connection can be assumed. And most things are not order dependent
Re: See you soon at dconf
On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan Well, I have too many. Want some? Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. Boarding now. See you soon! Luís
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd connection can be assumed. And most things are not order dependent What about packet boundaries?
Re: CTFE Status 2
On Sunday, 30 April 2017 at 13:26:09 UTC, Stefan Koch wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: [ ... ] Big news! The first step to include debug info has been done. Yes this means you will be able to step through ctfe code while the compiler executes it. This should have been kept secret before C++ steals it and does not give credit to D. :D
Re: See you soon at dconf
On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan I'm guessing everyone will be converging on the conference hotel as the day goes on? Just arrived at schönefeld, hope to see many of you shortly :)
Re: CTFE Status 2
An article about LLVM jit: https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/
Re: DIP 1004 Preliminary Review Round 1
On Tuesday, 2 May 2017 at 18:02:15 UTC, Adam D. Ruppe wrote:
On Tuesday, 2 May 2017 at 09:03:27 UTC, deadalnix wrote:
100% in favor of the constructor behavior change in case no
constructor is in the derived class.
I agree.
So do I.
However I oppose the other part of the DIP since it's already
possible today.
class FileException : Exception
{
this(ErrorCode error_code, string file = __FILE__, uint line
= __LINE__ )
{
super("FileNotFound", file, line);
}
alias __ctor = super.__ctor;
}
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 08:23:54 UTC, Nordlöw wrote: On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd connection can be assumed. And most things are not order dependent What about packet boundaries? We send source line by line. Packets should be under 1k in most cases.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 09:04:31 UTC, John Colvin wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan I'm guessing everyone will be converging on the conference hotel as the day goes on? Just arrived at schönefeld, hope to see many of you shortly :) I expect that there are several folks here already, but I haven't seen anyone in the lobby since I ran into Walter at breakfast (though I've been hanging out in my room and only checking the lobby occasionally, so I easily could have missed someone). Most of us who are here already are probably either seeing the sites or staying in our rooms, but it could just be that most everyone is arriving today. - Jonathan M Davis
dubs: Getting into the Node scripts market
Hi,
it would be great if we can position D as replacement of Node
scripts. With the --single argument of Dub we have almost
everything we need in this scenario.
But one thing is very odd. If you want to execute the app.d
source file with dub you have to write: dub --single app.d
- You have to remember the argument --single
- You have to add the .d extension
- You do not like to have the binary created, therefore you have
to add --temp-build
- You do not like to have too much output, therefore you have to
add --quiet
- If you have application arguments you have to know to add -- at
the end followed by the application arguments.
With these limitations I cannot convince a Node developer to
switch to D.
I created a very small batch file dubs.bat which would have a
huge impact in this scenario.
You can execute the D source file with: dubs app
Application arguments are just appended: dubs app --PORT 8080
-- dubs.bat
@echo off
set _filename=%~n1
set _extension=%~x1
for /f "tokens=1,* delims= " %%a in ("%*") do set
_args_without_filename=%%b
IF "% _extension%" == ".d" (
set _sourceFile=%_filename%
) else (
set _sourceFile=%_filename%.d
)
dub run --temp-build --quiet --single %_sourceFile% --
%_args_without_filename%
-- dubs.bat
Do you think it makes sense to add this batch file and a linux
equivalent shell script to the D compilers?
Kind regards
André Pany
Re: dubs: Getting into the Node scripts market
Am 03.05.2017 um 12:54 schrieb Andre Pany:
Hi,
it would be great if we can position D as replacement of Node scripts.
With the --single argument of Dub we have almost everything we need in
this scenario.
But one thing is very odd. If you want to execute the app.d source file
with dub you have to write: dub --single app.d
- You have to remember the argument --single
- You have to add the .d extension
- You do not like to have the binary created, therefore you have to add
--temp-build
- You do not like to have too much output, therefore you have to add
--quiet
- If you have application arguments you have to know to add -- at the
end followed by the application arguments.
With these limitations I cannot convince a Node developer to switch to D.
I created a very small batch file dubs.bat which would have a huge
impact in this scenario.
You can execute the D source file with: dubs app
Application arguments are just appended: dubs app --PORT 8080
-- dubs.bat
@echo off
set _filename=%~n1
set _extension=%~x1
for /f "tokens=1,* delims= " %%a in ("%*") do set
_args_without_filename=%%b
IF "% _extension%" == ".d" (
set _sourceFile=%_filename%
) else (
set _sourceFile=%_filename%.d
)
dub run --temp-build --quiet --single %_sourceFile% --
%_args_without_filename%
-- dubs.bat
Do you think it makes sense to add this batch file and a linux
equivalent shell script to the D compilers?
Kind regards
André Pany
Actually there is a special syntax that is also used for shebang style
scripts: `dub app.d arg1 arg2` is equivalent to `dub --quiet
--temp-build --single app.d -- arg1 arg2`. It seems like the command
line help wasn't really updated to reflect that, though.
The only catch is that the .d extension is still required to make it
possible to tell a script file name apart from a regular command.
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 04:22:00 UTC, Stefan Koch wrote: [...] I think any ordering should be done explicitly at the debugging protocol level. for example when sending sourceline messages the order is given by the line number and ordering can be done by the application. It's the same for breakpoint setting or for breakpoint trigger notification. Why? If I were to write a client for the debugging protocol, I wouldn't want to write protocol ordering logic (and essentially reimplement part of tcp). I would want to react to protocol messages as they arrive. As for lost packages, we want to respond intelligently as well. The only way I know of to respond intelligently to lost packages using udp - if you care about the information in them (which we do in this use case) - is to implement a retransmit mechanism; i.e. you would be reimplementing another part of tcp. And maybe reduce the amount of data in the package, to make arrival of future packages more likely. You assume a causation between udp datagram size and delivery probability, which - however likely - is an implementation detail.
Re: dubs: Getting into the Node scripts market
On 03/05/2017 1:13 PM, Sönke Ludwig wrote:
Am 03.05.2017 um 12:54 schrieb Andre Pany:
Hi,
it would be great if we can position D as replacement of Node scripts.
With the --single argument of Dub we have almost everything we need in
this scenario.
But one thing is very odd. If you want to execute the app.d source file
with dub you have to write: dub --single app.d
- You have to remember the argument --single
- You have to add the .d extension
- You do not like to have the binary created, therefore you have to add
--temp-build
- You do not like to have too much output, therefore you have to add
--quiet
- If you have application arguments you have to know to add -- at the
end followed by the application arguments.
With these limitations I cannot convince a Node developer to switch to D.
I created a very small batch file dubs.bat which would have a huge
impact in this scenario.
You can execute the D source file with: dubs app
Application arguments are just appended: dubs app --PORT 8080
-- dubs.bat
@echo off
set _filename=%~n1
set _extension=%~x1
for /f "tokens=1,* delims= " %%a in ("%*") do set
_args_without_filename=%%b
IF "% _extension%" == ".d" (
set _sourceFile=%_filename%
) else (
set _sourceFile=%_filename%.d
)
dub run --temp-build --quiet --single %_sourceFile% --
%_args_without_filename%
-- dubs.bat
Do you think it makes sense to add this batch file and a linux
equivalent shell script to the D compilers?
Kind regards
André Pany
Actually there is a special syntax that is also used for shebang style
scripts: `dub app.d arg1 arg2` is equivalent to `dub --quiet
--temp-build --single app.d -- arg1 arg2`. It seems like the command
line help wasn't really updated to reflect that, though.
The only catch is that the .d extension is still required to make it
possible to tell a script file name apart from a regular command.
Well you could look for the normal command, if not found, try isFile
with the extension if needed.
Just a thought.
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: For the typical usecase a lossless orderd connection can be assumed. - udp is not connection oriented, i.e. there is no connection - udp is not lossless and pretending it is means setting yourself up for a headache down the road - udp datagrams are not guaranteed to arrive in the order they were sent and pretending they do is also setting yourself up for a headache down the road What you've described so far is a classic, textbook use case of tcp.
Re: CTFE Status 2
On Wednesday, 3 May 2017 at 07:35:56 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:10:22 UTC, Adrian Matoga wrote: So you're going to reinvent TCP in your debugging protocol? No. there is no need for a full blown recovery mechanism. For the typical usecase a lossless orderd connection can be assumed. And most things are not order dependent The debugger isn't a massive, real-time system that needs to service thousands of clients and squeeze as much performance out of the network as possible. The overhead incurred by TCP is essentially not worth considering for something that's going to be run over localhost 90%, and service just the one client. Reinventing the wheel adds a far bigger overhead: Maintaining your new protocol. TCP implementations are readily available. They're well maintained, well documented, and are essentially guaranteed to work across platforms. Implementing a new protocol just adds an extra point of breakage for little to no gain. It also incurs the cost of the associated development time, and - down the line - any time spent fixing or iterating. Not to mention that tests need to be written, documentation needs to be put in place. A classic case of premature optimization.
Re: DIP 1004 Preliminary Review Round 1
On Wednesday, 3 May 2017 at 09:13:54 UTC, Daniel N wrote:
However I oppose the other part of the DIP since it's already
possible today.
class FileException : Exception
{
this(ErrorCode error_code, string file = __FILE__, uint
line = __LINE__ )
{
super("FileNotFound", file, line);
}
alias __ctor = super.__ctor;
}
I was excited for a second, but that doesn't actually compile.
Error: alias test.FileException.__ctor is not a constructor;
identifiers starting with __ are reserved for the implementation
Re: DIP 1004 Preliminary Review Round 1
On Wednesday, 3 May 2017 at 12:46:19 UTC, Andrej Mitrovic wrote:
On Wednesday, 3 May 2017 at 09:13:54 UTC, Daniel N wrote:
However I oppose the other part of the DIP since it's already
possible today.
class FileException : Exception
{
this(ErrorCode error_code, string file = __FILE__, uint
line = __LINE__ )
{
super("FileNotFound", file, line);
}
alias __ctor = super.__ctor;
}
I was excited for a second, but that doesn't actually compile.
Error: alias test.FileException.__ctor is not a constructor;
identifiers starting with __ are reserved for the implementation
I used this technique many times with many different compiler
versions...
The trick is that your child class need to have defined at least
1 constructor before the alias.
This should work:
this() {}
alias __ctor = super.__ctor;
This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}
Re: [OT] Algorithm question
On Tuesday, 2 May 2017 at 23:09:54 UTC, MysticZach wrote:
On Tuesday, 2 May 2017 at 21:00:36 UTC, Timon Gehr wrote:
On 02.05.2017 22:42, MysticZach wrote:
On Tuesday, 2 May 2017 at 13:44:03 UTC, MysticZach wrote:
for (;;) {
if (P(a[i]))
return i;
++count;
if (count == length)
return -1;
i += hop;
if (i < length)
continue;
if (i < skipLength)
i += hop;
(I guess this should be 'while'.)
skipLength is determined modulo hop, thus it can't be more than
one hop away.
Actually, I did botch the implementation. The hopping interval
must be based on the prime rather than on n. But you could still
short circuit the while loop, I think. `if (prime - n > hop) {
skipLength = n + ((prime - n) % hop); }
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 09:04:31 UTC, John Colvin wrote: I'm guessing everyone will be converging on the conference hotel as the day goes on? I imagine I'll wander by there. I'm not staying there, but it is a quick walk to my accommodation. I land at 20.45 though, so I hope it's still going around 22.30-23.00.
Re: CTFE Status 2
On Sunday, 30 April 2017 at 19:52:27 UTC, H. S. Teoh wrote: On Sun, Apr 30, 2017 at 01:26:09PM +, Stefan Koch via Digitalmars-d wrote: On Thursday, 16 February 2017 at 21:05:51 UTC, Stefan Koch wrote: > [ ... ] Big news! The first step to include debug info has been done. Yes this means you will be able to step through ctfe code while the compiler executes it. Wow! Will that be accessible to users in the end? That could be a totally awesome way of debugging CTFE code! I used to think the same, but with each new line of code I write that is to be executed in CT, I become more convinced that there's no need to expose such debugging interface to the end user. Why? Because the end user expects that CTFE either gives exactly the same results as run-time execution or that it stops with an explicit error message on something that is not designed to be executed in CT. Any other problem found during CTFE execution must be 100% reproducible in run time or it's an ICE. Any CTFE debugging should be only for compiler maintainers, and the user shouldn't worry that CTFE could mess up something.
Re: dubs: Getting into the Node scripts market
On Wednesday, 3 May 2017 at 12:16:30 UTC, rikki cattermole wrote: Actually there is a special syntax that is also used for shebang style scripts: `dub app.d arg1 arg2` is equivalent to `dub --quiet --temp-build --single app.d -- arg1 arg2`. It seems like the command line help wasn't really updated to reflect that, though. The only catch is that the .d extension is still required to make it possible to tell a script file name apart from a regular command. Well you could look for the normal command, if not found, try isFile with the extension if needed. Just a thought. Fantastic. The isFile enhancement is a minor thing but it would be great if this also could be added. Thanks:) Kind regards André
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 07:29:27 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:45:05 UTC, Bastiaan Veelo wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. Likewise! I am at the airport as I type. Bastiaan. are you in Berlin already ? I am going to arrive near 19:00. Anyone up for having a pre-conf drink ? I am at Heimathafen right now, watching the Sociomantic people prepare. I am up for a drink, but I stay at Erlanger Hof, which is in the other direction from Heimathafen compared to Ibis. Anyone in my neighbourhood?
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 07:42:51 UTC, Luís Marques wrote: Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. I have asked Shai Tayeb here, Event Manager, and he will bring one tomorrow.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 13:14:01 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 07:29:27 UTC, Stefan Koch wrote: On Wednesday, 3 May 2017 at 06:45:05 UTC, Bastiaan Veelo wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. Likewise! I am at the airport as I type. Bastiaan. are you in Berlin already ? I am going to arrive near 19:00. Anyone up for having a pre-conf drink ? I am at Heimathafen right now, watching the Sociomantic people prepare. I am up for a drink, but I stay at Erlanger Hof, which is in the other direction from Heimathafen compared to Ibis. Anyone in my neighbourhood? I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 07:42:51 UTC, Luís Marques wrote: On Tuesday, 2 May 2017 at 20:19:02 UTC, Stefan Koch wrote: Hi, I am very happy to see you soon at dconf. And I apologize in advance for my nearly slideless talk. Hope this time there is dmd on the machine! Cheers Stefan Well, I have too many. Want some? Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. I've got one with me. I'm not staying in Ibis, but it's close to my hotel. I shall get there at about 9pm. See you!
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: (first of which I'm having now ;). Where were you thinking to meet? If there's beer where you are, I can get to you. 20 min.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 13:50:53 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: (first of which I'm having now ;). Where were you thinking to meet? If there's beer where you are, I can get to you. 20 min. I'm also staying at the Beethoven. First I've got to finish something up, then I'll join you as well.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 13:28:50 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 07:42:51 UTC, Luís Marques wrote: Can anyone get me a phillips screwdriver? Seriously. I'll be at the official hotel or you can lend me one tomorrow morning at the conference. I have asked Shai Tayeb here, Event Manager, and he will bring one tomorrow. Cool. Thanks!
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one. Sorry I lost cellular connection. Steve an I took the U7 to Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is enough, the cheap ticket.
Re: DIP 1004 Preliminary Review Round 1
On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
The trick is that your child class need to have defined at
least 1 constructor before the alias.
This should work:
this() {}
alias __ctor = super.__ctor;
This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}
I see. It does look like an accidental feature (as in, that it
could break in the future).
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 15:05:02 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one. Sorry I lost cellular connection. Steve an I took the U7 to Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is enough, the cheap ticket. Ah great, I'll go there as well.
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 15:05:02 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one. Sorry I lost cellular connection. Steve an I took the U7 to Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is enough, the cheap ticket. I might be wrong, but it's 6 stops for the Bus/Tram drive, and only three for the U/S Bahn drive: Einzelfahrausweise für Kurzstrecken gelten im Tarifbereich Berlin (AB,BC,ABC) für bis zu drei Stationen mit der S-Bahn, U-Bahn oder bis zu sechs Stationen mit Bus oder Straßenbahn. http://www.s-bahn-berlin.de/aboundtickets/kurzstrecke.htm
Re: See you soon at dconf
On 5/3/17 5:42 PM, Nemanja Boric wrote: On Wednesday, 3 May 2017 at 15:05:02 UTC, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one. Sorry I lost cellular connection. Steve an I took the U7 to Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is enough, the cheap ticket. I might be wrong, but it's 6 stops for the Bus/Tram drive, and only three for the U/S Bahn drive: Einzelfahrausweise für Kurzstrecken gelten im Tarifbereich Berlin (AB,BC,ABC) für bis zu drei Stationen mit der S-Bahn, U-Bahn oder bis zu sechs Stationen mit Bus oder Straßenbahn. http://www.s-bahn-berlin.de/aboundtickets/kurzstrecke.htm Not sure how many stops. It was Grenzalee stop, I think 5 or 6 stops from Hermannplatz? -Steve
Re: See you soon at dconf
On Wednesday, 3 May 2017 at 15:42:18 UTC, Nemanja Boric wrote: I might be wrong, but it's 6 stops for the Bus/Tram drive, and only three for the U/S Bahn drive: Einzelfahrausweise für Kurzstrecken gelten im Tarifbereich Berlin (AB,BC,ABC) für bis zu drei Stationen mit der S-Bahn, U-Bahn oder bis zu sechs Stationen mit Bus oder Straßenbahn. http://www.s-bahn-berlin.de/aboundtickets/kurzstrecke.htm You're right, looks like I have been reading too quickly.
Re: DIP 1004 Preliminary Review Round 1
On 05/03/2017 05:09 PM, Andrej Mitrovic wrote:
On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
The trick is that your child class need to have defined at least 1
constructor before the alias.
This should work:
this() {}
alias __ctor = super.__ctor;
This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}
I see. It does look like an accidental feature (as in, that it could
break in the future).
You could switch to:
```
this(A...)(auto ref A a)
{
import std.functional;
super(forward!a);
}
```
but that doesn't work with all the parameter storage classes.
lazy is no longer lazy for example.
--
Mike Wey
Re: The D ecosystem in Debian with free-as-in-freedom DMD
Am Wed, 03 May 2017 01:02:38 + schrieb Moritz Maxeiner : > On Tuesday, 2 May 2017 at 23:27:28 UTC, Marco Leise wrote: > > Am Tue, 02 May 2017 20:53:50 + > > schrieb Moritz Maxeiner : > > > >> On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote: > >> > > >> > I see what you're doing there, but your last point is > >> > wishful thinking. Dynamically linked binaries can share > >> > megabytes of code. Even Phobos - although heavily templated > >> > - has proven to be very amenable to sharing. For example, a > >> > "Hello world!" program using `writeln()` has these sizes > >> > when compiled with `dmd -O -release -inline`: > >> > > >> > static Phobos2 : 806968 bytes > >> > dynamic Phobos2 : 18552 bytes > >> > > >> > That's about 770 KiB to share or 97.7% of its total size! > >> > Awesome! > >> > >> Is all of that active code, or is some of that (statically > >> knowable) never getting executed (as in could've been removed > >> at compile/link time)? > > > > I guess David gave you the answer. So it's just 95.4% of its > > total size. :p > > Under the assumption that ldc2 produces no dead code in the > output; is that a reasonable assumption (I'm not sure)? > > > By the way, is the fully dynamic linking version possible with > > ldc2 now as well ? > > I did have a modified ebuild to try that out a while back and it > seemed to work fine in my limited testing scope. Since I quite > often change installed d compilers and don't want my programs > (like tilix) to stop working (or have old d compiler versions > being kept installed *just* because some programs were built with > them), I generally link against phobos statically, anyway, so I > my tests weren't exhaustive. The cmake flag to to use in the > ebuild would be BUILD_SHARED [1]. > > [1] > https://github.com/ldc-developers/ldc/blob/v1.2.0/CMakeLists.txt#L522 I remember seeing this line and thinking "aww .. no way to build both versions?". I.e. enable the "static-libs" USE flag to _also_ build static libraries accompanying the shared ones. I'll create an issue asking about that. -- Marco
Re: DIP 1004 Preliminary Review Round 1
On Wednesday, 3 May 2017 at 15:09:03 UTC, Andrej Mitrovic wrote:
On Wednesday, 3 May 2017 at 12:58:17 UTC, Daniel N wrote:
The trick is that your child class need to have defined at
least 1 constructor before the alias.
This should work:
this() {}
alias __ctor = super.__ctor;
This will give the error message you saw:
alias __ctor = super.__ctor;
this() {}
I see. It does look like an accidental feature (as in, that it
could break in the future).
Well, I was thinking one could put it in a mixin, then it would
be officially supported and user-facing code wouldn't have to use
__symbols. One benefit with using __ctor is that the syntax
doesn't clash with future "alias this" improvements.
Re: multiple `alias this` suggestion
On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote: On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote: Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here. https://forum.dlang.org/post/hvdmtvjvccbkmkjzu...@forum.dlang.org OK, you have a point. I realise syntax is the least important part of this proposal, but "alias this" is the only alias that still is backwards... If you do write a DIP at least consider this: alias this : entity, render;
Re: multiple `alias this` suggestion
On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote: On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote: On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote: Even better, with alias for embedded aliased-to-this structs made working usefully, name management can be done before embedding the features, by having another layer of embedding as in my earlier example here. https://forum.dlang.org/post/hvdmtvjvccbkmkjzu...@forum.dlang.org OK, you have a point. I realise syntax is the least important part of this proposal, but "alias this" is the only alias that still is backwards... If you do write a DIP at least consider this: alias this : entity, render; PS One could of course eat the cake and keep it still, at the cost of additional complexity. Distributed and prioritized: alias this : a_prio1, a_prio2, a_prio3; alias this : b_prio1, b_prio2; any a* could clash with any b* but a:s wont clash with their own kind since they are internally prioritised the same goes for b:s.
Re: See you soon at dconf
On 5/3/17 5:05 PM, Bastiaan Veelo wrote: On Wednesday, 3 May 2017 at 14:38:41 UTC, Rene Zwanenburg wrote: On Wednesday, 3 May 2017 at 13:36:45 UTC, Steven Schveighoffer wrote: I am at the Ludwig van Beethoven hotel. Just had a 2 hour nap, couldn't sleep on the plane. So a few beers will do me well (first of which I'm having now ;). Where were you thinking to meet? -Steve Are you still at the hotel bar? I just went down there but saw no-one. Sorry I lost cellular connection. Steve an I took the U7 to Ibis, 6 stops. We are 9 chaps atm. "Kurzstreckefahrkarte" is enough, the cheap ticket. Looking this up on the berlin.de web site it says: "A short distance ticket (Kurzstrecke) costs 1.70 Euros, reduced 1.30 Euros and and is valid for three stops with S- and U-Bahn. Changing trains is allowed. The ticket is also valid for six stops in buses and trams, but only if not changing vehicles." So maybe short ticket isn't good enough, because granzalee was 4 stops. Just don't want anyone to get into trouble... -Steve
Re: DConf 2017 Berlin - Streaming ?
On Saturday, 29 April 2017 at 20:46:06 UTC, Andrej Mitrovic wrote: The last bit of news I've received is they will be streamed on youtube this time. Is there any update on this? (Preferably in the form of a URL)
Re: DConf 2017 Berlin - Streaming ?
On Thursday, 4 May 2017 at 06:35:39 UTC, Brian Schott wrote: On Saturday, 29 April 2017 at 20:46:06 UTC, Andrej Mitrovic wrote: The last bit of news I've received is they will be streamed on youtube this time. Is there any update on this? (Preferably in the form of a URL) Yeah, hopefully there's a post in the announce forum coming, given the first talk is supposed to start in an hour (no idea if there is going to be a post, just hoping).
