On Thursday, 26 November 2015 at 09:41:38 UTC, ponce wrote:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko
wrote:
Single language, json based configuration engine is simpler
for IDE development and configuration tools. For example,
Sublime Text.This is very important to make l
On 2015-11-27 08:08, Sönke Ludwig wrote:
Actually, no! Conditionals and loops are the only constructs - switch is
a possibility, but basically nothing else. There will also never be
variables, just constants. There is a definitive limit, namely when it
becomes impossible to reason about the code
On 2015-11-26 21:03, Suliman wrote:
Why?
This is why [1]. Also, many developers here seem to have something
against Ruby, in general. Or at least they don't want a single piece of
Ruby code near D.
I contributed a build script for the OS X installer, written in Ruby.
Eventually it was con
On 2015-11-26 23:38, BLM768 wrote:
That was actually one of my first thoughts. It would be pretty, but we'd
have another dependency then. Also, Ruby doesn't embed well into other
applications
I has worked fine for me.
and if we're using another general-purpose programming
language for our co
Am 26.11.2015 um 23:47 schrieb Walter Bright:
On 11/26/2015 11:05 AM, Sönke Ludwig wrote:
But still
this thread has overall been very irritating to me (that doesn't quite
describe
it). Maybe I should better have replied immediately and anticipate
some of the
statements that followed, but I have
I see many solution here that do not require any language change.
To start, have a linter yell at the programmer when (s)he submit
a diff. Dev commit directly ? What the fuck are you doing ? Do
code review and get a linter.
Alternatively, generate a di file and hash it. You can have a bot
do
V Thu, 26 Nov 2015 22:27:06 +
CraigDillabaugh via Digitalmars-d napsáno:
> On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros
> wrote:
> > On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
> >> V Thu, 26 Nov 2015 12:43:52 +
> >> Chris via Digitalmars-d napsáno:
> >
On Thursday, 26 November 2015 at 20:56:39 UTC, Jonathan M Davis
wrote:
Yes, code can forward-reference an import. e.g. this code
compiles just fine:
void main()
{
writeln("Where's my import?");
}
import std.stdio;
Now, when the import is inside of a function, then it c
On 11/26/2015 11:05 AM, Sönke Ludwig wrote:
But still
this thread has overall been very irritating to me (that doesn't quite describe
it). Maybe I should better have replied immediately and anticipate some of the
statements that followed, but I have discussed this topic countless times and
I'm ge
On Thursday, 26 November 2015 at 20:47:18 UTC, wobbles wrote:
On Thursday, 26 November 2015 at 20:35:28 UTC, mattcoder wrote:
On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan
Koppe wrote:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig
wrote:
Thanks,
Sönke
Thank you (an
On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg
wrote:
Everyone will hate me for saying this, but in that case, just
go with Ruby (or some other similar language)
That was actually one of my first thoughts. It would be pretty,
but we'd have another dependency then. Also, Ruby doe
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
You are in a big team or working with a big code base. APIs are
being defined/modified, configuration constants are
defined/modified, structures are defin
On Thursday, 26 November 2015 at 20:56:04 UTC, Bruno Medeiros
wrote:
On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
V Thu, 26 Nov 2015 12:43:52 +
Chris via Digitalmars-d napsáno:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
[...]
TOML looks nice, _bu
On 26/11/2015 12:53, Daniel Kozak via Digitalmars-d wrote:
V Thu, 26 Nov 2015 12:43:52 +
Chris via Digitalmars-d napsáno:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
On 2015-11-25 11:17, Suliman wrote:
[...]
BTW, why was not TOML [1] chosen? I know it was discu
On Thursday, 26 November 2015 at 17:47:00 UTC, BLM768 wrote:
Then again, I don't even know whether it's possible for my code
to forward-reference an import; if not, pkg will never be null
anyway. Maybe I'll just assert it or something...
Yes, code can forward-reference an import. e.g. this cod
On 26/11/2015 12:29, Jacob Carlborg wrote:
BTW, why was not TOML [1] chosen? I know it was discussed but I can't
remember why SDL was preferred. I think TOML is more widely used than
SDL [2]. GitLib CI multi runner is also using it.
[1] https://github.com/toml-lang/toml
[2] https://github.com/to
Hi,
I have a problem to generate D wrapper for wxWidgets (wxD) on
msys2/mingw64.
Here is how to reproduce it:
1) Install msys2 from here http://msys2.github.io/
2) Launch msys2 terminal and add dmc/dmd to PATH
$ mkdir tmp && cd tmp
$ export
PATH="C:\Developer\D\dm\bin":"C:\Developer\D\dmd2\
On Thursday, 26 November 2015 at 20:35:28 UTC, mattcoder wrote:
On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe
wrote:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig
wrote:
Thanks,
Sönke
Thank you (and others) for your time developing dub.
I don't understand any
On 26/11/2015 16:10, Sönke Ludwig wrote:
The only valid reason for an IDE to directly parse the package
description is basically if it wants to provide a custom UI for editing
it. If the IDE is written in D, it can easily use DUB as a library and
not only get the package description in a common
On Thursday, 26 November 2015 at 18:56:20 UTC, Sebastiaan Koppe
wrote:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig
wrote:
Thanks,
Sönke
Thank you (and others) for your time developing dub.
I don't understand any feelings for or against the
configuration's format. From a main
On Thursday, 26 November 2015 at 17:23:07 UTC, Andrei
Alexandrescu wrote:
As of right now the situation with ranges is suboptimal - you
need to use .save() but if you don't the sheer copy works most
of the time, just not always. It may be nice to improve on that
a bit, for example to require in
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
[...]
So it's not just the function's signature you want to hash, but
it's code as well? What about functions called from the API
function? Or functions
On Thursday, 26 November 2015 at 19:57:19 UTC, Jacob Carlborg
wrote:
On 2015-11-26 20:05, Sönke Ludwig wrote:
Just to mention one additional reason for choosing SDLang over
one of
the more popular formats that shared some of the advantages,
there is an
idea to add limited support for (declarat
On 2015-11-26 20:05, Sönke Ludwig wrote:
Just to mention one additional reason for choosing SDLang over one of
the more popular formats that shared some of the advantages, there is an
idea to add limited support for (declarative) procedural statements:
https://github.com/D-Programming-Language/d
On 2015-11-26 12:24, tcak wrote:
One file can consist of many API functions. If there are 50 functions in
it, and only 1 of them has been modified, whole hash will change.
Compiler cannot tell which API has been changed then. Purpose is to
decrease the burden on programmer, and put it onto compi
Am 26.11.2015 um 18:10 schrieb Walter Bright:
On 11/26/2015 12:50 AM, Sönke Ludwig wrote:
Nobody has invented anything here. Please at least get your facts
straight
before ending discussions in this tone and manner.
I told Andrei it was invented, so I take the blame for that. I was
wrong. Jona
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:
Thanks,
Sönke
Thank you (and others) for your time developing dub.
I don't understand any feelings for or against the
configuration's format. From a maintainability perspective JSON
wins, from readability SDL wins. Pick _one
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
You are in a big team or working with a big code base. APIs are
being defined/modified, configuration constants are
defined/modified, structures are defin
On Thursday, 26 November 2015 at 11:45:07 UTC, Jakob Ovrum wrote:
On Thursday, 26 November 2015 at 10:47:39 UTC, Andrea Fontana
wrote:
Can gdc or ldc compile for this platform:
https://www.raspberrypi.org/blog/raspberry-pi-zero/
?
It's Linux/ARM, so yes, both GDC and LDC can target it.
FYI
On Thursday, 26 November 2015 at 02:20:43 UTC, Daniel Murphy
wrote:
Unfortunately I have no idea. You'll have to have a look at
what other code that resolves packages is doing.
If you can't find it it might be worth emailing Kenji Hara,
since he knows everything.
Well, expression.d seems to
On Wednesday, 25 November 2015 at 19:02:18 UTC, Walter Bright
wrote:
Note 2: I intend to migrate the dmd.conf file format to json.
Use D instead:
http://forum.dlang.org/post/vjipqkoiktkfvmnbs...@forum.dlang.org
The compiler already has everything to parse it.
As a side note json contains a f
Am 26.11.2015 um 18:16 schrieb B.Basile:
On Thursday, 26 November 2015 at 16:10:10 UTC, Sönke Ludwig wrote:
[...]
The only valid reason for an IDE to directly parse the package
description is basically if it wants to provide a custom UI for
editing it. If the IDE is written in D, it can easily u
On 11/20/2015 11:34 AM, Sönke Ludwig wrote:
Am 20.11.2015 um 16:37 schrieb Andrei Alexandrescu:
On 11/20/2015 04:42 AM, Sönke Ludwig wrote:
I think that .save is a serious design flaw in the range API
How would you redo it? -- Andrei
That's why I wrote that the alternatives had their own is
On Thursday, 26 November 2015 at 16:10:10 UTC, Sönke Ludwig wrote:
[...]
The only valid reason for an IDE to directly parse the package
description is basically if it wants to provide a custom UI for
editing it. If the IDE is written in D, it can easily use DUB
as a library and not only get th
On 11/26/2015 7:49 AM, Daniel Murphy wrote:
On 27/11/2015 1:37 AM, Jacob Carlborg wrote:
On 2015-11-26 12:47, Daniel Murphy wrote:
We get to delete the non-boost INI parser from the frontend!
How much trouble is that causing?
None, it just annoys me.
I agree with Daniel on that point.
On 11/26/2015 12:50 AM, Sönke Ludwig wrote:
Nobody has invented anything here. Please at least get your facts straight
before ending discussions in this tone and manner.
I told Andrei it was invented, so I take the blame for that. I was wrong.
Jonathan has since corrected me.
On 11/25/2015 11:45 PM, Jacob Carlborg wrote:
On 2015-11-25 20:02, Walter Bright wrote:
Note 2: I intend to migrate the dmd.conf file format to json.
What's the gain here compared to the breakage it will cause?
I recently spent some effort extending that format to support needed features.
It
On Thu, Nov 26, 2015 at 11:08:29AM +, Dicebot via Digitalmars-d wrote:
> On Thursday, 26 November 2015 at 09:21:33 UTC, Kagamin wrote:
> >On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei Alexandrescu
> >wrote:
> >>I need to trust our core contributors here to make the right
> >>high-level
On Thu, Nov 26, 2015 at 01:43:13PM +, mattcoder via Digitalmars-d wrote:
> Sorry but for me this is another "HOT" thread for a sh*t problem. The
> OP dislikes SDL, so use JSON. What's the big deal, and as Sönke Ludwig
> said, it was announced before
> (http://forum.rejectedsoftware.com/groups/r
Am 26.11.2015 um 16:43 schrieb Ilya Yaroshenko:
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko wrote:
Single language, json based configuration engine is simpler for IDE
development and configuration tools. For
On 27/11/2015 1:37 AM, Jacob Carlborg wrote:
On 2015-11-26 12:47, Daniel Murphy wrote:
We get to delete the non-boost INI parser from the frontend!
How much trouble is that causing?
None, it just annoys me.
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko
wrote:
Single language, json based configuration engine is simpler
for IDE development and configuration tools. For example,
Sublime Text.This is very important t
On 2015-11-26 12:47, Daniel Murphy wrote:
We get to delete the non-boost INI parser from the frontend!
How much trouble is that causing?
--
/Jacob Carlborg
On 2015-11-26 14:10, Ola Fosheim Grøstad wrote:
Why not use a well defined subset of YAML then?
I think that's perfectly fine as well.
--
/Jacob Carlborg
On Thursday, 26 November 2015 at 13:44:48 UTC, Vladimir Panteleev
wrote:
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
On 2015-11-25 11:17, Suliman wrote:
[...]
BTW, why was not TOML [1] chosen? I know it was
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
On 2015-11-25 11:17, Suliman wrote:
[...]
BTW, why was not TOML [1] chosen? I know it was discussed but
I can't remember why SDL was preferred. I think TOML is mor
Sorry but for me this is another "HOT" thread for a sh*t problem.
The OP dislikes SDL, so use JSON. What's the big deal, and as
Sönke Ludwig said, it was announced before
(http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/2/) and most agree with this change.
I'm here almost
On Thursday, 26 November 2015 at 12:11:25 UTC, Daniel Kozak wrote:
Btw. when your book will be published? :)
Soon. The schedule slipped a bit on the publisher's end, but I
don't know how it will affect the release date. I submitted my
copy edits of the prefinals last week, so now I'm just w
On Thursday, 26 November 2015 at 13:10:30 UTC, Ola Fosheim
Grøstad wrote:
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
maintain a parser for a format that hasn't "settled down" yet.
Why not use a well defined subset
On Thursday, 26 November 2015 at 12:43:54 UTC, Chris wrote:
TOML looks nice, _but_ it's version 0.4.0. We cannot afford to
maintain a parser for a format that hasn't "settled down" yet.
Why not use a well defined subset of YAML then?
V Thu, 26 Nov 2015 12:43:52 +
Chris via Digitalmars-d napsáno:
> On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
> wrote:
> > On 2015-11-25 11:17, Suliman wrote:
> >> [...]
> >
> > BTW, why was not TOML [1] chosen? I know it was discussed but I
> > can't remember why SDL w
On Thursday, 26 November 2015 at 12:29:55 UTC, Jacob Carlborg
wrote:
On 2015-11-25 11:17, Suliman wrote:
[...]
BTW, why was not TOML [1] chosen? I know it was discussed but I
can't remember why SDL was preferred. I think TOML is more
widely used than SDL [2]. GitLib CI multi runner is also u
On Monday, 23 November 2015 at 15:16:49 UTC, Sönke Ludwig wrote:
Don't works for me now, problem with
http://dlang.org/library/symbols.js both Chromium and Firefox.
I couldn't reproduce this with either Chrome/Firefox/Opera on
...
Could this be something local getting in the way, such as a
On 2015-11-25 11:17, Suliman wrote:
I think that using SDL format was big mistake. Not only I do not want to
spend time in learning yet another dead config format that now use only
one project -- DUB. In time when DUB used json it was not perfect, but
at last it was standard and everybody can rea
On 2015-11-25 17:22, Joakim wrote:
Converters like these would banish all these bikeshed arguments about
code formatting or config formats, but what would we argue about then?
We'd have to start debating religion or politics. :)
I'm sure there are a lot of other bikesheds that need (re)paintin
On 2015-11-26 09:33, Vladimir Panteleev wrote:
INI files are the closest thing to that. You probably have a lot of
INI-like files in your /etc/.
Rust's Cargo uses TOML, which is a structured extension of INI.
I think Go uses TOML. I have at least seen several Go projects who're
using. GitLab
On Thursday, 26 November 2015 at 11:49:25 UTC, John Colvin wrote:
Pretty sure it works fine with anything that dub knows about.
dub add-path or dub add-local should put things on an even
footing with ~/.dub in that regard.
`dub add-path` and `dub add-local` permanently add the specified
pat
V Thu, 26 Nov 2015 05:45:56 +
Mike Parker via Digitalmars-d napsáno:
> On Thursday, 26 November 2015 at 04:42:14 UTC, David DeWitt wrote:
>
> >
> > Is there any document explaining how to default to JSON so it
> > isn't necessary to specify each time? Also SDL isn't the
> > default so if t
On Thursday, 26 November 2015 at 10:47:39 UTC, Andrea Fontana
wrote:
Can gdc or ldc compile for this platform:
https://www.raspberrypi.org/blog/raspberry-pi-zero/
?
It's Linux/ARM, so yes, both GDC and LDC can target it.
On 26/11/2015 6:45 PM, Jacob Carlborg wrote:
On 2015-11-25 20:02, Walter Bright wrote:
Note 2: I intend to migrate the dmd.conf file format to json.
What's the gain here compared to the breakage it will cause?
We get to delete the non-boost INI parser from the frontend!
On Thursday, 26 November 2015 at 10:28:15 UTC, Dragos Carp wrote:
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker
wrote:
This is not even an issue. IDEs can create a dub.json for all
new projects and call 'dub describe' on imported projects
without ever touching SDLang. Again, *the
On Thursday, 26 November 2015 at 07:40:13 UTC, Jacob Carlborg
wrote:
On 2015-11-25 17:40, Joakim wrote:
I don't see Apple doing all that stuff nowadays. This move to
open-source Swift and port it to linux seems driven by the
llvm devs, I
doubt the company really cares. Apple open-sourced the
On Thursday, 26 November 2015 at 11:18:19 UTC, Andrea Fontana
wrote:
On Thursday, 26 November 2015 at 11:14:54 UTC, tcak wrote:
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to
talk about it again.
[...]
One applicable sol
On Thursday, 26 November 2015 at 11:14:54 UTC, tcak wrote:
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to
talk about it again.
[...]
One applicable solution: __traits( hashOf,
apiFunctionName/structName/variableName/clas
On Thursday, 26 November 2015 at 11:12:07 UTC, tcak wrote:
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
[...]
One applicable solution: __traits( hashOf,
apiFunctionName/structName/variableName/className )
I brought this topic in "Learn" a while ago, but I want to talk
about it again.
You are in a big team or working with a big code base. APIs are
being defined/modified, configuration constants are
defined/modified, structures are defined/modified for data.
You are coding on business logic sid
On Thursday, 26 November 2015 at 09:21:33 UTC, Kagamin wrote:
On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei
Alexandrescu wrote:
I need to trust our core contributors here to make the right
high-level decisions and execute them accurately when I'm not
looking.
I believe people do try
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko
wrote:
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig
Single language, json based configuration engine is simpler for
IDE development and configuration tools. For example, Sublime
Text.This is very important to make
Can gdc or ldc compile for this platform:
https://www.raspberrypi.org/blog/raspberry-pi-zero/
?
On Thursday, 26 November 2015 at 10:19:13 UTC, Mike Parker wrote:
This is not even an issue. IDEs can create a dub.json for all
new projects and call 'dub describe' on imported projects
without ever touching SDLang. Again, *there is no problem here*.
'dub describe' has one big issue. It work
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko
wrote:
Single language, json based configuration engine is simpler for
IDE development and configuration tools. For example, Sublime
Text.This is very important to make language used by big amount
of users.
Ilya
This is not
On Thursday, 26 November 2015 at 06:14:47 UTC, Joakim wrote:
I don't consider Java and C# real competitors to Swift or D, as
they're much older and won't attract the same users. Certainly
not Java, with how verbose it is, haven't looked at C# too
much. But for those with legacy codebases, tho
On Thursday, 26 November 2015 at 00:04:49 UTC, H. S. Teoh wrote:
Please, no. XML is unreadable write-only stuff that should only
be read/written by machine, it's not suitable as a *user*
interface.
XML is perfectly fine for hand editing if the grammar is well
designed. You even have IDEs that
It seems the BoyerMooreFinder currently cannot be customized with
a mapping like toLower:
import std.algorithm;
import std.stdio;
void main(string[] args) {
writeln("> ", find("Hello World", boyerMooreFinder("World")));
writeln("> ", find("Hello World", boyerMooreFinder!("toLower(a)
=
On Thursday, 26 November 2015 at 09:04:27 UTC, Ilya Yaroshenko
wrote:
Single language, json based configuration engine is simpler for
IDE development and configuration tools. For example, Sublime
Text.This is very important to make language used by big amount
of users.
Ilya
Sublime Text c
On Thursday, 26 November 2015 at 08:47:41 UTC, Sönke Ludwig wrote:
...
Just wanted to say thanks for SDLang support in dub Sönke, I
personally prefer it over json.
Bye.
On Wednesday, 25 November 2015 at 20:24:36 UTC, Andrei
Alexandrescu wrote:
I need to trust our core contributors here to make the right
high-level decisions and execute them accurately when I'm not
looking.
I believe people do try to account for your possible opinion when
making decisions, bu
On Thursday, 26 November 2015 at 07:40:13 UTC, Jacob Carlborg
wrote:
I'm guessing the only reason why they will release a Linux port
is because OS X and Linux are fairly similar, making this
small(er) effort.
Maybe also because of NextStep/GNUStep etc being available on
Linux. OS-X gets lots
On Thursday, 26 November 2015 at 08:50:42 UTC, Sönke Ludwig wrote:
Am 25.11.2015 um 20:25 schrieb Andrei Alexandrescu:
As Walter said a few times by now, inventing new languages is
an
endeavor of high fixed cost for everyone involved (including
users) and
shouldn't be done casually.
Please
Am 25.11.2015 um 20:25 schrieb Andrei Alexandrescu:
As Walter said a few times by now, inventing new languages is an
endeavor of high fixed cost for everyone involved (including users) and
shouldn't be done casually.
Please don't reply to this. Just throw SDL away and use JSON. Please
don't was
Am 26.11.2015 um 06:25 schrieb Andrei Alexandrescu:
This would be a lot more sensible if dub were not the official package
and build manager. The way I look at it, it's a manifestation of a
systemic problem: I can't work on dub and I can't monitor decisions
regarding it. Yet that doesn't make it
On Wednesday, 25 November 2015 at 23:37:20 UTC, Jonathan M Davis
wrote:
On Wednesday, 25 November 2015 at 22:51:28 UTC, rsw0x wrote:
On Wednesday, 25 November 2015 at 19:12:43 UTC, Andrei
Alexandrescu wrote:
It's not. To DUB maintainers: this is a strategic error.
Please throw SDL away and use
82 matches
Mail list logo
