Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 02:47:38 UTC, Rikki Cattermole wrote: I checked out y4m-d when it went up on the dub repository. Looks interesting. I do have to ask, are you interested in creating a unified library for multimedia with a importers/exporters a bit like ASIMPP? Because I think that could be rather useful and not too much work on top of the given types already had. Not really especially for video. Muxed video requires superior abstractions that I won't get right. Real streams may contains dynamic type-change and time flows continuously. So the generic streal abstraction when opening multimedia will be much more involved than in y4m, and this hard work has already been done in ffmpeg/libav.
Re: New libraries wave-d and y4m-d
On Tuesday, 29 April 2014 at 18:46:51 UTC, ponce wrote: wave-d is a library for reading and writing WAV format (range-based). https://github.com/p0nce/wave-d --- y4m-d is a library for reading and writing Y4M files. https://github.com/p0nce/wave-d Y4M is one of the simplest uncompressed video format, it's designed to provide a bit of meta-data over raw YUV files. That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day.
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering?
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 12:24:14 UTC, ponce wrote: On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering? Current offering of what, waved or portaudio/libsndfile?
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 13:39:41 UTC, Chris wrote: On Wednesday, 30 April 2014 at 12:24:14 UTC, ponce wrote: On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering? Current offering of what, waved or portaudio/libsndfile? Current offering as in the set of libraries available from D. libsndfile and portaudio can be used through bindings. But maybe you were thinking about eventually not using them?
Re: New libraries wave-d and y4m-d
On Wednesday, 30 April 2014 at 13:43:45 UTC, ponce wrote: On Wednesday, 30 April 2014 at 13:39:41 UTC, Chris wrote: On Wednesday, 30 April 2014 at 12:24:14 UTC, ponce wrote: On Wednesday, 30 April 2014 at 08:34:42 UTC, Chris wrote: That's great! At the moment I'm using PortAudio and libsndfile, it would be nice to have a D sound library one day. What are you missing in the current offering? Current offering of what, waved or portaudio/libsndfile? Current offering as in the set of libraries available from D. libsndfile and portaudio can be used through bindings. But maybe you were thinking about eventually not using them? I use portaudio and libsndfile through D bindings. I was just wondering, if there will be a comparable sound library written purely in D one day. It'd be a bit like re-inventing the wheel, I know, but since we already got the wheel in form of those two libs, there's no harm in rolling our own custom wheel at our own pace (pardon the pun).
Mono-D 2.0 - XamarinStudio 5.0 support, completion improvements
Hi everyone, there's a new XamarinStudio version upcoming. And just as usual, I've just downloaded the bleeding-edge release candidate and made Mono-D run on it :P For the next couple of days, you'll only be able to get Mono-D from the repo I've mentioned in the release note, as XamarinStudio's online addin system isn't ready for the new major version yet. Furthermore, there have been some smaller changes improvements to the completion functionality again. There's also upcoming dustmite support where you'll be able to invoke dustmite from within Mono-D. http://mono-d.alexanderbothe.com/mono-d-2-0-for-xamarinstudio-5-0/ Hopefully, I can release the new XamarinStudio/MonoDevelop version on Linux as well. Someone mentioned an API freeze for the next couple of XS/MD versions, so chances are good that there's no hassle with broken Mono-D's for the next months. Enjoy!
Announcing TitaniumD - A D Binding for the Botan Cryptography Library
Hello Fellow D'ers, I'd like to announce TitaniumD, a binding for D to the Botan Cryptography Library. Botan is an open-source cryptography library written in C++11 and makes extensive use of the C++ Standard Library in it's API. Titanium is a PIMPL around the Botan API designed to make interfacing Botan with other languages easier by translating the STL API into something more friendly. TitaniumD is the D specific binding for Botan. Botan is distributed as source only and utilizes a script to configure individual modules into a single header and source file called an amalgamation build. Because of this Botan and Titanium are not a typical library distributions, such as OpenSSL, and therefore I am unsure how this might fit into Deimos. A TitaniumD consists of three components: - TitaniumCore, contains the Botan amalgamation build and the PIMPL wrapper. - TitaniumD, the C++ half of the D binding that maps the PIMPL wrapper to a D compatible ABI. - TDI, the D half of the binding. Each of these components is built as a static library. Currently Titanium supports the following algorithms: AES - Sizes: 128/192/256- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Camellia- Sizes: 128/192/256 - Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Serpent - Sizes: 128- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV Threefish - Sizes: 512 - Modes: CBC, CTS, CFB, OFB, CTR, EAX, SIV Twofish - Sizes: 128- Modes: CBC, CTS, CFB, OFB, CTR, EAX, GCM, SIV SHA-2 - Sizes: 224/256/384/512 SHA-3 - Sizes: 224/256/384/512 Skein - Sizes: 512 Whirlpool - Sizes: 512 RSA Elliptic Curve Diffie-Hellman HMAC RNG ANSI X.923 RNG SSL/TLS support is coming soon. Botan has supported SSL/TLS for a long time, however, there were a few bugs in code that prevented Visual C++ from compiling the TLS modules. These are in the process of being fixed and I'll be building a wrapper for TLS in Titanium shortly. Botan currently supports x86, x64, and ARM, on Linux, OSX, Windows, iOS, and Android. The only dependency that Botan has is on Boost, and any recent version will do, I've tested it 1.54 and 1.55. At this point in time, I only have the time and energy to maintain the Windows portion of the code. Currently you can build it on Windows by entering the directory and running Build.sh in the Git Console. However, I could really use help in porting the build processes to other platforms. Beyond Botan the code itself is pretty vanilla C++, so any recent compiler should be able to compile the interface libraries without much fuss. So if anybody has any interest in a Crypto library for D that is easy to use and isn't OpenSSL, I could really use some help getting this library ported to more platforms. Pull requests will be accepted! Repositories: Botan: https://github.com/randombit/botan/tree/net.randombit.botan Titanium: https://github.com/ellipticbit/titanium -- Adam Wilson GitHub/IRC: LightBender Aurora Project Coordinator
Re: python vs d
On Wednesday, 30 April 2014 at 01:46:21 UTC, Nick Sabalausky wrote: indentation rules. All it can do, and indeed all is *does* do, is blindly assume that the indentation as presented is correct and adheres to the universal style. If something is indented wrong, there is no enforcement, only bugs. Not blindly. Python will complain if the indentation does not make sense. I very seldom run into indentation issues now, but had some when I was new to Python. Just like C's syntax, it takes some time getting used to.
Re: python vs d
On Tuesday, 29 April 2014 at 14:50:38 UTC, Kagamin wrote: On Monday, 28 April 2014 at 19:34:38 UTC, Kapps wrote: D can actually do a rather good job of runtime reflection. I made a runtime reflection module (https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d / https://shardsoft.com/docs/ShardTools/Reflection.html) for my own personal code and it's served the uses I've needed it for quite nicely. Cool. Can it access private members? Fields, but not methods. Private methods is something I was thinking about, but the only way I can think of to do it would involve making the type use a mixin (which does make sense in a way). I haven't done any work on anything like this though, and it's not really high priority since fields work and I haven't needed anything else yet.
Re: D For A Web Developer
On 30/04/14 00:09, Adam D. Ruppe wrote: A lot of things, mostly focusing around having the compiler to help refactor with confidence (the importance of this really can't be understated) and having libraries that fit better. 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 need to implement it myself. The speed is a nice bonus too, having to spend half a minute just waiting for the tests to run really grates me. Yeah, it's sucks that Rails is so slow to boot. But unit tests in D suck as well. I mean, how do I run a single unit test in D? Also, my text editor (TextMate) already has support for the unit tests frameworks used in Ruby. But wrt libraries, ActiveRecord is unbelievably awful, for example. It is a bad idea from the ground up: why, oh why are we reinventing the database? How do you mean? It just adds an object oriented layer on top of it. BTW, what should I use in D. I need a library that is database independent and I don't want to write SQL for the common use cases? erb templates are painful to use too I prefer HAML (similar to Jade in vibe.d) but I don't think it's that bad. What do you use? , and so is the routing. I don't understand why routing isn't done automatically for the common case. I don't know how you do you're routing but the first thing I do when generating a new Rails application is to remove the default routing. The default routing opens every public method in a controller to be a routing end point. It's a complete mess. The scaffolding is a pain too. Contrast to what web.d does: given a function signature, it automatically generates a form for it (using type information to select correct widgets) and can format the response in several forms automatically including plain text, html list, html table, json, xml, csv, and a custom template. 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 look something like this: class FoosController ApplicationController respond_to :json, :xml def index respond_with Foo.all end end Maybe Rails can do this stuff and I'm too much of a n00b, but the other experienced team members say the way we're doing it is pretty standard and I'm just not impressed. Sure, it depends on what's standard. Only using what's installed by default. Then yes, perhaps that's standard. But it's not always the best idea. At my previous work I did quite a lot different compared to the experienced team members. I can just get stuff done in D in a fraction of a time it takes to do even less in RoR. You don't think that's because you're used D for quite a while and developed your own web framework. Compared to Rails where you're completely new. The biggest problem I have with D is have to do everything myself. I'm getting a bit tired of that. [1] https://github.com/plataformatec/simple_form -- /Jacob Carlborg
Re: D For A Web Developer
On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote: Go has gained much of it's traction from provably and consistently producing simpler, faster and more reliable systems that C, C++, Python, etc. and getting articles about the success out there. 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. Only because developers don't reach for PyPy and Cython as much as they should, rather re-writing everything from scratch and they stating how they are impressed by Go.
Re: D For A Web Developer
On Wednesday, 30 April 2014 at 04:42:09 UTC, Dicebot wrote: On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote: On Tue, 2014-04-29 at 22:09 +, Adam D. Ruppe via Digitalmars-d wrote: […] I can just get stuff done in D in a fraction of a time it takes to do even less in RoR. This is the stuff marketing campaigns are made from. As well as informing the cabal that is this mailing list, there needs to be tweets, Facebook, G+, and proper publishing articles of people switching from RoR, Grails, Django to web.d and vibe.d and discovering (measured and guaranteed) significant performance benefits in both time to market and run time. I have a friend who has switched to vibe.d after being Erlang Cowboy devoted user for years. Trying to convince him to write an article about it but no luck so far :( Reason to switch in two words : static typing. I do like dynamic typed languages, but mostly for prototyping, scripting and tiny scale projects. The type of code that we get to write at enterprise level, static typing is very valuable, specially given how management tends to enforce write code not tests and the skillset of certain developers across regions. Code bases being worked on with 30+ developers across multiple sites get fragile very easily. -- Paulo
Re: D vs Rust: function signatures
On Wednesday, 30 April 2014 at 01:49:01 UTC, Nick Sabalausky wrote: On 4/29/2014 9:38 PM, Narrator wrote: fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self That looks like line noise. Not if one is used to ML languages. Beauty is in the eyes of the beholder. :)
Re: D vs Rust: function signatures
On Wednesday, 30 April 2014 at 01:38:46 UTC, Narrator wrote: The unbelievable amount of time and energy that's been spent discussing the smallest syntax, you would think that D would, at the very least, have better looking function signatures, but it doesn't. auto zip(Ranges...)(Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); auto zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if (Ranges.length allSatisfy!(isInputRange, Ranges)); fn zipB, U: IteratorB(self, other: U) - ZipSelf, U auto chain(Ranges...)(Ranges rs) if (Ranges.length 0 allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, Ranges))) == void)); fn chainU: IteratorA(self, other: U) - ChainSelf, U template map(fun...) if (fun.length = 1) auto map(Range)(Range r) if (isInputRange!(Unqual!Range)); fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self template filter(alias pred) if (is(typeof(unaryFun!pred))) auto filter(Range)(Range rs) if (isInputRange!(Unqual!Range)); fn filter'r(self, predicate: |A|: 'r - bool) - Filter'r, A, Self MaxType!(T1, T2, T) max(T1, T2, T...)(T1 a, T2 b, T xs) if (is(typeof(a b))); pub fn maxT: TotalOrd(v1: T, v2: T) - T I don't think a single one of those signatures are equivalent. Also, bear in mind that those if() constraints contain arbitrary code (as long as it can be evaluated at compile-time), so they are very flexible.
Re: python vs d
On Wednesday, 30 April 2014 at 06:12:24 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 01:46:21 UTC, Nick Sabalausky
wrote:
indentation rules. All it can do, and indeed all is *does* do,
is blindly assume that the indentation as presented is correct
and adheres to the universal style. If something is indented
wrong, there is no enforcement, only bugs.
Not blindly. Python will complain if the indentation does not
make sense. I very seldom run into indentation issues now, but
had some when I was new to Python. Just like C's syntax, it
takes some time getting used to.
Say you have a Python file with 500 lines of code. Try to copy
and paste something with a different indentation from somewhere
else into an if statement. You'll have to clean up before you can
test the program. This kind of patronizing bullshit was invented
for non-programmers who might make a mess of the code otherwise.
Any programmer will structure and clean up the code once s/he's
happy with it. Indentationists seem to assume that you cannot
indent in C-style languages or if it is not prescribed, people
will make a mess of it (which is patronizing fascist thinking).
In D you can do this:
if (mode == TEST) { // Second block added later
if (x == 1) { // First block
writeln(Hurray!);
}
}
In my opinion, this helps to test and bypass etc. things while
debugging. Often I don't keep them, and if I do, I clean them up
immediately as soon as I'm happy with it. In Python you have to
clean up, even if it's just for 2 minutes of debugging / testing.
Not to mention the nightmare of merging Python files with
different indentation levels or styles (tab vs. space).
Re: D For A Web Developer
On Wednesday, 30 April 2014 at 07:18:49 UTC, Paulo Pinto wrote: On Wednesday, 30 April 2014 at 05:00:47 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 30 April 2014 at 04:19:15 UTC, Russel Winder via Digitalmars-d wrote: Go has gained much of it's traction from provably and consistently producing simpler, faster and more reliable systems that C, C++, Python, etc. and getting articles about the success out there. 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. Only because developers don't reach for PyPy and Cython as much as they should, rather re-writing everything from scratch and they stating how they are impressed by Go. thank god i'm not the only one who thinks like that. rob pike mentioned that there are much more conversion of python / ruby developers than c / c++ developers. and as we all know the reason is the speed and there's a trade off. they're trading beauty, elegance, simplicity with ugly speed. i also think many go users are caught NIH syndrome. they are re-inventing everything. heck, they are even re-inventing nginx, redis, etc. because they are _not written_ in go. on ruby on rails side, it is fairly very easy. i've built apps with rails and i've always been happy with it. some apps used rails defaults, some apps were very customised. the thing with ror is that it is never getting in your way when you open up your editor and start building your application and that's what i look for in a web framework.
Re: D vs Rust: function signatures
Nick Sabalausky:
On 4/29/2014 9:38 PM, Narrator wrote:
fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self
That looks like line noise.
In D there is a lambda syntax:
auto F = (in int x) = x ^^ 2;
void main() {
int y;
auto G = (in int x) = x + y;
pragma(msg, typeof(F));
pragma(msg, typeof(G));
}
That code contains the types (the pragma output is a little
different):
int function(in int) pure nothrow @nogc @safe
int delegate(in int) nothrow @nogc @safe
An alternative syntax can be similar to the way you write D
lamdas:
(in int) pure nothrow @nogc @safe = int
(in int) nothrow @nogc @safe == int
(I am not suggesting to introduce this syntax to D because its an
useless duplication, but I find it a bit better.)
Bye,
bearophile
Re: D For A Web Developer
On Tuesday, 29 April 2014 at 17:09:53 UTC, Adam D. Ruppe wrote: On Tuesday, 29 April 2014 at 15:55:13 UTC, Etienne wrote: That's funny b/c most people say RoR made them love web development. That's probably because they went into it with very little experience with the alternatives. I was spoiled by my web.d and friends, as well as knowing how to use a real relational database, so getting on the Rails to me is like going back into the stone age. But if you came from mysql 3 and PHP 4 or some other primitive trash, RoR might seem like the best thing ever. I do kinda like the rails console repl tho. Of course, I kinda have that with cgi.d too, you can call its methods on the regular command line pretty easily, but that doesn't let you build up state as easily for quick changes and I do like that. (Maybe I'll offer such with my script.d, should be easy to add :P) the rest of it tho is just awful. Is there any documentation for web.d, including example apps? I'm using vibe.d at the moment and rolled my own customized DOM tree stuff (that was before I knew dom.d existed). I basically implemented the most important JS features for DOM manipulation and added stuff I'd always wanted in JS.
Re: DIP61: redone to do extern(C++,N) syntax
On Wed, 30 Apr 2014 05:03:58 +0100, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
Wrong KISS: compiler internals over specification
Indeed.
I've been a C/C++ developer for ~16 years and I was confused several times
reading this thread.
The mix of D modules and C++ namespaces is the thing what needs to be kept
simple for us lesser mortals, not the compiler implementation - which
should, I agree, *ideally* remain simple, but in this case should be
sacrificed for the other because compiler writers are good at what they do
and will be able to cope.
I think it is simpler all round to just invent (and perhaps reserve) a new
top level module for C++ namespaces (an idea mentioned here already) i.e.
cpp
Example:
module a;
extern(C++, std) class string {..} // identical to decl in b
module b:
extern(C++, std) class string {..} // identical to decl in a
extern(C++, std) class vector {..} // new decl
module userland;
import a;
import b;
void main()
{
cpp.std.string x = new cpp.std.string();
cpp.std.vector y = new cpp.std.vector();
}
Notes:
- the D modules 'a' and 'b' play no part whatsoever in the lookup of the
C++ symbol (why the hell should they? I see no benefit to this)
- the identical declarations in a/b for std.string are treated as one.
- any *use* (in userland) of a non-identical/ambiguous declaration would
result in an error.
Link time is where it would actually complain if multiple C++ symbols were
found.
Special lookup rules would apply to cpp.*
My 2p/c
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: D For A Web Developer
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 module tests at once creates problems than either module is too big or unit tests are not really unit tests.
Re: D For A Web Developer
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. For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based. The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it! Basically my idea is that you register as little as possible. That was why I went with a class for routes. I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important. 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). Right now your approach actually results in more code than stock vibe.d (stand-alone function + explicit route registration).
Re: D For A Web Developer
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 to design simplicity and independence of base vibe.d modules. For example I can't imagine a single case when I'd prefer class-based route definition to stock delegate-based. The classes are unfortunately just a container for routes. So if you got a better way, that can provide the same functionality, I'd love for a plan on how to do it! Basically my idea is that you register as little as possible. That was why I went with a class for routes. I'm really gunning for less, simpler = more. And for medium-large sites thats kinda important. 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 doesn't result in a container is registerRoutes!mymodule; Instead of registerRoute!MyRoute; Now if I could get access to a list of all the modules and hence all routes at CTFE then that wouldn't be an issue. Same deal for models. Basically give me a way that doesn't impose upon the user to manually register a route and the symbol is available at CTFE, then I'll use it. I just don't know it. There is some benefits of having a container for routes however. Being able to add UDAs to that group of routes. I.e. Don't generate javascript, give them a name/grouping. While its possible without it, its a bit more distinct.
Re: DIP61: redone to do extern(C++,N) syntax
On Wed, 30 Apr 2014 10:20:22 +0100, Regan Heath re...@netmail.co.nz
wrote:
Something else to think about.
C# has the same problem and has solved it the following way..
[main.cs]
using ..
using CSTest_Test1;
using CSTest_Test2;
namespace CSTest
{
class Program
{
static void Main(string[] args)
{
Test1.GetLastError(); // class, not namespace required to call
method
Test2.GetLastError(); // class, not namespace required to call
method
}
}
}
[Test1.cs]
using ..
namespace CSTest_Test1
{
public static class Test1
{
[DllImport(coredll.dll, SetLastError = true)]
public static extern Int32 GetLastError();
}
}
[Test2.cs]
namespace CSTest_Test2
{
public static class Test2
{
[DllImport(coredll.dll, SetLastError = true)]
public static extern Int32 GetLastError();
}
}
GetLastError() is always going to unambiguous here because it *must* live
inside a C# class and that class name is *always* required in the call to
it.
If D has replaced classes/namespaces with modules, then the answer to our
problem may be to use the C++ namespace *only* to mangle the symbol, and
*only* use the D module for lookup resolution.
module a;
extern(C++, std) class string {..}
module b:
extern(C++, std) class string {..}
extern(C++, std) class vector {..}
module userland;
import a;
import b;
void main()
{
string x = new string(); //error ambiguous (same resolution as for D
symbols)
a.string x = new a.string(); //ok
b.vector y = new b.vector(); //ok
}
Regan
Re: python vs d
On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
Say you have a Python file with 500 lines of code. Try to copy
and paste something with a different indentation from somewhere
else into an if statement.
Paste in non-formatting-mode and use the editor's ability to
block indent? Having an editor that will indent/unindent regions
when you hit tab/shift-tab helps.
This kind of patronizing bullshit was invented for
non-programmers who might make a mess of the code otherwise.
It is true that Python grew out of a programming language
tradition meant for teaching/prototyping.
But the Python syntax it is more useful for an interpreter prompt
(REPL) than a syntax with explicit begin/end markers. Most of the
non-trivial transformations I do start at the REPL before being
pasted into the editor.
In D you can do this:
if (mode == TEST) { // Second block added later
if (x == 1) { // First block
writeln(Hurray!);
}
}
I think Go did the right thing by not requiring the redundant
parantheses on the if statement and perhaps also by allowing the
omission of semicolons where appropriate etc. Room for improved
legibility right there.
In Python I would probably use «TEST» rather than «mode==test»:
if TEST x == 1:
…
Ola.
Regarding ref results
Below you can find some musings, that perhaps just show my
ignorance of C++11.
The topic is partially related to the of C++11:
http://en.wikipedia.org/wiki/C%2B%2B11#Rvalue_references_and_move_constructors
Sometimes I have to compute hash digests, or to return small but
fixed amounts of data in array for various reasons. There are
many ways to do it in D, a simple way is to return an ubyte[],
but I like static safety (to avoid empty arrays, null pointers,
etc), this is a simple solution:
// Program#1
import std.stdio: writefln;
import std.string: representation;
ubyte[20] sillyHash(in ubyte[] key) pure nothrow @nogc {
typeof(return) result;
foreach (immutable i, ref r; result)
r = (key[i % $] ^ i) % 256;
return result;
}
void main() {
immutable data = some text;
immutable digest = data.representation.sillyHash;
writefln(%-(%02x%), digest);
}
This first solution performs a copy of the output array. (In some
cases a compiler can reserve the array space in the stack frame
of the caller and just return a pointer, return value
optimization). This solution is clean, safe, easy to use, and if
your function is not called many times and the output array is
not too much large, it's a solution I like. Copying small array a
small number of times is cheap enough.
-
If the output array is larger, or you need to call that function
many times and you don't want to pay the copy, you can use
references (you can also use pointers, but they are less safe):
// Program#2
import std.stdio: writefln;
import std.string: representation;
import std.traits: ParameterTypeTuple, Unqual;
void sillyHash2(in ubyte[] key, ref ubyte[20] digest)
pure nothrow @nogc {
foreach (immutable i, ref r; digest)
r = (key[i % $] ^ i) % 256;
}
void main() {
immutable data = some text;
Unqual!(ParameterTypeTuple!sillyHash2[1]) digest;
sillyHash2(data.representation, digest);
writefln(%-(%02x%), digest);
}
This second version is almost equally safe, but it has some
disadvantages:
- You need to define the return variable before the function,
this is not handy for UFCS chains;
- You also need to define the type of the result before calling
the function. Here I have found such type using
ParameterTypeTuple, but this is not so handy, and if the function
becomes a template, you also need to instantiate it to find the
argument type.
- Now the digest variable can't be immutable.
- The code at the call point is longer.
-
A hypothetical version that combines the advantages of the first
two versions:
// Program#3
import std.stdio: writefln;
import std.string: representation;
ref ubyte[20] sillyHash3(ref return digest, in ubyte[] key)
pure nothrow @nogc {
foreach (immutable i, ref r; digest)
r = (key[i % $] ^ i) % 256;
return digest;
}
void main() {
immutable data = some text;
immutable digest = data.representation.sillyHash3;
writefln(%-(%02x%), digest);
}
sillyHash3 has two arguments, but the programmer can only give
the second (all the arguments past the first), the first argument
is handled by the compiler.
The compiler rewrites this sillyHash3 like Program#2 (but with
swapped function arguments, 'digest' is the first).
Despite this syntax idea is not very good, it has the advantage
of being efficient (only a pointer is returned, no array copy),
it's safe, it's clean at the call point, allows to tag the result
as immutable, and it doesn't rely on compiler optimizations like
Program#1 so it's reliably efficient (unless the returned array
is tiny).
The same syntax is also usable for structs:
struct Foo { /*many fields here*/ }
ref Foo bar(ref return f1) {
// Some computation here,
// and f1 fields initialization.
return f1;
}
void main() {
immutable Foo f = bar();
}
Bye,
bearophile
Re: python vs d
On Wednesday, 30 April 2014 at 10:16:12 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
Say you have a Python file with 500 lines of code. Try to copy
and paste something with a different indentation from
somewhere else into an if statement.
Paste in non-formatting-mode and use the editor's ability to
block indent? Having an editor that will indent/unindent
regions when you hit tab/shift-tab helps.
Yes it helps, but a language's syntax / usability should not
depend on tools like editors. Also, what if I want to use an
editor that doesn't support all the fancy formatting stuff?
This kind of patronizing bullshit was invented for
non-programmers who might make a mess of the code otherwise.
It is true that Python grew out of a programming language
tradition meant for teaching/prototyping.
But the Python syntax it is more useful for an interpreter
prompt (REPL) than a syntax with explicit begin/end markers.
Most of the non-trivial transformations I do start at the REPL
before being pasted into the editor.
In D you can do this:
if (mode == TEST) { // Second block added later
if (x == 1) { // First block
writeln(Hurray!);
}
}
I think Go did the right thing by not requiring the redundant
parantheses on the if statement and perhaps also by allowing
the omission of semicolons where appropriate etc. Room for
improved legibility right there.
In Python I would probably use «TEST» rather than
«mode==test»:
if TEST x == 1:
By this you change the substance of the if statement merely for
test purposes, i.e.
if x == 1: if TEST x == 1:
which is not very elegant, and it's error prone (what if you
overlook the TEST bit for release?)
In my D example you leave the essential part untouched. On top of
that, the fact that to if statements are at the same indentation
level makes it easier to spot that there is something unusual
going on there.
Fitted Kitchens Birmingham
Fitted Kitchens Birmingham www.exdisplaykitchens1.co.uk .Fitted kitchens in Birmingham for only £595 including appliances. Full fitted kitchens only £ 5 9 5.Fitted kitchens Birmingham. [url=http://www.budgetkitchenbirmingham.co.uk][B]Fitted Kitchens Birmingham[/B][/url]
Re: Regarding ref results
On Wednesday, 30 April 2014 at 10:22:45 UTC, bearophile wrote:
- You need to define the return variable before the function,
this is not handy for UFCS chains;
- You also need to define the type of the result before calling
the function. Here I have found such type using
ParameterTypeTuple, but this is not so handy, and if the
function becomes a template, you also need to instantiate it to
find the argument type.
Assuming a static array is considered to be a normal aggregate,
the System V ABI defines some of this problem away.
int[10] foo()
{
int[10] a;
//fill a
return a;
}
void bar()
{
foo();
}
becomes assembly equivalent to this, assuming a sensible (not
necessarily very clever) compiler:
void foo(int* ret)
{
int[10] a;
//fill a
ret[0 .. 10] = a[];
}
void bar()
{
int[10] a;
foo(a.ptr);
}
The memory is allocated on stack of caller, and then it passes
the base address in %edi
Perhaps I'm being naive, but it should be trivial for the
optimiser to produce something like:
void foo(int* ret)
{
ret[0 .. 10] = 0; //pessimistic, sometimes elidable.*
//fill ret as if it was an int[10]
}
void bar()
{
int[10] a;
foo(a.ptr);
}
*especially when inlined.
I'm not so familiar with other ABIs, but there are really only 3
choices: 1) allocate in caller, 2) memcopy or 3) return in
multiple registers. I doubt anyone uses 2, 1 is what we see above
and 3 is very cheap (register moves normally cost little).
Re: What's the deal with Warning: explicit element-wise assignment...
On Tuesday, 29 April 2014 at 18:09:00 UTC, bearophile wrote: In Phobos there are awkward names like walkLength walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well.
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 11:20:40 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote: walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well. Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan). walk indicates that you can use a visitor-pattern, thus it is a misleading name. (Not that it matters.) For algorithms execution complexity is not a mere implementation detail. walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach.
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote: walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well. Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan). walk indicates that you can use a visitor-pattern, thus it is a misleading name. (Not that it matters.)
Fitted Kitchens Birmingham
Fitted Kitchens Birmingham www.exdisplaykitchens1.co.uk .Fitted kitchens in Birmingham for only £595 including appliances. Full fitted kitchens only £ 5 9 5.Fitted kitchens Birmingham.
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote: For algorithms execution complexity is not a mere implementation detail. walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach. For you maybe. For me the response is walkLength??? WTF is that? Does this imply a length restricted forEach? I've never seen walk or traverse being used for indicating O(n), it is usually used to indicate something you can utilize in order to traverse a data-structure. That's how the terms are used in CS. Walk is an imperative. walk length indicates walk the length of, not calculate the length of. But naming functions is often more difficult than writing the code. (not a joke)
Re: python vs d
On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote: You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation. I suppose I haven't found the whitespace in Haskell and F# so bothersome because the static type systems catch most of the mistakes at compile time that would occur in Python. Haskell also allows optional braces instead of whitespace (whitespace is just syntactic sugar for braces), which can be quite useful at times, especially when copying code.
Re: python vs d
On 4/30/2014 6:16 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
In D you can do this:
if (mode == TEST) { // Second block added later
if (x == 1) { // First block
writeln(Hurray!);
}
}
Yea, I do that all the time for debugging...*deliberately* since it
makes it trivial to spot the temporary testing code. A language
shouldn't get in my way just because it made a false assumption about my
workflow.
I think Go did the right thing by not requiring the redundant
parantheses on the if statement and perhaps also by allowing the
omission of semicolons where appropriate etc. Room for improved
legibility right there.
Personally, I find Go's reduced parens and such to make it noticeably
harder to read. There's less for my eyes to lock onto when visually
parsing/scanning. YMMV of course.
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 11:35:56 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 30 April 2014 at 11:24:09 UTC, Dicebot wrote: For algorithms execution complexity is not a mere implementation detail. walk' implies exactly that it is O(n) as opposed to O(1) of built-in length properties. It is a wise approach. For you maybe. For me the response is walkLength??? WTF is that? Does this imply a length restricted forEach? And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) walk here implies iteration and iteration implies O(n).
Re: D For A Web Developer
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 look something like this: 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. So I started doing it in reverse: Instead of defining the form in the server-side code and then awkwardly trying to make it generate the HTML I want, I just define the form in HTML. (Or rather, in an HTML template that's still more-or-less valid HTML, with a few additional non-standard tags to help with metadata like how to validate this field). Then I use Adam's dom.d (in non-strict mode) to read the HTML form template (preserving the templating stuff), and automatically infer everything I need to automate the form's behavior (and to strip out the non-standard metadata I added). I've been pretty happy with that so far. It combines the DRY simplicity of define a form in ONE place and it 'just works' with the full power and control of hand-written HTML. What I really need to do is fully de-entange that stuff from my cluttered mess of a homemade web framework https://github.com/Abscissa/SemiTwistWeb and release as a separate cleaned-up lib.
Re: D For A Web Developer
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 doesn't result in a container is registerRoutes!mymodule; Instead of registerRoute!MyRoute; Well you need to specify this only once with root module (usually app.d) supplied as a parameter. You can query all imported modules recursively from it. Now if I could get access to a list of all the modules and hence all routes at CTFE then that wouldn't be an issue. Same deal for models. This can't be done with same guarantees as runtime reflection because of separate compilation. Requirement to transitively to import everything from root module is necessary. I don't see it much of a burden though. There is some benefits of having a container for routes however. Being able to add UDAs to that group of routes. I.e. Don't generate javascript, give them a name/grouping. While its possible without it, its a bit more distinct. 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 reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention.
Re: D For A Web Developer
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 reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist.
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/30/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrei std.algorithm.count also works with any input range, they can use that if they don't like walkLength. Unless it has some limitations? I can't think of any.
Re: D For A Web Developer
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 yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system.
Re: D For A Web Developer
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. Lightweight networking framework. In 1A we have JavaEE, Spring, RoR, Django, Grails, etc. In 2B we have Sinatra, Ratpack, Flask, Bottle, etc. For 2A there is Twisted and 2B asyncio (showing my Python bias here :-) That does seem to happen. 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.
Re: D For A Web Developer
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 have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system. Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides.
Re: D vs Rust: function signatures
On 4/30/2014 3:26 AM, Paulo Pinto wrote: On Wednesday, 30 April 2014 at 01:49:01 UTC, Nick Sabalausky wrote: On 4/29/2014 9:38 PM, Narrator wrote: fn map'r, B(self, f: |A|: 'r - B) - Map'r, A, B, Self That looks like line noise. Not if one is used to ML languages. Beauty is in the eyes of the beholder. :) FWIW, I do agree (Not that I know much about ML-family). The ...to me was carelessly left as implied. ;)
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote: And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) walk here implies iteration and iteration implies O(n). The common term is count, countNodes, countElements etc... Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations? I find fragmented libraries hard to use.
Re: D For A Web Developer
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 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 reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system. Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides. There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place.
Re: D For A Web Developer
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 difference in speed there. 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. But still, one person's productivity is too subjective to focus a lot on IMO.
Re: D For A Web Developer
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 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 reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system. Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides. There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place. The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'. 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.
Re: D For A Web Developer
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: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 yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system. Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides. There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place. The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'. 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. A JIT for D? That would be many, many man-years of work.
Re: D For A Web Developer
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
helper value in the URL params, telling it to evaluate the named
function instead of just trying to convert the data to the right
time.
So for that one, the regular might be /add?a=1b=2. With the
nested call, we want a={the result of /add?a=1b=2)b=3.
So it passes it as something like this: /add? +
urlencode(a=/add?a=1a=2) + b=2a-type=ServerResult;
So the special a-type= tells it that a should not be converted
to an integer, but instead parsed and called.
The same url parser deconstructs it into a function call and gets
the data out (currently, the implementation does it through
string intermediaries for ease; it almost literally replaces that
with the result in the URL, then re-parses it).
This avoids extra calls to the server since it is all done in one
set. There's also ways to filter the results that way, for
example running a querySelector() call on the server to filter a
HTML result for JS.
Then, the JS call itself is either synchronous or asynchronous.
The sync calls are done with the .getSync method. This generally
sucks so I rarely use it, but one cool thing about it is
exceptions from the D side are propagated to the Javascript side,
making error handling natural. (This is also the way my web.d.php
works - it uses PHP's version of opDispatch to make a little
class that translate's PHP function calls to http requests for
talking to the server. It always uses synchronous calls which
sucks btw, but it is awfully easy to use: $a = $Foo-add(1,
2).getSync();)
The asynch ones just do pretty regular AJAX requests with a
callback. The only thing that's interesting is I used the apply
function in JS to make it kinda nice:
return callback.apply(callbackThis, ourArguments);
So things like this kinda works sanely, arguments you pass are
forwarded, etc.
function someFunction(something, another, result) {}
Foo.add(1,2).get(someFunction, hey, this); // will call
someFunction(hey, this, 3);
Naturally, there's on error callbacks too that can work the same
way. D exceptions are passed as JS objects. (Indeed, in general,
all the results from D are passed as objects, it does some
JSON.parse action on the JS side and automatic serialization on
the D side so many things just work.)
Re: D For A Web Developer
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 stacks like the plague. They tend to be lockin solutions. Reminds me of Tango in D1 where you risked pulling in all kinds of dependencies. 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 user experience. - I avoid advanced routing, it adds little and leads to harder to maintain code, give me a regexp based routing table in one location binding request-handlers. - Server side generation should be kept minimal, prevents caching. - Would never consider using serverside javascript generation. What I do want: - Transparent fast distributed in-memory database with logging to a exchangable backing store and with consistency guarantees. - No filesystem dependencies.
Re: D For A Web Developer
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 general, I write what I use, and right now I don't have any significant new D web projects in the pipeline. I still have a couple old ones going, but the new boss said no in switching to D from Ruby (the rest of the team doesn't know it), so the question now is: do I want to spend my nights writing something I won't be using right now or doing something else? for now, the answer is doing something else. That might change eventually tho. in the arena that Twisted used to be king; more vibe.d than web.d. I think the vibe.d folks are doing pretty cool work too. Actually, my web.d could arguably be used with vibe.d; a vibe backend for my cgi.d is a realistic possibility, and then web.d is a pretty straight-forward add-on on top of that. In fact, it might not even be very hard, I just haven't tried yet. (And the other libs are already independent, I think Nick uses my dom.d with vibe already.) Though, my little httpd isn't awful so again, works for me is a lot of inertia to overcome.
Re: D For A Web Developer
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 way it works in mine is the proxy object sets a kinda
magical helper value in the URL params, telling it to evaluate
the named function instead of just trying to convert the data
to the right time.
So for that one, the regular might be /add?a=1b=2. With the
nested call, we want a={the result of /add?a=1b=2)b=3.
So it passes it as something like this: /add? +
urlencode(a=/add?a=1a=2) + b=2a-type=ServerResult;
So the special a-type= tells it that a should not be
converted to an integer, but instead parsed and called.
The same url parser deconstructs it into a function call and
gets the data out (currently, the implementation does it
through string intermediaries for ease; it almost literally
replaces that with the result in the URL, then re-parses it).
This avoids extra calls to the server since it is all done in
one set. There's also ways to filter the results that way, for
example running a querySelector() call on the server to filter
a HTML result for JS.
Then, the JS call itself is either synchronous or asynchronous.
The sync calls are done with the .getSync method. This
generally sucks so I rarely use it, but one cool thing about it
is exceptions from the D side are propagated to the Javascript
side, making error handling natural. (This is also the way my
web.d.php works - it uses PHP's version of opDispatch to make a
little class that translate's PHP function calls to http
requests for talking to the server. It always uses synchronous
calls which sucks btw, but it is awfully easy to use: $a =
$Foo-add(1, 2).getSync();)
The asynch ones just do pretty regular AJAX requests with a
callback. The only thing that's interesting is I used the apply
function in JS to make it kinda nice:
return callback.apply(callbackThis, ourArguments);
So things like this kinda works sanely, arguments you pass are
forwarded, etc.
function someFunction(something, another, result) {}
Foo.add(1,2).get(someFunction, hey, this); // will call
someFunction(hey, this, 3);
Naturally, there's on error callbacks too that can work the
same way. D exceptions are passed as JS objects. (Indeed, in
general, all the results from D are passed as objects, it does
some JSON.parse action on the JS side and automatic
serialization on the D side so many things just work.)
I see I see. I was assuming there wasn't too much changed on the
server side. And mostly in javascript. Netherless quite
interesting and advanced usage.
Perhaps it could spawn some changes to the router. And hence the
ajax route generation.
Re: D For A Web Developer
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 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 have added it as one of examples for my DConf talk just yesterday :) This list, however, can possibly be built automatically via reflection provided single root entry point. I think good flexible framework should provide user both options and infer as much as possible by convention. Hmm interesting idea, although I'd feel a lot happier about it if the compiler was able to (with a switch most likely) infer/create automatically package.d files with auto import of all sub modules if it doesn't exist. Sounds like typical use case for imaginary dub plugin system. Perhaps but in the compiler, the file system wouldn't actually be changed. And the explicit package.d files would merely be overrides. There's nothing stopping you from automatically making a temporary directory structure for building. No need to alter it in-place. The way this discussion is going I'll have a new build manager built specifically for web development. This is where I'm gonna say 'no'. 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. A JIT for D? That would be many, many man-years of work. Nah written in D. But in saying that, it would probably be one of the first languages I'd have a go at.
Re: D For A Web Developer
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 class D expert but a RoR n00b, so there's naturally some difference in speed there. 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. But still, one person's productivity is too subjective to focus a lot on IMO. Calculated dishonesty is healthy in a marketing campaign :p
Re: D For A Web Developer
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 bytecode take the form of D functions (such as int16 addI16(int16 a, int16 b), for instance) so you're essentially generating an array of D functions then iterating over them evaluating them. This would obviously be slower than generating assembly directly, but would still be faster than an interpreter, and you could still do some optimisation on it.
Re: D For A Web Developer
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 understand assembly to write a JIT. You could instead have your bytecode take the form of D functions (such as int16 addI16(int16 a, int16 b), for instance) so you're essentially generating an array of D functions then iterating over them evaluating them. This would obviously be slower than generating assembly directly, but would still be faster than an interpreter, and you could still do some optimisation on it. Been there. Drunmeta [0]. Theres a reason why I'm not going down that road anymore ;) [0] https://github.com/rikkimax/drunmeta
Re: D For A Web Developer
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 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. 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 results easier). Now, if I run all tests I will get output from all the tests, not the one I'm trying to debug. That's really annoying.
Re: D For A Web Developer
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 results easier). Now, if I run all tests I will get output from all the tests, not the one I'm trying to debug. That's really annoying. Output from the failing test will always be the last one in console. Pipe to tail - profit. This sounds as pure aesthetics issue.
Re: python vs d
On Wednesday, 30 April 2014 at 11:46:32 UTC, Nick Sabalausky
wrote:
On 4/30/2014 6:16 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
In D you can do this:
if (mode == TEST) { // Second block added later
if (x == 1) { // First block
writeln(Hurray!);
}
}
Yea, I do that all the time for debugging...*deliberately*
since it makes it trivial to spot the temporary testing code. A
language shouldn't get in my way just because it made a false
assumption about my workflow.
Yep. Good to know I'm not the only one who does this all the time
:-)
I think Go did the right thing by not requiring the redundant
parantheses on the if statement and perhaps also by allowing
the
omission of semicolons where appropriate etc. Room for improved
legibility right there.
Personally, I find Go's reduced parens and such to make it
noticeably harder to read. There's less for my eyes to lock
onto when visually parsing/scanning. YMMV of course.
Re: D For A Web Developer
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 couple of
writefln instead of using a debugger (it's faster and I get
formatted results easier).
Now, if I run all tests I will get output from all the tests, not the
one I'm trying to debug. That's really annoying.
Output from the failing test will always be the last one in console. Pipe to
tail - profit. This sounds as pure aesthetics issue.
What I usually do is to be writefln at the start and end of the failing
test, so I know exactly which part of the output belongs to the failure:
unittest {
writeln(Starting failing test);
... // stuff
writeln(debug value = %s, ...);
... // stuff
writeln(End failing test);
}
Then just pipe it to:
sed -ne/^Starting\ failing\ test/,/^End\ failing\ test/p
and you're good to go. :-) (The End message is there so that you're
sure the failure is coming from this test, not somewhere else, and also
serves as an indicator of when the problem gets fixed and it moves on to
the next test.)
T
--
It's amazing how careful choice of punctuation can leave you hanging:
Re: python vs d
On Tuesday, 29 April 2014 at 14:59:25 UTC, logicchains wrote: An argument for zero-based indexing from Dijkstra: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html Well, indeed, it's impossible to select an empty subrange with convention c (pascal?). Is it a problem? Simply use null instead of an empty range.
Re: D For A Web Developer
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
manipulation and added stuff I'd always wanted in JS.
Yeah, dom.d is kinda my magical group of nice convenience too.
The .addChild() helper makes building a tree in code so simple
that I rarely even thing about innerHTML anymore.
addChild takes a tag name and two child strings which are
customized based on the tag name:
addChild(a, Link test, http://link-target.com/;); // makes
a href=httppLink test/a
addChild(span, foo, bar); // makes span
class=barfoo/span
addChild(div, Html(blol/b)); // divblol/b/div
(normally, the second argument is innerText and the third
argument is the big customization point.)
dom.d's Form class makes them stupid-simple to use too.
auto form = document.requireSelector!Form(#my-form);
form.setValue(something, else);
setValue finds the element with that particular name and sets teh
value based on what it is. So if it is an input, it sets value.
If it is a textarea, it sets innerText. If it is select, it
sets the attribute on the right option, or can add an option if
needed. It can also implicitly create a hidden element if needed.
The Link class has a similar function for link URL params.
And, of course, these can be done in a loop:
void forwardParams() {
foreach(k, v; cgi.post)
form.setValue(k, v);
}
so simple!
Re: D For A Web Developer
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 model of tree-generation when
branching in Or! steps.
Then, the interpretation stage can re-create the D environment with hash
maps of a Entity Variant of D types, functions, values and
instantiations added with their respective identifiers, each as a single
Entity struct containing their instructions as a simple array.
e.g. struct Entity { Entity[] scope; Entity[] instructions }
Once that's done, you should have all your types and objects in
HashMaps, ready to execute with an entry point. You move through the
instructions with a foreach loop by looking up function calls and
expecting the appropriate return type.
Call me crazy, but I think typed variants would be easier and faster to
handle than the regular casting methods that interpreted languages use
currently.
Anyway, the hardest part again would be to write a good garbage collector.
Re: D For A Web Developer
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. Aye, I rarely use my automatic forms on live sites either but they are really nice for backend CRUD stuff or a quick-n-dirty first-draft. Sometimes though, I can get away with just modifying an automatic form and kinda want to make web.d 2.0 better at that. Instead of defining the form in the server-side code and then awkwardly trying to make it generate the HTML I want, I just define the form in HTML. (Or rather, in an HTML template that's still more-or-less valid HTML, with a few additional non-standard tags to help with metadata like how to validate this field). Yes, rox rox rox. This is what my html.d originally was for btw, expanding non-standard tags. Many of them are obsolete now tho, I use html5 attributes instead. Of course, html.d also includes other cool stuff like CSS expansion and JS foreach macros too, as we fairly recently talked about. 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 well-formedness, not validation. So it accepts custom tags and attributes easily enough.
Re: D For A Web Developer
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 (it's faster and I get formatted results easier). Now, if I run all tests I will get output from all the tests, not the one I'm trying to debug. That's really annoying. Output from the failing test will always be the last one in console. Pipe to tail - profit. This sounds as pure aesthetics issue. 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...
Re: python vs d
On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote: which is not very elegant, and it's error prone (what if you overlook the TEST bit for release?) I'd probably tie it to DEBUG and make sure it has the correct value whenever DEBUG is false. No need to remove it before release. Ola.
Re: D For A Web Developer
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 user experience. I don't really agree, I do as much work as I can on the server, I like the AJAX stuff to be as stupid simple as setting innerHTML. (Indeed, web.d's automatic javascript has helper functions for this: Server.getSomeData(args).useToReplace(some_element); ) It makes it a lot simpler and gives good compatibility since the client is pretty thin. - I avoid advanced routing, it adds little and leads to harder to maintain code, give me a regexp based routing table in one location binding request-handlers. aye, I think routing is generally ridiculous. - 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. Of course, doing things on the server may not need to be cached anyway because you don't have the lag of a million http requests in putting it together.
Re: D For A Web Developer
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 data point is not data but a lot of them is. Every anecdote carries some weight. And even as one person, there are probably a non-trivial number of people who think roughly the same way and would benefit from...err, from being proselytised? ;) -Wyatt
Re: D For A Web Developer
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-other-tests. For integration testing you need some different approach where being able to run separate cases is indeed useful. But it is not a fault of D _unit_ test design.
Re: D For A Web Developer
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 need to
implement it myself.
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 almost always need some kind of customization for
our specific case anyway!
There's a few exceptions where something is hard to write, but
most things just aren't that hard.
But unit tests in D suck as well.
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 method
still in use.
In D, you just recompile and those things are found almost
instantly without needing to actually run any code.
How do you mean? It just adds an object oriented layer on top
of it.
They deliberately avoid the most important parts of a relational
database:
http://guides.rubyonrails.org/migrations.html
The Active Record way claims that intelligence belongs in your
models, not in the database. As such, features such as triggers
or foreign key constraints, which push some of that intelligence
back into the database, are not heavily used.
ORM is something I only like in very small quantities, but
ActiveRecord uses it for *everything*, well, except for the
things it doesn't even support.
The problem here is one of encapsulation and of correctness. If
something bypasses the model - which is required for tasks the
library doesn't even support and also likely to happen if there's
a second app using the data - all kinds of stuff can get in there
that is bad.
You also have problems like race conditions:
account = BankAccount.find(1)
account.balance -= 10
account.save!
What if two of those run concurrently? I searched the web quickly
for this and haven't found a good answer yet...
Then, with referential integrity, the docs suggest DIY or getting
some third party gem, because their godawful library doesn't
really support it. The best it does is offer you a square wheel
with the dependent thing. Stupid stupid stupid.
When you actually use the database as it is intended, it takes
care of these things for you with very easy syntax that works
across business logic languages. Nothing new to learn there.
BTW, what should I use in D. I need a library that is database
independent and I don't want to write SQL for the common use
cases?
idk, I use my database.d which has a little bit of overlap with
what active record does, but since I generally see ORM as being a
nasty anti-pattern and horribly leaky abstraction, I didn't go
far with it.
There's really nothing to fear with writing SQL, except the cases
where the language sucks. (UPDATE and INSERT being so different,
and the solutions being different for the various vendors, ugh.
That's why I made my DataObject, it gathers the changes together
then issues one of those commands. It can also be gotten from a
query, making it a kind of simple active record:
auto obj = mysql.queryDataObject(select * from foo limit
1).front;
obj.whatever = something;
obj.commitChanges(); // calls UPDATE foo SET whatever='something'
WHERE id = ?
which also works on joined queries on MySQL btw and offers easy
support for multiple primary keys or ones not named id (as an
argument to commitChanges), something active record as far as i
can tell doesn't even try to do, but it doesn't try to fetch
child objects or anything like that.
I have considered adding child object fetching, but I don't
really see the need, it is easy to write a method that does that
if you want to.)
I prefer HAML (similar to Jade in vibe.d) but I don't think
it's that bad. What do you use?
The ruby thing looks like this span class=foo%= @some_value
%/span.
For my D stuff, I have two options:
1) create the HTML right in D using dom.d. I like to use this for
objects that know how to format themselves and output strictly
semantic XML/HTML. The visual styling is then done with CSS. This
works better than you might expect!
2) web.d also has a fairly simple replacement system too:
span class=foo{$some_value}/span
it also supports inserting partials
div html-from={$dynamic_html}/div or include partial=foo
/, though the include thing takes a wee bit of helper code from
the app because it needs to find the html somewhere.
And the variable replacement can be piped: {$some_count|plural
user users} for example, which is kinda cool.
It does NOT support intertwined code. Other things are done with
Re: Default arguments in function callbacks not taken into account when instantiating templates has huge security implications
On 4/29/14, Wyatt via Digitalmars-d digitalmars-d@puremagic.com wrote: I'm sorry, but can you explain how this lets an attacker learn anything useful? Maybe I over-exaggerated a little bit here. On 4/29/14, Kenji Hara via Digitalmars-d digitalmars-d@puremagic.com wrote: This is a compiler bug. Ok, I thought it was maybe by design. I remember there being a similar issue with function pointers not being distinct w.r.t. default arguments. There's a bugzilla issue where Walter comments on it. I'm not sure about the issue number though.
Re: D For A Web Developer
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 different types of files and caching strategies: 1. static files (the ones that never change can be stored at edge caches) 2. pregenerated files (files served from Amazon AWS, Google Cloud Storage, CDNs) 3. proxy cachable files / client cachable files 4. server memcached files 5. fully dynamic files Ola.
Re: D For A Web Developer
On 4/30/2014 9:47 AM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com 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 with the lightweights.
Ugh, avoid the full stacks like the plague. They tend to be lockin
solutions. Reminds me of Tango in D1 where you risked pulling in all
kinds of dependencies.
You might dislike this, but I think nimble servers and clean separation
with javascript heavy clients are the future.
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.
That said, I don't have an issue with fat clients in general. I usually
tend to prefer them (ex: desktop email client). Just not when the fat
client happens to be inside a web browser, because that tends to not be
fat client so much as needlessly bloated client with an awkward,
temperamental UI (example: MS Word and OpenOffice have never lost one
keystroke for me from a network hiccup or anything equally trivial).
What I don't want:
- I have started to avoid server processing of forms, javascript/ajax
gives better user experience.
JS can definitely help improve the UX of form validation, no doubt about
that, but it's important to remember that server-side validation is
still necessary anyway, regardless of what you do on the client.
- I avoid advanced routing, it adds little and leads to harder to
maintain code, give me a regexp based routing table in one location
binding request-handlers.
Same here. I don't like having my available HTTP interfaces scattered
across my codebade, and I definitely don't like having them implicit
based on member-function visibility (I've used such frameworks before.
Not personally my cup of tea).
What I *do* love is having a canonical table defining my entire HTTP
interface in one easy location. The extra typing or non-DRYness of that
is a mere triviality in my experience (and I'm normally a huge DRY buff).
- Server side generation should be kept minimal, prevents caching.
Ehh, yes and no. Server side generation is usually fine, just not when
it's done more often than necessary. And traditional server-side web
technologies definitely tend to do it more than necessary,
For example, consider a page containing a blog post with (non-Disqus)
user comments:
It's a complete waste for the server to regenerate such a page upon
every request, PHP/ASP-style. That's because it doesn't *change* upon
every viewing - it only changes on every post and edit (and not even
every one of those, if there's enough comments to trigger paging).
So unless the page's rate of comment submissions/edits approaches the
rate of comment views (unlikely...except maybe on YouTube ;) ), then
it's best to re-generate upon posts/edits and then cache that. So you
still get caching benefits, but with no need to make *all* the clients
duplicate the exact same page-generating effort as each other upon every
viewing.
Supporting login stuff (ex: Hello, [your name here]! Logout?) doesn't
really mess this up either. The vast majority of the page can still be
cached by the server. Then, generating it for each user doesn't need
to be anything more resource-intensive than this:
void loginUser(string name)
{
session.user.loggedIn = true;
session.user.name = name;
// Whatever template engine you want:
session.user.loggedInUI =
`Hello b`~name~`/b! a href=/logoutLogout/a`;
}
enum commonLoggedOutUI =
`Login: formUsername:input... Pass:input.../form`;
void showMyPage(OutRange response, User user)
{
// myPage was automatically split into parts A and B
// last time it was updated:
response.put(myPagePartA);
if(session.user.loggedIn)
response.put(session.user.loggedInUI);
else
response.put(commonLoggedOutUI);
response.put(myPagePartB);
}
- Would never consider using serverside javascript generation.
Heh, I've actually done that on old-style ASP (ages ago). It was both
confusing and interesting.
What I do want:
- Transparent fast distributed in-memory database with logging to a
exchangable backing store and with consistency guarantees.
- No filesystem dependencies.
I'll take those, plus a large vanilla latte, please. :) Thank you, come
again!
A few considerations on garbage collection
I'm mulling over a couple of design considerations for allocators, and
was thinking of the following restriction:
1. No out-of-bounds tricks and no pointer arithmetic. Consider:
int[] a = new int[1000];
a = a[250 .. 750];
int* p = a[500 .. $].ptr;
Subsequently the GC should be within its rights to deallocate any memory
within the first and last 250 integers allocated, even though in theory
the user may get to them by using pointer arithmetic.
In particular that means once a slice is shrunk, there's no growing back
unless another slice is around.
I think the current GC already does that.
2. The same may be the case for classes WITHOUT destructors. Consider:
class A
{
int[1000] a;
int b;
int[1000] c;
}
int* p = (new A).b;
The collector should be allowed to deallocate any memory except b's own,
even though that means the class has holes in it. The current GC does
not do that.
2. However, the same shall not be the case for classes with destructors.
Consider:
class B
{
int[1000] a;
int b;
int[1000] c;
~this() { ... }
}
int* p = (new B).b;
This class has a destructor, so it will be kept around in its entirety
if an internal pointer is held.
3. Classes meant to have destructors called at collection will ALWAYS
have been allocated with new (i.e. won't start in the middle of some
other allocation). In other words, only class objects created with new
will be properly collected. Those forced in odd places with emplace()
are the responsibility of the user.
4. Currently, struct objects created with new do NOT have their
destructors called during collection. I think this may continue, meaning
that structs created with new are somewhat low-level and are meant to be
destroyed and deallocated manually.
5. This brings up arrays of structs. As far as I understand, destructors
will never be called for these, even after all references are gone:
struct S { ~this() { ... } }
auto a = new S[100];
Unlike (4), arrays of structs are high-level and frequently used. I
think we must do something about it, so I plan to support calling
destructors for arrays of structs.
6. The point above brings to mind more radical possibilities, such as
making all arrays reference-counted and allowing compulsive deallocation
when the reference counter goes down to zero. That would rule out things
like escaping pointers to data inside arrays, which is quite extreme.
But probably worth bringing up in a brainstorming. If we disallow
statically constructs that take addresses we may get away with it.
Please chime in with your thoughts.
Andrei
Parallel execution of unittests
Hello,
A coworker mentioned the idea that unittests could be run in parallel
(using e.g. a thread pool). I've rigged things to run in parallel
unittests across modules, and that works well. However, this is too
coarse-grained - it would be great if each unittest could be pooled
across the thread pool. That's more difficult to implement.
This brings up the issue of naming unittests. It's becoming increasingly
obvious that anonymous unittests don't quite scale - coworkers are
increasingly talking about the unittest at line 2035 is failing and
such. With unittests executing in multiple threads and issuing e.g.
logging output, this is only likely to become more exacerbated. We've
resisted named unittests but I think there's enough evidence to make the
change.
Last but not least, virtually nobody I know runs unittests and then
main. This is quickly becoming an idiom:
version(unittest) void main() {}
else void main()
{
...
}
I think it's time to change that. We could do it the
non-backward-compatible way by redefining -unittest to instruct the
compiler to not run main. Or we could define another flag such as
-unittest-only and then deprecate the existing one.
Thoughts? Would anyone want to work on such stuff?
Andrei
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/30/14, 4:20 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Wednesday, 30 April 2014 at 11:13:46 UTC, John Colvin wrote: walkLength is a really good name. Clear, concise, to the point. It's not often that you can make such a short name that explains the behaviour so well. Actually it isn't a good abstraction as it exposes implementation internals. The name should indicate what you get (the calculating of a result), not how the framework obtains it (sequential scan). Making complexity an implementation detail is an antipattern. -- Andrei
Re: D For A Web Developer
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 an ability to run specific unittests.
Re: D For A Web Developer
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 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. 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 results easier). Now, if I run all tests I will get output from all the tests, not the one I'm trying to debug. That's really annoying. Yah, naming unittests is key here. With names one can specify which to run/not run, regex patterns (i.e. run only quick*) etc. -- Andrei
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/30/14, 5:58 AM, Andrej Mitrovic via Digitalmars-d wrote: On 4/30/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: On 4/29/14, 11:08 AM, bearophile wrote: In Phobos there are awkward names like walkLength Love it. -- Andrei std.algorithm.count also works with any input range, they can use that if they don't like walkLength. Unless it has some limitations? I can't think of any. Yah, they overlap in functionality but only somewhat. walkLength is O(1) on ranges with length, and it allows a convenient up to parameter. Andrei
Re: What's the deal with Warning: explicit element-wise assignment...
On 4/30/14, 6:18 AM, Ola Fosheim Grøstad ola.fosheim.grostad+dl...@gmail.com wrote: On Wednesday, 30 April 2014 at 11:52:14 UTC, Dicebot wrote: And that would have been quite a close guess actually as walkLength is constrained to accept only finite InputRanges :) walk here implies iteration and iteration implies O(n). The common term is count, countNodes, countElements etc... Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations? That would be an awful idea. -- Andrei
Re: Parallel execution of unittests
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in
parallel
In D we have strong purity to make more safe to run code in
parallel:
pure unittest {}
We've resisted named unittests but I think there's enough
evidence to make the change.
Yes, the optional name for unittests is an improvement:
unittest {}
unittest foo {}
I am very glad your coworker find such usability problems :-)
We could do it the non-backward-compatible way by
redefining -unittest to instruct the compiler to not run main.
Good.
I'd also like some built-in way (or partially built-in) to use a
module only as main module (to run its demos) or as module to
be imported. This problem is solved in Python with the if
__name__ == __main__: idiom.
Bye,
bearophile
Re: A few considerations on garbage collection
On 4/30/14, 8:33 AM, Andrei Alexandrescu wrote: int[] a = new int[1000]; a = a[250 .. 750]; int* p = a[500 .. $].ptr; Here I meant: int[] a = new int[1000]; int* p = a[500 .. $].ptr; a = a[250 .. 750]; Andrei
Re: Parallel execution of unittests
Am Wed, 30 Apr 2014 08:43:31 -0700 schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org: However, this is too coarse-grained - it would be great if each unittest could be pooled across the thread pool. That's more difficult to implement. I filed a pull request which allowed running unit tests individually (and in different threads*) two years ago, but didn't pursue this further: https://github.com/D-Programming-Language/dmd/pull/1131 https://github.com/D-Programming-Language/druntime/pull/308 To summarize: It provides a function pointer for every unit test to druntime or user code. This is actually easy to do. Naming tests requires changes in the parser, but I guess that shouldn't be difficult either. * Some time ago there was a discussion whether unit tests can rely on other tests being executed first / execution order. AFAIK some phobos tests require this. That of course won't work if you run the tests in different threads.
Re: python vs d
On Wednesday, 30 April 2014 at 14:57:44 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote: which is not very elegant, and it's error prone (what if you overlook the TEST bit for release?) I'd probably tie it to DEBUG and make sure it has the correct value whenever DEBUG is false. No need to remove it before release. Ola. I think it is not feasible to tie everything to DEBUG. Debug is a signpost that marks well-defined problem zones. Often I need just a little writefln() statement somewhere in the code to see what is going on / wrong in a certain block. The simplest example is to insert writeln() simply to see up to which point it prints before the app crashes. Believe it or not, I find this technique very efficient in certain situations. Python often gets in my way when micro-debugging in this way, because of indentation terror.
Re: Parallel execution of unittests
On 4/30/14, 8:54 AM, bearophile wrote:
Andrei Alexandrescu:
A coworker mentioned the idea that unittests could be run in parallel
In D we have strong purity to make more safe to run code in parallel:
pure unittest {}
This doesn't follow. All unittests should be executable concurrently. --
Andrei
Re: D For A Web Developer
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 well-formedness, not validation. So it accepts custom tags and attributes easily enough. 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). IIRC, I think there were some cases where the my templates involved some non-well-formedness that the DOM's non-strict mode was perfectly happy with. Whatever it was, I'm sure there was *something* I was doing that strict mode was tripping up on. May have been an old version of the DOM, too. Granted there are still things I have to refrain from doing in my HTML form templates because it would violate well-formedness *too much* even for an ultra-relaxed HTML DOM. But those cases always have other (arguably more sanitary) ways to accomplish the same thing.
Re: A few considerations on garbage collection
On Wednesday, 30 April 2014 at 15:33:29 UTC, Andrei Alexandrescu
wrote:
4. Currently, struct objects created with new do NOT have their
destructors called during collection. I think this may
continue, meaning that structs created with new are somewhat
low-level and are meant to be destroyed and deallocated
manually.
5. This brings up arrays of structs. As far as I understand,
destructors will never be called for these, even after all
references are gone:
struct S { ~this() { ... } }
auto a = new S[100];
Unlike (4), arrays of structs are high-level and frequently
used. I think we must do something about it, so I plan to
support calling destructors for arrays of structs.
Although it would be a breaking change, I am intending to propose
that the destructors of heap-allocated structs be handled in the
same way as destructors of classes in my GC implementation. I am
also intending to propose a guarantee that, if the program exits
normally, all destructors will be invoked before the application
ends. To help facilitate this I intend to have a thread dedicated
to calling destructors. I'm still working on typing out the
entire design of the GC, but I don't currently see a reason
(design-wise) why I'd have to change these things.
Re: Parallel execution of unittests
On 4/30/14, 8:54 AM, Johannes Pfau wrote:
Am Wed, 30 Apr 2014 08:43:31 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
However, this is too
coarse-grained - it would be great if each unittest could be pooled
across the thread pool. That's more difficult to implement.
I filed a pull request which allowed running unit tests individually
(and in different threads*) two years ago, but didn't pursue this
further:
https://github.com/D-Programming-Language/dmd/pull/1131
https://github.com/D-Programming-Language/druntime/pull/308
To summarize: It provides a function pointer for every unit test to
druntime or user code. This is actually easy to do. Naming tests
requires changes in the parser, but I guess that shouldn't be difficult
either.
That's fantastic, would you be willing to reconsider that work?
* Some time ago there was a discussion whether unit tests can rely on
other tests being executed first / execution order. AFAIK some phobos
tests require this. That of course won't work if you run the tests in
different threads.
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared this() { Runtime.unittestThreads = 1; }
Andrei
Re: Parallel execution of unittests
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared this() { Runtime.unittestThreads = 1; }
Andrei
Named tested seems like a no brainier to me.
Maybe nested unittests?
unittest OrderTests {
// setup for all child tests?
unittest a {
}
unittest b {
}
}
I also wonder if its just better to extend/expose the unittest API for
more advanced things like order of execution, test reporting, and parallel
execution. And we can just support an external unittesting library to do
all the advanced testing options.
Re: Parallel execution of unittests
On Wednesday, 30 April 2014 at 15:43:35 UTC, Andrei Alexandrescu
wrote:
Hello,
A coworker mentioned the idea that unittests could be run in
parallel (using e.g. a thread pool). I've rigged things to run
in parallel unittests across modules, and that works well.
However, this is too coarse-grained - it would be great if each
unittest could be pooled across the thread pool. That's more
difficult to implement.
This brings up the issue of naming unittests. It's becoming
increasingly obvious that anonymous unittests don't quite scale
- coworkers are increasingly talking about the unittest at
line 2035 is failing and such. With unittests executing in
multiple threads and issuing e.g. logging output, this is only
likely to become more exacerbated. We've resisted named
unittests but I think there's enough evidence to make the
change.
Last but not least, virtually nobody I know runs unittests and
then main. This is quickly becoming an idiom:
version(unittest) void main() {}
else void main()
{
...
}
I think it's time to change that. We could do it the
non-backward-compatible way by redefining -unittest to instruct
the compiler to not run main. Or we could define another flag
such as -unittest-only and then deprecate the existing one.
Thoughts? Would anyone want to work on such stuff?
Andrei
An existing library implementation:
https://github.com/atilaneves/unit-threaded
Re: Parallel execution of unittests
On 4/30/14, 9:19 AM, Byron wrote:
On Wed, 30 Apr 2014 09:02:54 -0700, Andrei Alexandrescu wrote:
I think indeed a small number of unittests rely on order of execution.
Those will be still runnable with a fork factor of 1. We'd need a way to
specify that - either a flag or:
static shared this() { Runtime.unittestThreads = 1; }
Andrei
Named tested seems like a no brainier to me.
Maybe nested unittests?
unittest OrderTests {
// setup for all child tests?
unittest a {
}
unittest b {
}
}
I wouldn't want to get too excited about stuff without there being a
need for it. We risk overcomplicating things (i.e what happens inside
loops etc).
I also wonder if its just better to extend/expose the unittest API for
more advanced things like order of execution, test reporting, and parallel
execution. And we can just support an external unittesting library to do
all the advanced testing options.
That would be pretty rad.
Andrei
Re: Parallel execution of unittests
On 4/30/14, 9:24 AM, QAston wrote: An existing library implementation: https://github.com/atilaneves/unit-threaded Nice! The Warning: With dmd 2.064.2 and the gold linker on Linux 64-bit this code crashes. is hardly motivating though :o). I think this project is a confluence of a couple others, such as logging and a collection of specialized assertions. But it's hard to tell without documentation, and the linked output https://github.com/atilaneves/unit-threaded/blob/master/unit_threaded/io.d does not exist. Andrei
Re: D For A Web Developer
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 either, but I think websites are getting more usable now. For a while it was a shitty stuttering mess of HTML and JS that made me longing for an AntiWeb browser with community maintained per-site AI that turns the horrible HTML-mess into semantic markup that you can style yourself. I actually have a file called antiweb.d here… ;) I also had high hopes for XSLT. I remember requiring studentprojects to serve XML from the server, and transform it to HTML using XSLT in the browser back in 2002 or so. And XSLT support was actually quite good, at least until the mobile shit hit the fan. Unfortunately connections were still slow so XSLT based rendering had to wait until the whole XML was downloaded. Today I think it might work out quite nicely, but I doubt anyone even remembers that browser can do XSLT today. Actually, I am not even sure if they all still support it? The weird thing is that SEO and search engine priorities are the ones that keep the dynamic websites from going fully dynamic by their anti-dynamic measures (punishing non-static content) and they are also the ones that are pushing semantic markup such as itemscope/itemprop microdata. 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 am not even going to use the term «a pile of junk» which would suggest that there is some sense of structure to it. I think it is more like a scattered mutating spaghetti dinner gone terribly wrong, slowly emerging from every toilet in every household taking over the earth… like the classic horror movies from the 1950s. JS can definitely help improve the UX of form validation, no doubt about that, but it's important to remember that server-side validation is still necessary anyway, regardless of what you do on the client. Yup. So a must have is a good infrastructure for specifying database invariants and transactions. Ideally it should execute like a stored procedure thus leaving the server logic pretty clean. What I *do* love is having a canonical table defining my entire HTTP interface in one easy location. The extra typing or non-DRYness of that is a mere triviality in my experience (and I'm normally a huge DRY buff). Yep, it also acts like always-up-to-date documentation when you come back to the source code 6 months later trying to figure out the main structure. So unless the page's rate of comment submissions/edits approaches the rate of comment views (unlikely...except maybe on YouTube ;) ), then it's best to re-generate upon posts/edits and then cache that. So you still get caching benefits, but with no need to make *all* the clients duplicate the exact same page-generating effort as each other upon every viewing. Well, I would probably use JS… ;-) But I am pragmatic. Caching and pregeneration can lead to bugs and complications. So it is usually a good idea to just do a dynamic version first and then add caching when needed. I also sometimes use a dynamic template during development, and then just save a static version for release if I know that it won't change. I'll take those, plus a large vanilla latte, please. :) Thank you, come again! You're welcome! I think it is realistic now for smaller sites (say 1-8 servers) where you have enough RAM to hold perhaps 10 times the information the site will ever provide. One should be able to sync 8 servers that have relative few write operations easily. So, reading the log might take some time during startup, but with an efficient format… it probably could complete quickly for 1GB of data.
Re: python vs d
On Wednesday, 30 April 2014 at 11:41:29 UTC, logicchains wrote: On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote: You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation. I suppose I haven't found the whitespace in Haskell and F# so bothersome because the static type systems catch most of the mistakes at compile time that would occur in Python. Haskell also allows optional braces instead of whitespace (whitespace is just syntactic sugar for braces), which can be quite useful at times, especially when copying code. Right, it's not the significant indentation which perplexes you, but the complete lack of compile time checking from Python. I'm perplexed that anyone could prefer that too, but I suppose those programmers who are way smarter than me and don't make any mistakes find types burdensome, or are always writing correct code that can't be type checked by any current checker.
Re: What's the deal with Warning: explicit element-wise assignment...
On Wednesday, 30 April 2014 at 15:51:09 UTC, Andrei Alexandrescu wrote: Why all the specialized functions in algorithm.d? Why not just have a default predicate that is always true and do compile time optimizations? That would be an awful idea. -- Andrei Why? By having a gazillion functions doing almost the same thing you are moving away from generic programming…
Re: D For A Web Developer
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 method still in use. 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. Anytime I use them, they just create more work for me. Writing more sanity checks. More hours debugging. More work to optimize hotspots. More time figuring out Tracebacks I'm getting from code I didn't even write or from tools I'm simply trying to install. Etc. In D, you just recompile and those things are found almost instantly without needing to actually run any code. Gotta love it :)
Re: Parallel execution of unittests
Am Wed, 30 Apr 2014 09:28:18 -0700
schrieb Andrei Alexandrescu seewebsiteforem...@erdani.org:
I also wonder if its just better to extend/expose the unittest API
for more advanced things like order of execution, test reporting,
and parallel execution. And we can just support an external
unittesting library to do all the advanced testing options.
That would be pretty rad.
We can kinda do that.
I guess the main problem for a simple approach is that unittests are
functions but advanced frameworks often have unittest classes/objects.
We can't really emulate that on top of functions.
What we can easily do is parse UDAs on unittests and provide access to
these UDAs. For example:
module my.testlib;
struct Author
{
string _name;
string serialize() {return _name;} //Must be evaluated in CTFE
}
module test;
import my.testlib;
@Author(The Author) unittest
{
//Code goes here
}
Then with the mentioned pull request we just add another field to the
runtime unittest information struct: An associative array with string
keys matching the qualified name of the UDA and as values the strings
returned by serialize() (evaluated by CTFE).
Then we have for the test runner:
foreach( m; ModuleInfo )
{
foreach(test; m.unitTests)
{
if(my.testlib.Author in test.uda)
writefln(Author: %s, test.uda[my.testlib.Author]);
}
}
This is some more work to implement though, but it's additive so we can
first implement the basic mechanism in pull #1131 then add this uda
stuff later.
Re: A few considerations on garbage collection
Andrei Alexandrescu: Subsequently the GC should be within its rights to deallocate any memory within the first and last 250 integers allocated, even though in theory the user may get to them by using pointer arithmetic. Such use of point arithmetic is not uncommon. I think the current GC already does that. If this is true then this needs to be documented in bold text. Bye, bearophile
