On 10.09.2013 22:43, FrogLegs wrote:
Does VisualD work with VS2013?
I just adapted the installer script and tried it with VS2013 RC. Seems
to work fine from a first glance, it will be available with the next
release.
On 10.09.2013 22:03, Tove wrote:
On Tuesday, 10 September 2013 at 18:10:33 UTC, Rainer Schuetze wrote:
Thanks for pointing these out. The README didn't receive a lot of
attention lately, most of the documentation and news is on the web
site. I agree, with it being displayed on the front
On 2013-09-10 20:10, Rainer Schuetze wrote:
Thanks for pointing these out. The README didn't receive a lot of
attention lately, most of the documentation and news is on the web site.
I agree, with it being displayed on the front github page it should be
updated.
Rename it to README.md and you
Please participate.
http://forum.dlang.org/thread/jsnhlcbulwyjuqcqo...@forum.dlang.org
Am 10.09.2013 23:04, schrieb Nick Sabalausky:
On Tue, 10 Sep 2013 23:01:12 +0200
Brad Anderson e...@gnuk.net 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).
Am 11.09.2013 00:30, schrieb Brad Anderson:
On Tuesday, 10 September 2013 at 22:06:28 UTC, luminousone wrote:
And license acknowledgement, this is much more important with
source libraries then it is with say apt on Ubuntu. Accidentally
polluting a bsd project or a closed source project with
On 11.09.2013 00:39, Martin Nowak wrote:
On 09/07/2013 02:47 PM, Benjamin Thaut wrote:
If you compile lib1 into a static library and then copmpile lib2 into a
DLL which statically links against lib1 both symbols lib1Func and
lib2Func will be exported from the dll because lib1Func will get
Am 11.09.2013 00:06, schrieb luminousone:
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is known to be unchanged without need for updates(such
as most wrappers).
Agreed. Maybe some other knowledge, such
On 10.09.2013 20:03, Andrei Alexandrescu wrote:
On 9/10/13 9:31 AM, Brad Anderson wrote:
On Saturday, 7 September 2013 at 19:05:03 UTC, 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
Am 11.09.2013 01:17, schrieb Peter Williams:
On 11/09/13 06:48, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in
Am 11.09.2013 02:18, schrieb Martin Nowak:
On 09/10/2013 10:48 PM, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence
Am 11.09.2013 03:49, schrieb Nathan M. Swan:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which
On Tuesday, 10 September 2013 at 21:25:41 UTC, Walter Bright
wrote:
On 9/9/2013 11:35 AM, Russel Winder wrote:
C++11 has revitalized C++ in ways that are only just showing
themselves.
That's true.
This is a threat to D gaining traction.
I'm less sure about that. I think it presents an
Am 11.09.2013 06:06, schrieb Jason den Dulk:
On Tuesday, 10 September 2013 at 20:48:58 UTC, Andrei Alexandrescu wrote:
We're considering making dub the official package manager for D. What
do you all think?
I think it is a good idea. Having a broad library available for
developers to use is
On 2013-09-10 16:38, Dicebot wrote:
This is why mixing ABI and mangling in one entity is bad. And why
overloading extern(C) functions is compile-time error in C++.
There's a GCC (Clang) extension that enables support function
overloading in C. I guess it's a bit overkill to support in D.
On Tuesday, 10 September 2013 at 14:38:56 UTC, Dicebot wrote:
On Tuesday, 10 September 2013 at 14:07:18 UTC, Luís Marques
wrote:
I just realized I wasn't clear -- it calls the (wrong)
overloaded function:
extern(C) void foo(int);
extern(C) void foo() { writeln(yes, this is called); }
On 2013-09-10 23:53, Nick Sabalausky wrote:
Europe has good taste in music. Example: Almost anytime I watch Top
Gear, I notice them using great songs that I recognize from my own
collection that you almost never hear played here in the US. Stuff
like Prodigy or Crystal Method, for example.
On Sep 10, 2013 10:56 PM, Nick Sabalausky
seewebsitetocontac...@semitwist.com wrote:
On Tue, 10 Sep 2013 23:23:48 +0200
Paulo Pinto pj...@progtools.org wrote:
Really?!? It is quite popular in Europe.
Europe has good taste in music. Example: Almost anytime I watch Top
Gear, I notice them
On Wednesday, 11 September 2013 at 08:32:43 UTC, Jacob Carlborg
wrote:
On 2013-09-10 23:53, Nick Sabalausky wrote:
Europe has good taste in music. Example: Almost anytime I
watch Top
Gear, I notice them using great songs that I recognize from my
own
collection that you almost never hear
On 2013-09-11 08:28, Sönke Ludwig wrote:
Agreed. Maybe some other knowledge, such as how many other (active)
packages depend on it, or how often it is still downloaded, can help to
get a robust automatic measure.
How many total downloads would be nice as well. In RubyGems there are
often
On Tuesday, 10 September 2013 at 20:35:00 UTC, Nick Sabalausky
wrote:
On Tue, 10 Sep 2013 19:26:48 +0100
Russel Winder rus...@winder.org.uk wrote:
Perhaps I am late to the party, but clearly all the meta-data
associated with packages managed by Dub are Dub Records. Groan.
Heh, took me awhile
On 2013-09-11 08:56, Sönke Ludwig wrote:
Having an integrated CI solution would not only solve 4, but would also
allow things such as automatic online documentation for each package.
But for so many packages this will of course be difficult in terms of
available hardware power and security
On 2013-09-11 06:06, Jason den Dulk wrote:
1) Must be legal.
What exactly does this mean in this context?
4) Must compile and run with a reasonably recent version of the
official compiler.
I think it's better to specify a compiler and version in the package file.
--
/Jacob Carlborg
On 09/10/2013 03:45 PM, Dicebot wrote:
done and done (the design of my logger is based on what I distilled from
the old discussion)
Thanks! You will be next after Brian then (pardon me for wanting
std.d.lexer so much :P)
No problem, it might be good though to get so bashing beforehand to
On Wednesday, 11 September 2013 at 08:46:12 UTC, deadalnix wrote:
On Tuesday, 10 September 2013 at 20:35:00 UTC, Nick Sabalausky
wrote:
On Tue, 10 Sep 2013 19:26:48 +0100
Russel Winder rus...@winder.org.uk wrote:
Perhaps I am late to the party, but clearly all the meta-data
associated with
On 2013-09-10 22:48, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in the
future of the project.
We're considering
On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig
wrote:
Am 11.09.2013 00:06, schrieb luminousone:
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in
cases
where it is known to be unchanged without need for
On Monday, 9 September 2013 at 11:14:47 UTC, Mike Parker wrote:
I'm experimenting with some Linux stuff right now and am
currently working on something using epoll. But I've run into
an issue where dmd just doesn't see anything in
core.sys.linux.epoll. As a workaround, I've implemented my own
On Wednesday, 11 September 2013 at 08:51:30 UTC, Jacob Carlborg
wrote:
On 2013-09-11 06:06, Jason den Dulk wrote:
1) Must be legal.
What exactly does this mean in this context?
You cannot include anything you do not have the legal right to
include. I.E no copyright violations, no child
Am 11.09.2013 11:57, schrieb Jacob Carlborg:
On 2013-09-10 22:48, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in
On 11-9-2013 12:28, ilya-stromberg wrote:
On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig wrote:
Am 11.09.2013 00:06, schrieb luminousone:
Projects that haven't had an update for an excessive amount of
time should likely be hidden but still available except in cases
where it is
On Wednesday, 11 September 2013 at 11:31:11 UTC, Faux Amis wrote:
On 11-9-2013 12:28, ilya-stromberg wrote:
On Wednesday, 11 September 2013 at 06:28:30 UTC, Sönke Ludwig
wrote:
Am 11.09.2013 00:06, schrieb luminousone:
Projects that haven't had an update for an excessive amount
of
time should
On Wed, 11 Sep 2013 10:46:11 +0200
deadalnix deadal...@gmail.com wrote:
KAMOULOX !
Seriously, this thread looks like a juxtaposition of random words
to me. Can someone translate ?
Hopefully I can explain without making things more confusing...
Perhaps I am late to the party, but
On 9/11/2013 7:58 PM, goughy wrote:
Odd. I opened a pull request that fixed a case issue with the
'Linux'/'linux' version identifier in that module that I thought was
accepted and merged. Sounds like the same symptom.
https://github.com/D-Programming-Language/druntime/pull/489
Yes, it's
On 2013-09-11 12:28, ilya-stromberg wrote:
Simple idea: try to build the package via current DMD. If compilation
false then the package too old (or we have DMD regression). So, it would
be nice to have package autotester like for DMD/Phobos repositories.
Why should you be forced to constantly
On Wednesday, 11 September 2013 at 12:26:05 UTC, Jacob Carlborg
wrote:
On 2013-09-11 12:28, ilya-stromberg wrote:
Simple idea: try to build the package via current DMD. If
compilation
false then the package too old (or we have DMD regression).
So, it would
be nice to have package autotester
On 2013-09-11 13:03, Jason den Dulk wrote:
Yes, but if the latest version the package is known to work with is more
than 3 years old, it would be desirable to have that kept away from the
up to date packages.
Three years is a bit different. I'm thinking more that it need to
support multiple
On Wednesday, 11 September 2013 at 09:57:48 UTC, Jacob Carlborg
wrote:
The biggest issue I have with dub is that it's really doesn't
install packages, at least not in the traditional sense. I
cannot just run dub install foo and then foo --help. It
will only clone the repository, not install,
Am 11.09.2013 14:00, schrieb Nick Sabalausky:
There's the DUB package manager for D:
https://github.com/rejectedsoftware/dub
And apparently (although I guess I never noticed this) the meta-data
for each package is called a record (a common, albeit old, term for
a database entry).
Slight
On Wed, 11 Sep 2013 14:56:42 +0200
Sönke Ludwig slud...@outerproduct.org wrote:
Regarding the dub music genre, it has to be said that although it is
the root for dubstep and in turn ... brostep, it's usually not really
comparable result-wise
Oh right, and I certainly agree. A music genere
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.
On 2013-09-11 14:00, Nick Sabalausky wrote:
There's a relatively recent derivative of the dub music genre called
dubstep https://en.wikipedia.org/wiki/Dubstep.
So if I add DStep as a package in dub we get: dubstep :)
--
/Jacob Carlborg
On Wed, 11 Sep 2013 21:10:46 +0800
Lionello Lunesu lione...@lunesu.remove.com wrote:
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
Am 11.09.2013 15:25, schrieb Jacob Carlborg:
On 2013-09-11 14:00, Nick Sabalausky wrote:
There's a relatively recent derivative of the dub music genre called
dubstep https://en.wikipedia.org/wiki/Dubstep.
So if I add DStep as a package in dub we get: dubstep :)
Oh noes! There it happened
On Wednesday, 11 September 2013 at 06:58:03 UTC, PauloPinto wrote:
I think it is better to sell D's capabilities in terms of
systems programming scenarios.
Your 1-4 points are already covered by existing languages for
traditional line of business applications, specially given the
fact that
On Wednesday, 11 September 2013 at 08:26:02 UTC, deadalnix wrote:
I think this is another form of the unclear qualifier binding
problem.
Qualifier bind to symbol : mangling.
Qualifier bind to type : calling convention.
Yeah, giving tool to differ those can be an elegant way out of
this
On Wednesday, 11 September 2013 at 13:39:02 UTC, Nick Sabalausky
wrote:
On Wed, 11 Sep 2013 21:10:46 +0800
Lionello Lunesu lione...@lunesu.remove.com wrote:
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
On Tuesday, 3 September 2013 at 07:02:33 UTC, Rainer Schuetze
wrote:
To initialize data with a pointer into another DLL, you cannot
do that with a direct relocation, you have to run some code to
copy the value from the import table into the data.
Well, yes, static initialization is
On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg
wrote:
I'm thinking this type of package manager should be a
development tool as well. But there are a lot of development
tools that are executables and not just libraries. Think of
your documentation generator. Without having
On Sunday, 8 September 2013 at 23:52:46 UTC, Stewart Gordon wrote:
The problem is that null no longer works. How to fix?
I'd say, strong handles shouldn't act as pointers (and shouldn't
contain pointers), so null shouldn't work, I use HANDLE(0)
instead of null. Use void* for maximum
std.d.lexer is standard module for lexing D code, written by
Brian Schott
Input
Code: https://github.com/Hackerpilot/phobos/tree/master/std/d
Documentation:
http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html
Initial discussion:
On 2013-09-11 13:30, Sönke Ludwig wrote:
Right now it is a pure development tool. It would be very nice to have
end user installs somehow supported (either by directly installing
application packages or by generating OS specific packages such as DEB
or RPM). But since this enters a highly
On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by
Brian Schott
I remember reading there were some interesting hash-advances in
dmd recently.
http://forum.dlang.org/thread/kq7ov0$2o8n$1...@digitalmars.com?page=1
On Wednesday, 11 September 2013 at 14:11:11 UTC, John Colvin
wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
YAML is nice but can be surprisingly tricky to write by hand
sometimes (especially for people not used to significant
whitespace).
Here's the discussion about
Am 11.09.2013 17:01, schrieb Jacob Carlborg:
Why not _make_ a tag? But uploading zipped packages (or better
specifying an external link) could be added as an alternative without
much effort.
I'm not referring to uploading zip packages. Say I have ten tags but I
only want dub to know about five
On Wednesday, 11 September 2013 at 06:31:50 UTC, Rainer Schuetze
wrote:
On 10.09.2013 20:03, Andrei Alexandrescu wrote:
On 9/10/13 9:31 AM, Brad Anderson wrote:
On Saturday, 7 September 2013 at 19:05:03 UTC, Walter Bright
wrote:
Recent threads here have made it pretty clear that VisualD
is
On Wednesday, 11 September 2013 at 06:12:41 UTC, Sönke Ludwig
wrote:
Am 10.09.2013 23:04, schrieb Nick Sabalausky:
On Tue, 10 Sep 2013 23:01:12 +0200
Brad Anderson e...@gnuk.net 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
On Wednesday, 11 September 2013 at 15:01:37 UTC, Jacob Carlborg
wrote:
On 2013-09-11 13:30, Sönke Ludwig wrote:
Right now it is a pure development tool. It would be very nice
to have
end user installs somehow supported (either by directly
installing
application packages or by generating OS
On 10/09/13 22:48, Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and things are
going well. In particular Sönke has been very active about maintaining and
improving it, which brings further confidence in the future of the project.
We're considering
On Thu, Sep 05, 2013 at 10:14:01AM -0700, Timothee Cour wrote:
Currently D will compile templated code that is syntactically correct
but semantically always incorrect (ie regardless of template
parameters), eg the following:
regardless of T, b is not in scope and hence this template cannot be
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
YAML is just plain evil. It doesn't ignore whitespace.
- Jonathan M Davis
Am 11.09.2013 20:04, schrieb H. S. Teoh:
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
YAML is just plain evil. It doesn't ignore whitespace.
[...]
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
YAML is just plain evil. It doesn't ignore whitespace.
[...]
It's funny. I used to think Python is
On Monday, 9 September 2013 at 14:21:17 UTC, Dicebot wrote:
While Jacob is working on improving std.serialization, there is
some time to do more reviews. Review manager role does not seem
to be very stressing, so I can step up as one for any of the
projects currently in queue as soon as their
On 9/11/13, Kagamin s...@here.lot wrote:
I'd say, strong handles shouldn't act as pointers (and shouldn't
contain pointers), so null shouldn't work.
NULL is already used in a ton of WinAPI C/C++ code and MSDN
documentation, it would be a major pain in the ass to have to use e.g.
HWND(0)
On 9/11/2013 11:43 AM, Johannes Pfau wrote:
But to be honest I'm not sure how important this really is. I think it
should help for more responsive IDEs but maybe parsing is not a
bottleneck at all?
It is important, and I'm glad you brought it up. The LexerConfig can provide a
spot to put a
Walter Bright wrote:
Parsing D requires arbitrary lookahead.
Why---and since which version?
-manfred
On Tuesday, September 10, 2013 13:48:58 Andrei Alexandrescu wrote:
We've been experimenting with http://code.dlang.org for a while and
things are going well. In particular Sönke has been very active about
maintaining and improving it, which brings further confidence in the
future of the
On 9/11/2013 11:45 AM, qznc wrote:
On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by Brian Schott
Documentation:
http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html
The documentation for Token twice
Am Wed, 11 Sep 2013 17:01:58 +0200
schrieb Dicebot pub...@dicebot.lv:
std.d.lexer is standard module for lexing D code, written by
Brian Schott
Question / Minor issue:
As we already have a range based interface I'd love to have partial
lexing / parsing, especially for IDEs.
Say I have
On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
YAML is just plain evil. It doesn't
On 9/11/2013 8:01 AM, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by Brian Schott
Thank you, Brian! This is important work.
Not a thorough review, just some notes from reading the doc file:
1. I don't like the _ suffix for keywords. Just call it kwimport or
On Wednesday, September 11, 2013 20:12:40 Paulo Pinto wrote:
Am 11.09.2013 20:04, schrieb H. S. Teoh:
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than JSON and is very widely known.
The choice of ending token names with underscores was made
according to the Phobos style guide.
http://dlang.org/dstyle.html
On 9/11/2013 12:10 PM, Brian Schott wrote:
The choice of ending token names with underscores was made according to the
Phobos style guide.
http://dlang.org/dstyle.html
I didn't realize that was in the style guide. I guess I can't complain about it,
then :-)
On Wednesday, September 11, 2013 11:49:44 Walter Bright wrote:
1. I don't like the _ suffix for keywords. Just call it kwimport or
something like that.
Appending _ is what we do in Phobos when we need to use a keyword, and it's
even called out in the style guide: http://dlang.org/dstyle.html
On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by
Brian Schott
Documentation:
http://hackerpilot.github.io/experimental/std_lexer/phobos/lexer.html
The documentation for Token twice says measured in ASCII
characters
On 9/11/2013 12:17 PM, Manfred Nowak wrote:
Walter Bright wrote:
Parsing D requires arbitrary lookahead.
Why---and since which version?
Since the very beginning.
One example is determining if something is a declaration or an expression.
On Wednesday, September 11, 2013 19:17:26 Manfred Nowak wrote:
Walter Bright wrote:
Parsing D requires arbitrary lookahead.
Why---and since which version?
IIRC, it's at least partially cause by the .. token. You have to look ahead to
figure out whether it's .. or a floating point literal.
On 2013-09-11 18:11, Sönke Ludwig wrote:
It will only look at version tags of the form vA.B.C(postfix) any reason
to hide one of those? It could be added as a feature to the registry,
but is there a compelling use case to warrant the costs?
No, that should be ok.
or, you can choose which
On 2013-09-11, 20:29, Andrej Mitrovic wrote:
On 9/11/13, Kagamin s...@here.lot wrote:
I'd say, strong handles shouldn't act as pointers (and shouldn't
contain pointers), so null shouldn't work.
NULL is already used in a ton of WinAPI C/C++ code and MSDN
documentation, it would be a major
On Wednesday, 11 September 2013 at 20:08:44 UTC, H. S. Teoh wrote:
On Wed, Sep 11, 2013 at 10:04:20PM +0200, Dicebot wrote:
On Wednesday, 11 September 2013 at 19:58:36 UTC, H. S. Teoh
wrote:
I disagree. I think it's more readable to use a consistent
prefix,
like kw... or kw_... (e.g. kw_int,
On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:
On 2013-09-11 17:09, Dicebot wrote:
Those should be provided as sources and built by dub too.
Distributing binary packages requires both package signing and
reasonable web of trust - something that is not easy to just
implement
On Wed, Sep 11, 2013 at 12:13:07PM -0700, Walter Bright wrote:
On 9/11/2013 12:10 PM, Brian Schott wrote:
The choice of ending token names with underscores was made according
to the Phobos style guide.
http://dlang.org/dstyle.html
I didn't realize that was in the style guide. I guess I
On 2013-09-11 14:29, Dicebot wrote:
Because it is current D reality. Package that do not get updated to
latest front-end version are used only if there is absolutely no other
choice. Amount of inconvenience it causes to the user of the package is
tremendous.
I don't understand the
On Wed, Sep 11, 2013 at 11:49:44AM -0700, Walter Bright wrote:
On 9/11/2013 8:01 AM, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by Brian
Schott
Thank you, Brian! This is important work.
Not a thorough review, just some notes from reading the doc file:
1. I
On Wed, Sep 11, 2013 at 10:04:20PM +0200, Dicebot wrote:
On Wednesday, 11 September 2013 at 19:58:36 UTC, H. S. Teoh wrote:
I disagree. I think it's more readable to use a consistent prefix,
like kw... or kw_... (e.g. kw_int, kw_return, etc.), so that it's
clear you're referring to token
On Wednesday, 11 September 2013 at 19:29:48 UTC, Jonathan M Davis
wrote:
On Wednesday, September 11, 2013 19:17:26 Manfred Nowak wrote:
Walter Bright wrote:
Parsing D requires arbitrary lookahead.
Why---and since which version?
IIRC, it's at least partially cause by the .. token. You have
On Wednesday, 11 September 2013 at 19:58:36 UTC, H. S. Teoh wrote:
I disagree. I think it's more readable to use a consistent
prefix, like
kw... or kw_... (e.g. kw_int, kw_return, etc.), so that it's
clear
you're referring to token types, not the actual keyword.
Not unless you want to change
On 2013-09-11 17:09, Dicebot wrote:
Those should be provided as sources and built by dub too. Distributing
binary packages requires both package signing and reasonable web of
trust - something that is not easy to just implement from scratch.
Otherwise any single malicious package may ruin
On Wednesday, 11 September 2013 at 20:05:18 UTC, Jacob Carlborg
wrote:
On 2013-09-11 14:29, Dicebot wrote:
Because it is current D reality. Package that do not get
updated to
latest front-end version are used only if there is absolutely
no other
choice. Amount of inconvenience it causes to
On 11.09.2013 20:49, Walter Bright wrote:
On 9/11/2013 8:01 AM, Dicebot wrote:
std.d.lexer is standard module for lexing D code, written by Brian Schott
Thank you, Brian! This is important work.
Not a thorough review, just some notes from reading the doc file:
1. I don't like the _ suffix
On Wed, Sep 11, 2013 at 03:17:22PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 11:04:37 H. S. Teoh wrote:
On Wed, Sep 11, 2013 at 01:24:38PM -0400, Jonathan M Davis wrote:
On Wednesday, September 11, 2013 16:11:10 John Colvin wrote:
Why not YAML? It's cleaner than
On Wednesday, September 11, 2013 15:29:33 Jonathan M Davis wrote:
On Wednesday, September 11, 2013 19:17:26 Manfred Nowak wrote:
Walter Bright wrote:
Parsing D requires arbitrary lookahead.
Why---and since which version?
IIRC, it's at least partially cause by the .. token. You have
On 2013-09-11 18:50, Brad Anderson wrote:
I have to completely disagree with you here. Where would it end? Would
it install vim for me? Install the Java VM so it could run some Java
tool? The level of effort needed to add this functionality—which would
duplicate dozens of existing package
On 2013-09-11 14:33, Dicebot wrote:
I am strongly against it. It is not a job of language package manager.
Implementing it properly will require to integrate the knowledge of
every existing packaging system among every slightly popular OS /
distro. Implement it as a hack with own package
On 2013-09-11 22:07, Dicebot wrote:
Different front-end versions are not guaranteed to be ABI compatible.
You always need to use same compiler version within one application and
using library that is not updated to latest version forces you to use
that old version in your own code too.
Yes,
On Wed, Sep 11, 2013 at 10:18:12PM +0200, Dicebot wrote:
On Wednesday, 11 September 2013 at 20:08:44 UTC, H. S. Teoh wrote:
On Wed, Sep 11, 2013 at 10:04:20PM +0200, Dicebot wrote:
On Wednesday, 11 September 2013 at 19:58:36 UTC, H. S. Teoh wrote:
I disagree. I think it's more readable to use
On Wednesday, 11 September 2013 at 20:16:52 UTC, H. S. Teoh wrote:
On Wed, Sep 11, 2013 at 10:07:02PM +0200, Jacob Carlborg wrote:
On 2013-09-11 17:09, Dicebot wrote:
Those should be provided as sources and built by dub too.
Distributing binary packages requires both package signing and
On 2013-09-11 22:15, H. S. Teoh wrote:
How would it know which compiler(s) to use to compile the packages? What
if you have multiple compilers / development environments with
incompatible ABIs?
The same way it works now.
--
/Jacob Carlborg
1 - 100 of 212 matches
Mail list logo
