I just want to write a web client app on D for medical
institutions. It must be a complicated interface. What tools
(GUI) should I use for quick programming?
Can I somehow abstract from web programming?
Thanks in advance.
Regards, Sergey
The Nimrod version partially unrolls the recursion 4 times. How
hard is this to do in D?
http://codegolf.stackexchange.com/questions/26459/how-high-can-you-go-a-codingalgorithms-challenge
Bye,
bearophile
Meta:
Your C++ translation: ~277ms
Your second version: ~2.34ms/round
Both D programs are translations of C++ programs.
LDC might do a better job with this.
I have developed those two programs using ldc2, so the usage of
ldc2 is encouraged, and inlining is necessary for both programs.
On Sunday, 4 May 2014 at 10:04:12 UTC, bearophile wrote:
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language visible
On 5/4/2014 12:34 AM, Jonathan M Davis via Digitalmars-d wrote:
Regardless, unittest blocks don't really put any restrictions on what kind of
code can go in them, and I'd prefer that that stay the case. The discussion
on parallelizing unit tests threatens that on some level, but as long as we
ha
On Sun, 2014-05-04 at 13:44 +0200, Jacob Carlborg via Digitalmars-d
wrote:
> On 2014-05-03 21:51, Atila Neves wrote:
>
> > This is why I started to learn Cucumber.
>
> Cucumber is for acceptance tests. There are also functional and
> integration tests.
We could get into bikeshedding here,…
Cuc
On 2014-05-02 19:25, brad clawsie wrote:
this has been the fundamental issue for me. its not just missing libs,
its libs that are surfaced via a C-binding, which in my limited
I've had problems with ImageMagick, basically every time. But that's the
only one I can think of, at least for now.
On 2014-05-03 21:51, Atila Neves wrote:
This is why I started to learn Cucumber.
Cucumber is for acceptance tests. There are also functional and
integration tests.
--
/Jacob Carlborg
On 2014-05-03 21:52, Atila Neves wrote:
For me it's the output. I don't want to see the output of other
tests when I'm debugging a failure.
That's a good point.
--
/Jacob Carlborg
Danny Weldon:
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf.stackexchange.com/questions/26323/how-slow-is-python-really-or-how-fast-is-your-language
It all helps to get the language visible.
Here are my solutions:
http://forum.dlang.org/thread/p
On Wednesday, 30 April 2014 at 04:22:52 UTC, Rikki Cattermole
wrote:
It may be a good time to repeat, we need a marketing manager
for D!
Somebody really really needs to focus on getting us out there.
If somebody has some time, they could post a solution in D to
this problem:
http://codegolf
On Sat, 03 May 2014 19:36:53 -0700
Walter Bright via Digitalmars-d wrote:
> On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
> > I'm not sure mock networks can really be used for testing a
> > client-only lib of some specific protocol. There may also be other
> > examples.
> >
> > There's also the que
On 5/3/2014 6:57 PM, Nick Sabalausky wrote:
I'm not sure mock networks can really be used for testing a client-only lib of
some specific protocol. There may also be other examples.
There's also the question of whether or not D's "unittest {...}" should *expect*
to be limited to tests that are *t
On 5/3/2014 3:32 PM, Walter Bright wrote:
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
One good example is networking tests - if I worked on an airplane I'd
love to
not test tests that need connectivity with a simple regex.
I am suspicious that testing networks with a unit test is an
inapp
On Thursday, 1 May 2014 at 09:58:32 UTC, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then it
contains
unit tests, not integration tests or system tests, just unit
tests.
Then we need to come up with
On Thursday, 1 May 2014 at 10:50:12 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
On 4/30/2014 1:36 PM, Andrei Alexandrescu wrote:
One good example is networking tests - if I worked on an airplane I'd love to
not test tests that need connectivity with a simple regex.
I am suspicious that testing networks with a unit test is an inappropriate use
of unit tests.
Unit tests s
On 4/30/2014 4:17 PM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
(*) Are we allowed to have gotos any more since Dijkstra's letter?
You better ask the dining philosophers.
Nah, they're too busy trying to figure out how to use their forks.
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
I think one of the great things about Rails and Ruby is all the
libraries and plugins that are available. If I want to do
something, in RoR there's a big chance there's already a
library for that. In D, there's a big chance I n
On 01/05/14 21:55, "Marc Schütz" " wrote:
You're probably right. I thought that changed in a recent release, but
can't find it anymore.
I don't know. I wouldn't trust it. It's the behavior in Rails 3. I
haven't used Rails 4 yet.
--
/Jacob Carlborg
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it.
Client side validation is about better feedback. Today's browsers
are fast enough for doing field validation for every keystroke.
4a. if transaction
On Thursday, 1 May 2014 at 18:35:40 UTC, Jacob Carlborg wrote:
On 2014-05-01 15:54, "Marc Schütz" " wrote:
You can also use the built-in `includes()`, which does a LEFT
OUTER JOIN:
Post.includes(:comments).where(comments: {title: "bar"})
(It also eager-loads the comments, but this is usu
On 2014-05-01 19:56, "Marc Schütz" " wrote:
Exactly. I just feel that client-side validation is unnecessary
duplication in most cases. But sure, it can be used where it makes sense.
There's a gem [1] for that. Although it seems that one is not maintained
anymore.
[1] https://github.com/Dock
On 2014-05-01 15:54, "Marc Schütz" " wrote:
You can also use the built-in `includes()`, which does a LEFT OUTER JOIN:
Post.includes(:comments).where(comments: {title: "bar"})
(It also eager-loads the comments, but this is usually desired anyway,
because an OUTER JOIN doesn't make sense if
On Thursday, 1 May 2014 at 15:11:07 UTC, Nick Sabalausky wrote:
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it. That's why I like to do things the
following way:
1. user input on the client
2. po
On Thursday, 1 May 2014 at 13:33:50 UTC, Marc Schütz wrote:
IMO the client shouldn't do any validation, unless you can
really, really trust it. That's why I like to do things the
following way:
1. user input on the client
2. post using ajax
3. server validates and stores the data
4a. if tran
On 5/1/14, 3:50 AM, John Colvin wrote:
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have never ever
wanted to run a sing
On Thursday, 1 May 2014 at 12:17:56 UTC, Ary Borenszweig wrote:
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then
it contains
unit tests, not integration tests or system tests, just
On Thursday, 1 May 2014 at 10:44:42 UTC, Jacob Carlborg wrote:
On 2014-04-30 22:38, Adam D. Ruppe wrote:
I also find myself really missing outer joins and views.
For outer joins:
1. You can always use raw SQL, also in combination with
ActiveRecord
Post.joins(:comments).joins("outer join fo
On Wednesday, 30 April 2014 at 17:17:02 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky
wrote:
Sounds pretty much exactly what I'd expect from just about any
PHP-based application. :/
Modern PHP isn't so bad. I can write acceptable code in PHP.
Tho
On 5/1/14, 6:58 AM, Jacob Carlborg wrote:
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then it contains
unit tests, not integration tests or system tests, just unit tests.
Then we need to come up with a separate framework f
On Wednesday, 30 April 2014 at 15:04:53 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg
wrote:
I think one of the great things about Rails and Ruby is all
the libraries and plugins that are available. If I want to do
something, in RoR there's a big chance t
On Wednesday, 30 April 2014 at 19:25:40 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to run a single unit test, why would one need it? If
On 2014-04-30 22:36, Nick Sabalausky wrote:
Aren't you talking about databases? Single-threading won't save you from
races there unless the DBMS itself is single-threaded (which would be a
pretty undesirable DBMS).
Are you referring to if one process executes line 1 while another
executes lin
On 2014-04-30 22:38, Adam D. Ruppe wrote:
Yeah, foreign keys are really an absolute must. So are uniqueness
constraints. Rails can kinda do these, but in its own reinvented ways
that don't actually hit the DB (at least not without add on gems)
Rails unique constraints do hit the DB, but they c
On 2014-04-30 22:11, Russel Winder via Digitalmars-d wrote:
This cannot be a good idea. If the block says unittest then it contains
unit tests, not integration tests or system tests, just unit tests.
Then we need to come up with a separate framework for doing all other
kinds of tests.
--
/J
On Wednesday, 30 April 2014 at 20:36:15 UTC, Andrei Alexandrescu
wrote:
On 4/30/14, 12:25 PM, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg
wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to
Am 01.05.2014 01:05, schrieb Ary Borenszweig:
On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not
On 4/30/14, 10:38 AM, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I u
On 4/30/2014 3:53 PM, Jacob Carlborg wrote:
On 2014-04-30 17:04, Adam D. Ruppe wrote:
You also have problems like race conditions:
account = BankAccount.find(1)
account.balance -= 10
account.save!
I think most Rails application are run single threaded. But with
multiple processes instead.
On Wednesday, 30 April 2014 at 19:53:53 UTC, Jacob Carlborg wrote:
I don't really agree with that. Although I'm not a fan of store
procedures/functions in the database. But I don't mind foreign
key constraints. We used that at my previous work. Via a gem :)
Yeah, foreign keys are really an abs
On 4/30/14, 12:25 PM, Dicebot wrote:
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module test
On 4/30/2014 4:36 PM, Andrei Alexandrescu wrote:
One good example is networking tests - if I worked on an airplane I'd
love to not test tests that need connectivity with a simple regex.
The biggest thing for me has been unittests in third party libraries
(hence the idiom of -version=unittest
Am 30.04.2014 22:12, schrieb Russel Winder via Digitalmars-d:
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 2014-04-30 15:38, Adam D. Ruppe wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's
On Wednesday, 30 April 2014 at 16:42:00 UTC, Nick Sabalausky
wrote:
Anytime I use them, they just create more work for me.
def. I like them in small quantities - heck, I'm written dynamic
types and scripting languages for D! But they cause me pain
pretty quickly.
On Wednesday, 30 April 2014 at 20:00:59 UTC, Russel Winder via
Digitalmars-d wrote:
If you have a "full stack" solution to a problem then Django
does work
quite well, however most of my use is far from "full stack" so
Depends on what "full stack" is meant to cover. I haven't found a
single fu
On Wed, 2014-04-30 at 21:06 +0200, Jacob Carlborg via Digitalmars-d
wrote:
> On 2014-04-30 15:38, Adam D. Ruppe wrote:
>
> > Of course, I doubt the gap will ever be closed, since Ruby's awfulness
> > isn't dependent on my experience level. It's not like it will ever get
> > static typing even if I
On Wed, 2014-04-30 at 21:08 +0200, Jacob Carlborg via Digitalmars-d
wrote:
[…]
> Why would I run more tests than I have to? BTW, I would probably use the
> "unittest" keyword for other kinds of tests than unit tests as well.
This cannot be a good idea. If the block says unittest then it contains
On Wednesday, 30 April 2014 at 16:02:25 UTC, Nick Sabalausky
wrote:
Well, I've been using mustache-d as my main templating engine,
which is just a general text preprocessor (Although I'm kinda
eyeing that other text preprocessor that uses actual D code).
ah, I see. BTW, fun fact: dom.d can und
On Wed, 2014-04-30 at 18:04 +, via Digitalmars-d wrote:
[…]
> I've looked closely at Django. I find it more convenient to use
> smaller independent libraries inspired by Django than using the
> framework itself.
If you have a "full stack" solution to a problem then Django does work
quite wel
On 2014-04-30 17:04, Adam D. Ruppe wrote:
I like implementing things myself :P
That's the question I dread most at meetings now: "is there a gem for
this?" idk, in the time it takes to search for and evaluate third party
code, I could have just written it myself. Especially since libraries
almo
On Wednesday, 30 April 2014 at 19:08:15 UTC, Jacob Carlborg wrote:
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have
never ever
wanted to run a single unit test, why would one need it? If
running all
module tests at once creates problems than eithe
On 2014-04-30 11:43, Dicebot wrote:
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why would one need it? If running all
module tests at once creates problems than either module is too big or
unit tests are not really unit tests.
Why wo
On 2014-04-30 15:38, Adam D. Ruppe wrote:
Of course, I doubt the gap will ever be closed, since Ruby's awfulness
isn't dependent on my experience level. It's not like it will ever get
static typing even if I used it all the time. It won't get faster.
ActiveRecord won't get sane.
Ruby has gotte
On Wednesday, 30 April 2014 at 17:23:49 UTC, Russel Winder via
Digitalmars-d wrote:
Tornado, Pyramid, Django as a framework and a design and idioms
I've looked closely at Django. I find it more convenient to use
smaller independent libraries inspired by Django than using the
framework itself.
On Wednesday, 30 April 2014 at 17:23:39 UTC, Byron wrote:
Client side validation should only be used for giving users
immediate fed
back and saving cycles. You do know I can look at your js, find
all of
your ajax calls and send what ever data I want right..
If the security model depends on co
On Wed, 30 Apr 2014 17:17:01 +, Ola Fosheim Grøstad wrote:
> 4. server unwraps the data and blindly inserts it into the database
u.. wtf? This is why hackers keep stealing my credit card
Client side validation should only be used for giving users immediate fed
back and saving
On Wed, 2014-04-30 at 05:00 +, via Digitalmars-d wrote:
[…]
> Python is simpler than Go for web. There is a reason for why Go
> is still not in production on App Engine, you end up with more
> convoluted code as far as I can tell. Faster, yep.
I disagree. A good Python Web application would
On Wednesday, 30 April 2014 at 16:56:11 UTC, Nick Sabalausky
wrote:
Sounds pretty much exactly what I'd expect from just about any
PHP-based application. :/
Modern PHP isn't so bad. I can write acceptable code in PHP.
Though, I only do so when there is no other option, since it is
the least d
On Wed, 2014-04-30 at 12:41 -0400, Nick Sabalausky via Digitalmars-d
wrote:
[…]
> This has a lot to do with why I don't buy the common argument that
> dynamic languages are all about "just getting shit done".
Interesting use of the word shit. I tend to find that the average
programmer produces sh
On 4/30/2014 12:32 PM, "Ola Fosheim Grøstad"
" wrote:
On the other side of the fence the Wordpress authors are having a lot of
power. Whatever Wordpress makes easy will dominate a large portion of
the web. I think that is so sad, because the Wordpress codebase is… err…
junk.
I've used Wordpres
On 4/30/2014 11:04 AM, Adam D. Ruppe wrote:
A big difference though is the compiler helps you a lot in D. In Ruby,
for example, the main reason we use the unit tests (so far) is to help
ensure consistency after refactoring something. It catchings things like
a renaming we missed, or a removed me
On Wednesday, 30 April 2014 at 15:27:48 UTC, Nick Sabalausky
wrote:
That definitely is the direction things are moving right now.
Granted, I don't like it, but you're right it's undoubtedly the
popular direction and it's unlikely to slow or reverse anytime
soon.
I'm not sure if I like it eith
On 4/30/2014 10:53 AM, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky wrote:
Then I use Adam's dom.d (in non-strict mode) to read the HTML form
template (preserving the templating stuff)
I use strict mode for that stuff, keep in mind strict mode is about
wel
On 4/30/14, 7:18 AM, Ary Borenszweig wrote:
On 4/30/14, 6:43 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
But unit tests in D suck as well. I mean, how do I run a single unit
test in D?
This is common complaint I still fail to understand. I have never
On 4/30/2014 10:58 AM, Ary Borenszweig wrote:
What if you have tests against a database that where each take some
time? I don't want to wait for the whole tests to run...
Collapse block, [Home], [Shift]-[Down] (select), [Ctrl]-/ (comment)
;)
Just FWIW, though. I'm not arguing for or against
On 4/30/2014 9:47 AM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky wrote:
FWIW, IMO the big selling point of D is it's fairly unique knack for
letting you eat your cake and still have it. I rather like to think we
can manage merging the "full stacks
On Wednesday, 30 April 2014 at 14:57:00 UTC, Adam D. Ruppe wrote:
- Server side generation should be kept minimal, prevents
caching.
That's not really true. You can cache individual parts on the
server and in some cases, cache the whole page on the client
too.
Mhh… I think there are several
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
I think one of the great things about Rails and Ruby is all the
libraries and plugins that are available. If I want to do
something, in RoR there's a big chance there's already a
library for that. In D, there's a big chance I ne
On Wednesday, 30 April 2014 at 13:52:25 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe
wrote:
But still, one person's productivity is too subjective to
focus a lot on IMO.
Calculated dishonesty is healthy in a marketing campaign :p
Put another way, one dat
On Wednesday, 30 April 2014 at 14:58:20 UTC, Ary Borenszweig
wrote:
That's good.
What if you have tests against a database that where each take
some time? I don't want to wait for the whole tests to run...
Tests with I/O are not unit tests. And built-in D feature is not
called unit-or-somet-
On Wednesday, 30 April 2014 at 13:47:11 UTC, Ola Fosheim Grøstad
wrote:
You might dislike this, but I think nimble servers and clean
separation with javascript heavy clients are the future.
What I don't want:
- I have started to avoid server processing of forms,
javascript/ajax gives better u
On 4/30/14, 11:25 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
When I have a bug in my code I usually add a test for it so it never
happens again.
Because it's a bug, I might need to debug it. So I add a couple of
"writefln" instead of using a debugger
On Wednesday, 30 April 2014 at 12:26:06 UTC, Nick Sabalausky
wrote:
Automatic forms generated from a type are nice for
quick-n-dirty stuff, but I find they tend to work against (or
at least be much less useful for) the tweaking and
customization usually needed in public-facing production sites.
A JIT for D? That would be many, many man-years of work.
Wrong!
It would be quite easy. I've figured it out myself.
I've thought of using Pegged with PEG/BNF ParseTrees, made faster using
ParseTree serialization matched to the source's CRC32-encoding for
memoization, with a multi-threaded mo
On Wednesday, 30 April 2014 at 09:22:06 UTC, Chris wrote:
Is there any documentation for web.d, including example apps?
Not much, I've done some before but it is pretty scattered and I
don't even know where it all is right now.
I basically implemented the most important JS features for DOM
ma
On Wed, Apr 30, 2014 at 02:25:05PM +, Dicebot via Digitalmars-d wrote:
> On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig wrote:
> >When I have a bug in my code I usually add a test for it so it never
> >happens again.
> >
> >Because it's a bug, I might need to debug it. So I add a
On Wednesday, 30 April 2014 at 14:18:37 UTC, Ary Borenszweig
wrote:
When I have a bug in my code I usually add a test for it so it
never happens again.
Because it's a bug, I might need to debug it. So I add a couple
of "writefln" instead of using a debugger (it's faster and I
get formatted re
On 4/30/14, 6:43 AM, Dicebot wrote:
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
But unit tests in D suck as well. I mean, how do I run a single unit
test in D?
This is common complaint I still fail to understand. I have never ever
wanted to run a single unit test, why wo
On Wednesday, 30 April 2014 at 14:11:20 UTC, logicchains wrote:
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
You don't necessarily need to
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
Hmm now if only I understand assembly better. And was able to
write a JIT then maybe. Maybe then I could implement my evil
ideas.
You don't necessarily need to understand assembly to write a JIT.
You could instead have your
On Wednesday, 30 April 2014 at 13:38:28 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
This is the stuff marketing campaigns are made from.
Eh, like Jacob said later, I don't think this is a totally fair
comparison cuz I'm a world
On Wednesday, 30 April 2014 at 13:50:18 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014
On Wednesday, 30 April 2014 at 13:48:07 UTC, Adam D. Ruppe wrote:
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
wrote:
Although I definitely would like to hear more about
asynchronous javascript instead of my synchronous based code
and how I can combine it at some point.
The w
On Wednesday, 30 April 2014 at 04:32:37 UTC, Russel Winder via
Digitalmars-d wrote:
The lesson from the Bottle/Flask/Tornado experience over the
last few years is that it is always better
to be working on the next version rather than just
stick to maintaining the current version.
Maybe, but in
On Wednesday, 30 April 2014 at 12:56:03 UTC, Nick Sabalausky
wrote:
FWIW, IMO the big selling point of D is it's fairly unique
knack for letting you eat your cake and still have it. I rather
like to think we can manage merging the "full stacks" with the
"lightweights".
Ugh, avoid the full sta
On Wednesday, 30 April 2014 at 04:32:33 UTC, Rikki Cattermole
wrote:
Although I definitely would like to hear more about
asynchronous javascript instead of my synchronous based code
and how I can combine it at some point.
The way it works in mine is the proxy object sets a kinda magical
helpe
On Wednesday, 30 April 2014 at 13:37:33 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12
On Wednesday, 30 April 2014 at 13:28:28 UTC, John Colvin wrote:
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 1
On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via
Digitalmars-d wrote:
This is the stuff marketing campaigns are made from.
Eh, like Jacob said later, I don't think this is a totally fair
comparison cuz I'm a world class D expert but a RoR n00b, so
there's naturally some differen
On Wednesday, 30 April 2014 at 13:03:43 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits
On Wednesday, 30 April 2014 at 12:55:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I h
On 4/30/2014 1:24 AM, Russel Winder via Digitalmars-d wrote:
I would say from anecdotal observation, so no real significance, that
most languages end up with a number of frameworks:
1A. Full stack Web framework.
1B. Lightweight HTTP framework.
2A. Full feature networking framework.
2B. Lightwei
On Wednesday, 30 April 2014 at 12:52:36 UTC, Rikki Cattermole
wrote:
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just yeste
On Wednesday, 30 April 2014 at 12:38:32 UTC, Dicebot wrote:
There are definitely several benefits of having aggregated
compile-time known list of routes. Actually I have added it as
one of examples for my DConf talk just yesterday :) This list,
however, can possibly be built automatically via r
On Wednesday, 30 April 2014 at 10:01:51 UTC, Rikki Cattermole
wrote:
Why can't stand-alone annotated function be a valid route?
Route is pretty much method + url + handler and first two can
be inferred by convention in many cases (as done in
vibe.web.rest & Co).
The only way I know of that do
On 4/30/2014 3:14 AM, Jacob Carlborg wrote:
There's a plugin [1] for Rails for generating a form based on a type. I
don't understand how anyone can manage without that. It can
automatically respond in a couple of formats as well. By default JSON,
XML and Erb template. The most basic example will
On Wednesday, 30 April 2014 at 09:41:36 UTC, Dicebot wrote:
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
wrote:
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module
coupling and OO-heavy design is big loss compared
On Wednesday, 30 April 2014 at 04:21:20 UTC, Rikki Cattermole
wrote:
Having a quick look at Cmsed I must admit I like plain vibe.d
much more despite the added features :( Forced module coupling
and OO-heavy design is big loss compared to design simplicity
and independence of base vibe.d modules
On Wednesday, 30 April 2014 at 07:14:34 UTC, Jacob Carlborg wrote:
But unit tests in D suck as well. I mean, how do I run a single
unit test in D?
This is common complaint I still fail to understand. I have never
ever wanted to run a single unit test, why would one need it? If
running all mod
1 - 100 of 137 matches
Mail list logo
