On 20.12.2013 22:05, Jacob Carlborg wrote:
On 2013-12-20 08:03, Paulo Pinto wrote:
Even though I rather use D than Go, every time I read that, I am tempted
to prove people wrong. If I had the time for it, that is.
Go offers the same mechanisms for systems programming as Oberon does. If
ETHZ wa
On Friday, 20 December 2013 at 19:40:22 UTC, Michel Fortin wrote:
Actually, "static import" already exists. And semantically it's
pretty much the same thing as the above: you have to use the
symbol's full name. But currently the compiler will import
eagerly. I doubt there'd be any breakage if "
Just watched this presentation :
http://www.infoq.com/presentations/functional-pros-cons
Skip to minute 28 to understand what we are discussing here about
the magical unique.
On Saturday, 21 December 2013 at 01:33:53 UTC, H. S. Teoh wrote:
Has DMD always had -J for string imports? 'cos if not, I'd be
fearful of
somebody using string imports to view the contents of arbitrary
files.
It fails to import the source code for the test file, so I guess
it's safe?
h
On Saturday, 21 December 2013 at 01:42:34 UTC, Luís Marques wrote:
I'm not passing -J to DMD, so I can't see how that would work.
Also, I'm not returning to the server any output from DMD,
other than the return code (success / failure).
Ahh, I misunderstood you. I'll check it.
On Saturday, 21 December 2013 at 01:33:53 UTC, H. S. Teoh wrote:
Has DMD always had -J for string imports? 'cos if not, I'd be
fearful of
somebody using string imports to view the contents of arbitrary
files.
string x = import("/etc/passwd");
pragma(msg, x);
// or trigg
On Sat, Dec 21, 2013 at 02:13:21AM +0100, Jakob Ovrum wrote:
[...]
> Well, then it does become a lot harder to exploit, but DMD being a
> C++ project it might be prone to security flaws, especially in past
> versions (I'm not very familiar with the DMD codebase, so can't say
> for sure). Make sure
I don't have anything really substantial to say except that this
looks good to me and i look forward to it being
implemented/pulled.
On Saturday, 21 December 2013 at 01:14:05 UTC, Jakob Ovrum wrote:
Well, then it does become a lot harder to exploit, but DMD
being a C++ project it might be prone to security flaws,
especially in past versions (I'm not very familiar with the DMD
codebase, so can't say for sure). Make sure you d
On Saturday, 21 December 2013 at 01:19:46 UTC, Luís Marques wrote:
Yes, I implemented a timeout of just a few seconds (7s, I
think). It's short so that it doesn't take too long to test
with all the compiler versions. I actually tested that the
template recursion is limited (500) but not CTFE (a
On 2013-12-20 21:36:15 +, Andrei Alexandrescu
said:
On 12/20/13 12:43 PM, Martin Nowak wrote:
Couldn't static imports be made lazy without breaking any code?
One simple idea is to make all imports lazy - no change in semantics.
Sure, why not. Except that upon reaching the first non-fu
On Sat, Dec 21, 2013 at 02:13:21AM +0100, Jakob Ovrum wrote:
[...]
> Anyway, I know for a fact that one can easily make DMD go into an
> infinite loop in various ways, so you'd have to implement some kind
> of timeout (not talking about CTFE here, which I think is
> self-limiting).
CTFE is self-li
On Saturday, 21 December 2013 at 01:14:05 UTC, Jakob Ovrum wrote:
Anyway, I know for a fact that one can easily make DMD go into
an infinite loop in various ways, so you'd have to implement
some kind of timeout (not talking about CTFE here, which I
think is self-limiting).
Yes, I implemented
On Saturday, 21 December 2013 at 01:03:32 UTC, H. S. Teoh wrote:
Well, in that case it's not *as* bad of an idea. :P But still,
you want
to be careful any time arbitrary, unfiltered user input is
involved,
especially when said user input is code (the executable may not
be run,
but remember th
On Saturday, 21 December 2013 at 00:54:52 UTC, Luís Marques wrote:
On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum
wrote:
This is not running in a sandbox? And it's running on a
*Windows machine*?
I really recommend you take it down. Someone will come around
and infect your work ne
On Sat, Dec 21, 2013 at 01:54:49AM +0100, digitalmars-d-boun...@puremagic.com
wrote:
> On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum wrote:
> >This is not running in a sandbox? And it's running on a *Windows
> >machine*?
> >
> >I really recommend you take it down. Someone will come ar
On Sat, Dec 21, 2013 at 01:47:39AM +0100, Jakob Ovrum wrote:
> On Saturday, 21 December 2013 at 00:22:23 UTC, Luís Marques wrote:
> >I haven't yet secured the client which does the tests, and I
> >imagine that the old DMD versions are full of vulnerabilities, so
> >please don't be a jerk :-) (I hop
On Saturday, 21 December 2013 at 00:47:49 UTC, Jakob Ovrum wrote:
This is not running in a sandbox? And it's running on a
*Windows machine*?
I really recommend you take it down. Someone will come around
and infect your work network, it's just a matter of time.
To be clear, the user provided
On Saturday, 21 December 2013 at 00:22:23 UTC, Luís Marques wrote:
I haven't yet secured the client which does the tests, and I
imagine that the old DMD versions are full of vulnerabilities,
so please don't be a jerk :-) (I hope the client doesn't die, I
left it running at work, as I don't have
Hi,
My memory of the timeline of D features is quite fuzzy, so I
created a service to test snippets of D source code with *all* of
the DMD versions publicly available.
Right now the service is *very* in the rough and the UI is butt
ugly (it just outputs the raw results), but it seems to be
On 12/20/2013 06:27 PM, Andrei Alexandrescu wrote:
I had this idea fot a while, and Walter is favorable of it as well -
extend "import" for one-shot use. With that feature the example would
become:
void topN(alias less = "a < b",
SwapStrategy ss = SwapStrategy.unstable,
On Fri, Dec 20, 2013 at 10:51:13PM +0100, monarch_dodra wrote:
> On Friday, 20 December 2013 at 21:36:15 UTC, Andrei Alexandrescu
> wrote:
> >On 12/20/13 12:43 PM, Martin Nowak wrote:
> >>Couldn't static imports be made lazy without breaking any code?
> >
> >One simple idea is to make all imports l
On 12/18/2013 04:42 AM, Kenji Hara wrote:
http://wiki.dlang.org/DIP53
Redesign currently implemented qualified constructor concept.
...
Roughly speaking, this DIP just removes a language feature and changes
the syntax of another feature to something less descriptive. I think
implementing this
On 12/19/2013 2:11 PM, Martin Nowak wrote:
And there is also a cmdline tool to do this, dman.
Still anything that helps to improve the usability of the website is welcome
https://github.com/D-Programming-Language/dlang.org.
I find dman to be very convenient. Glad someone else noticed it :-)
On Friday, 20 December 2013 at 21:32:23 UTC, Max Klyga wrote:
2. Make a D fastcgi process and point nginx to it. There is
Adam Ruppe's cgi.d implementation for example.
Yeah, my cgi.d can interface with nginx through fastcgi, scgi, or
reverse proxy pretty well.
Though my code doesn't scale a
On Friday, 20 December 2013 at 21:38:20 UTC, Larry wrote:
Do many people use it ?
Not many, as not many people use D in general. No negative
feedback from those who have tried so far though ;) You may want
to contact developer(s) directly via
http://forum.rejectedsoftware.com/groups/rejected
On Friday, 20 December 2013 at 21:44:11 UTC, Larry wrote:
Now,
I assume that it is very fast. But there are no benchmarks
under heavy loads.
It seems very good but not really commonly used.
Probably only current information about vibe.d performance is
this article :
https://atilanevesonco
Thanks a lot !
You are all wonderful and helpful
On Friday, 20 December 2013 at 08:42:29 UTC, bearophile wrote:
(We are bikeshedding a little.)
A lot actually, I just hope this gets implemented, whatever
keyword will be used.
On Friday, 20 December 2013 at 21:36:15 UTC, Andrei Alexandrescu
wrote:
On 12/20/13 12:43 PM, Martin Nowak wrote:
Couldn't static imports be made lazy without breaking any code?
One simple idea is to make all imports lazy - no change in
semantics.
Andrei
If the import is lazy, how do you
Now,
I assume that it is very fast. But there are no benchmarks under
heavy loads.
It seems very good but not really commonly used.
On 12/20/13 12:43 PM, Martin Nowak wrote:
Couldn't static imports be made lazy without breaking any code?
One simple idea is to make all imports lazy - no change in semantics.
Andrei
Thanks !
Now, the next question : are those implementations robust ?
Do they bite (are they reliable )?
Do many people use it ?
Remember, I am coming from python where everything is easy and am
already learning D and decided to give it a jump.
On Friday, 20 December 2013 at 21:32:57 UTC, Larry wrote:
Let me add a bit more of context : I currently use UWSGI but I
would like to accelerate python replacing it with D.
Less memory consumption and so on..
I need something as robust as uwsgi.
If there is none, then, no go. :)
Thanks !
Ok,
thanks you answered while I was typing :)
On Friday, 20 December 2013 at 21:21:23 UTC, Larry wrote:
Hello,
I am not really confident on this one, but could D be
interfaced with Nginx ?
It would be nice to replace python but if not easily doable,
then it is a no-no for me.
Any clue on it ?
Thanks
http://dicebot-old.blogspot.co.u
On 2013-12-20 21:21:22 +, Larry said:
Hello,
I am not really confident on this one, but could D be interfaced with Nginx ?
It would be nice to replace python but if not easily doable, then it is
a no-no for me.
Any clue on it ?
Thanks
Sure you can. There are three options:
1. Make ng
Let me add a bit more of context : I currently use UWSGI but I
would like to accelerate python replacing it with D.
Less memory consumption and so on..
I need something as robust as uwsgi.
If there is none, then, no go. :)
Thanks !
Hello,
I am not really confident on this one, but could D be interfaced
with Nginx ?
It would be nice to replace python but if not easily doable, then
it is a no-no for me.
Any clue on it ?
Thanks
On 2013-12-20 08:03, Paulo Pinto wrote:
Even though I rather use D than Go, every time I read that, I am tempted
to prove people wrong. If I had the time for it, that is.
Go offers the same mechanisms for systems programming as Oberon does. If
ETHZ was able to create Native Oberon, AOS and EthO
On 2013-12-20 16:12, bearophile wrote:
Lot of programmers ignore what academia does, this is a big problem.
Unfortunately the opposite is true as well. I read some article that
here in Sweden the universities and other schools examines around 1000
people in the area of game development. At t
I updated DIP22 - Private symbol visibility with my findings from
implementing the 'Hide module members' pull request.
https://github.com/D-Programming-Language/dmd/pull/739
I don't have much time to cope with the topic but any feedback is welcome.
On 12/20/2013 06:27 PM, Andrei Alexandrescu wrote:
I had this idea fot a while, and Walter is favorable of it as well -
extend "import" for one-shot use. With that feature the example would
become:
void topN(alias less = "a < b",
SwapStrategy ss = SwapStrategy.unstable,
On 12/20/2013 08:40 PM, Michel Fortin wrote:
Actually, "static import" already exists. And semantically it's pretty
much the same thing as the above: you have to use the symbol's full
name. But currently the compiler will import eagerly. I doubt there'd be
any breakage if "static" changed to mean
On Friday, 20 December 2013 at 19:51:03 UTC, H. S. Teoh wrote:
On Fri, Dec 20, 2013 at 02:40:22PM -0500, Michel Fortin wrote:
On 2013-12-20 19:36:28 +, "Meta" said:
>On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down
>wrote:
>>On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh
On Fri, Dec 20, 2013 at 02:40:22PM -0500, Michel Fortin wrote:
> On 2013-12-20 19:36:28 +, "Meta" said:
>
> >On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
> >>On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
> >>>in the current import path, then implicitly try
On 2013-12-20 19:36:28 +, "Meta" said:
On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
in the current import path, then implicitly try to import x.y and lookup
z in that module. Then you could just write:
On Friday, 20 December 2013 at 19:34:10 UTC, Patrick Down wrote:
On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
in the current import path, then implicitly try to import x.y
and lookup
z in that module. Then you could just write:
void f(T)(T t) if (std.range.isInputRang
On Friday, 20 December 2013 at 17:40:08 UTC, H. S. Teoh wrote:
in the current import path, then implicitly try to import x.y
and lookup
z in that module. Then you could just write:
void f(T)(T t) if (std.range.isInputRange!T) ...
and the compiler will automatically import std.range wit
On Fri, Dec 20, 2013 at 02:20:12PM -0500, Michel Fortin wrote:
> On 2013-12-20 17:27:55 +, Andrei Alexandrescu
> said:
>
> >I had this idea fot a while, and Walter is favorable of it as well
> >- extend "import" for one-shot use. With that feature the example
> >would become:
> >
> > void
On Fri, Dec 20, 2013 at 01:17:29PM -0600, captaindet wrote:
> On 2013-12-20 11:38, H. S. Teoh wrote:
[...]
> >Hmm. Why do we need to incorporate the 'import' keyword in the first
> >place? What about extending symbol lookup, so that if a
> >fully-qualified symbol x.y.z can't be found in the current
On 2013-12-20 11:38, H. S. Teoh wrote:
On Fri, Dec 20, 2013 at 09:27:55AM -0800, Andrei Alexandrescu wrote:
On 12/20/13 5:45 AM, Joseph Rushton Wakeling wrote:
On 20/12/13 10:06, Meta wrote:
void topN(alias less = "a< b",
SwapStrategy ss = SwapStrategy.unstable,
On 2013-12-20 17:27:55 +, Andrei Alexandrescu
said:
I had this idea fot a while, and Walter is favorable of it as well -
extend "import" for one-shot use. With that feature the example would
become:
void topN(alias less = "a < b",
SwapStrategy ss = SwapStrategy.unstabl
On Friday, 20 December 2013 at 17:57:46 UTC, Andrei Alexandrescu
wrote:
On 12/20/13 9:38 AM, H. S. Teoh wrote:
What about extending symbol lookup, so that if a
fully-qualified
symbol x.y.z can't be found in the current symbol tables, and
x/y exists
in the current import path, then implicitly tr
On 12/20/2013 9:57 AM, Andrei Alexandrescu wrote:
On 12/20/13 9:38 AM, H. S. Teoh wrote:
Hmm. Why do we need to incorporate the 'import' keyword in the first
place?
To make the intent explicit. But that's an interesting idea. I'd probably
require a leading '.' just to make it unambiguous that
On Fri, Dec 20, 2013 at 09:57:46AM -0800, Andrei Alexandrescu wrote:
> On 12/20/13 9:38 AM, H. S. Teoh wrote:
> >Hmm. Why do we need to incorporate the 'import' keyword in the first
> >place?
>
> To make the intent explicit. But that's an interesting idea. I'd
> probably require a leading '.' just
On 12/20/13 9:38 AM, H. S. Teoh wrote:
Hmm. Why do we need to incorporate the 'import' keyword in the first
place?
To make the intent explicit. But that's an interesting idea. I'd
probably require a leading '.' just to make it unambiguous that lookup
must start from top level.
What about e
On Fri, Dec 20, 2013 at 09:27:55AM -0800, Andrei Alexandrescu wrote:
> On 12/20/13 5:45 AM, Joseph Rushton Wakeling wrote:
> >On 20/12/13 10:06, Meta wrote:
> > void topN(alias less = "a < b",
> > SwapStrategy ss = SwapStrategy.unstable,
> > Range, RandomGen)(Range r, si
On 12/20/13 5:45 AM, Joseph Rushton Wakeling wrote:
On 20/12/13 10:06, Meta wrote:
void topN(alias less = "a < b",
SwapStrategy ss = SwapStrategy.unstable,
Range, RandomGen)(Range r, size_t nth, ref RandomGen rng)
if (isRandomAccessRange!(Range) && hasLengt
Lot of programmers ignore what academia does, this is a big
problem.
Because these programmers are not to be convinced by some arcane
academic argument but by success stories of 'industrial'
projects. I don't think that's too bad, somehow the bad academic
ideas need to be filtered.
But now
On 26/11/13 17:28, Andrei Alexandrescu wrote:
On 11/26/13 3:22 AM, Joseph Rushton Wakeling wrote:
So, as other people have suggested, really the only thing we can
reasonably do is to define a separate Imaginary type
I agree. Let's move forward with this.
Provisional code:
https://github.com/
On Fri, Dec 20, 2013 at 10:06:01AM +0100, Meta wrote:
> On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei Alexandrescu
> wrote:
> >2. Push imports from top level into the entities (functions,
> >classes etc) that use them.
>
> 2 comes with its own problems, though. With imports at the top, yo
pjmlp:
Now we have Julia already achieving C like speeds in some
areas, although the implementation is still quite young.
Julia compiles using LLVM, that is mature. But I think Julia uses
light optimization parameters (I don't know if the optimization
level can be changed).
So until a big
On 12/20/2013 03:04 PM, Timon Gehr wrote:
The DIP breaks some existing, perfectly valid code without any clear way
to fix it.
const(int)* foo(...){ ... }
class C{
int* a;
this()const{
a = foo(...); // error
}
}
The actual workaround will be:
class C{
int* a;
On Friday, 20 December 2013 at 10:26:09 UTC, Araq wrote:
On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile
wrote:
Russel Winder:
The whole point of Go is to re
On 12/20/2013 08:43 AM, Joseph Rushton Wakeling wrote:
On 20/12/13 01:41, deadalnix wrote:
If that is an extra learning cost, doesn't it make the semantic more
complex,
almost by definition ?
Compared to ... ?
As far as I can see, it's learning a small extra meaning of 'const' in a
context wh
On 20/12/13 10:06, Meta wrote:
2 comes with its own problems, though. With imports at the top, you can easily
tell what the module imports at a glance. Putting imports into the deepest
possible scopes where they are used will make it a huge chore to hunt all the
imports down. You can of course gr
On 20/12/13 09:42, bearophile wrote:
A new keyword is a flag that you have found something different. It makes it
simpler to learn.
[... ]
Giving different names to different ideas makes them less complex :-)
Seems to me there's something of a sweet spot to be found between minimizing the
to
On 2013-12-20 10:37, Andrei Alexandrescu wrote:
I think that's a price we need to pay the same way cars replaced
carriages in spite of them having a lot of disadvantages at the time.
It's simply a mindset to do away with.
Transitive imports can be figured with:
dmd -c -o- -v module | grep '^im
On Thursday, 19 December 2013 at 11:22:59 UTC, Maxim Fomin wrote:
On Thursday, 19 December 2013 at 07:31:28 UTC, ilya-stromberg
wrote:
What should we do if we decide that we need REAL `const`
postblit/constructor? I mean postblit/constructor that creates
only `const` object that can't be implic
On 12/20/2013 12:32 PM, Timon Gehr wrote:
On 12/20/2013 10:13 AM, Andrej Mitrovic wrote:
On 12/20/13, bearophile wrote:
A new keyword is a flag that you have found something different.
It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the
On 12/20/2013 10:13 AM, Andrej Mitrovic wrote:
On 12/20/13, bearophile wrote:
A new keyword is a flag that you have found something different.
It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the symbol name "body", but I can't use this s
On Friday, 20 December 2013 at 07:04:02 UTC, Paulo Pinto wrote:
On Friday, 20 December 2013 at 06:50:41 UTC, SomeDude wrote:
On Thursday, 19 December 2013 at 12:27:57 UTC, bearophile
wrote:
Russel Winder:
The whole point of Go is to replace C,
I didn't know this.
Bye,
bearophile
Because
On 12/19/13, Adam D. Ruppe wrote:
> Is there a way to skip writing the exports section and using a
> .def file when doing a DLL on Windows now?
>
> And if not, will/can DIP45 allow that?
Not sure if you mean avoiding using the EXPORTS section in a .def
file, or if you want to avoid using export d
On 12/20/13, Andrei Alexandrescu wrote:
> Local imports are the future. Better get used to them.
To be fair, it's modularization that is the future. And that implies
modules that don't stand tall at 8K, 16K, 32K lines+. If the modules
have less code and the code is limited in scope then you autom
On 12/20/13 1:06 AM, Meta wrote:
On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei Alexandrescu wrote:
2. Push imports from top level into the entities (functions, classes
etc) that use them.
2 comes with its own problems, though. With imports at the top, you can
easily tell what the modu
Andrej Mitrovic:
It also steals a valid symbol name.
Someone has suggested to prefix it with a @.
E.g. there's tons of C code that
uses the symbol name "body", but I can't use this symbol
because it's
used in DBC. It's a keyword that's used in literally just one
feature, and it's annoying
On Friday, 20 December 2013 at 09:18:07 UTC, Joseph Rushton
Wakeling wrote:
On 20/12/13 10:10, ilya-stromberg wrote:
Would you like to be responsible for this decision?
I hope it's clear that what I'm trying to do is understand your
reasoning, because you have ideas and knowledge that are
di
On 12/20/13, Meta wrote:
> 2 comes with its own problems, though. With imports at the top,
> you can easily tell what the module imports at a glance. Putting
> imports into the deepest possible scopes where they are used will
> make it a huge chore to hunt all the imports down.
Why is that import
On 20/12/13 10:10, ilya-stromberg wrote:
Would you like to be responsible for this decision?
I hope it's clear that what I'm trying to do is understand your reasoning,
because you have ideas and knowledge that are different from mine.
On 12/20/13, Andrej Mitrovic wrote:
> at least with
> asserts in the actual body I can add diagnostic messages)
Sorry that was wrong, "in" can be used for that of course. But I don't
see the benefit of in blocks.
On Thursday, 19 December 2013 at 09:52:15 UTC, Joseph Rushton
Wakeling wrote:
Unless there's a good application of a specifically
const-specific postblit/constructor, it seems to me that the
conflation in the DIP is helpful, because it simplifies the
process of writing, understanding and using
On 12/20/13, bearophile wrote:
> A new keyword is a flag that you have found something different.
> It makes it simpler to learn.
It also steals a valid symbol name. E.g. there's tons of C code that
uses the symbol name "body", but I can't use this symbol because it's
used in DBC. It's a keyword
On Wednesday, 18 December 2013 at 21:40:08 UTC, Andrei
Alexandrescu wrote:
2. Push imports from top level into the entities (functions,
classes etc) that use them.
2 comes with its own problems, though. With imports at the top,
you can easily tell what the module imports at a glance. Putting
On 12/20/13, Martin Nowak wrote:
> On 12/19/2013 04:13 PM, Craig Dillabaugh wrote:
>> Maybe it uses the Javascript hypenator or something. After all
>> it was Andrei that posted it :o)
>
> Hyphenate with D. http://code.dlang.org/packages/hyphenate
P.S. That homepage link leads to a dead link. Th
Joseph Rushton Wakeling:
As far as I can see, it's learning a small extra meaning of
'const' in a context where it's quite intuitive, versus
introducing an extra keyword which is used _only_ in this
context and which is not entirely intuitive.
A new keyword is a flag that you have found some
86 matches
Mail list logo
