I say we can put out D3 about the time Linux puts out kernel 2.8.
Daniel Gibson wrote:
> Probably it would be helpful if size_t was a proper type that can't
> be mixed with other types in dangerous ways without explicit casting.
Bad idea: once you insert an explicit cast, you now have a *hidden*
bug on the new platform instead of a compile error.
Torarin:
> But isn't the reason you're supplying a value to appendToFront that
> you do want a specific amount?
I figured it was just to give precision control over memory usage...
One problem with "at least" is it might have to wait for two
packets to come off the network interface; could be fairly slow.
The "at most" means it will take whatever is available without
overflowing your buffer - it will never wait if there is any
data available.
spir wrote:
> press play
Since size_t is an alias, you wouldn't see it's name anywhere
except the source code.
Sometimes I think we should troll the users a little and make
a release with names like so:
alias size_t
TypeUsedForArraySizes_Indexes_AndOtherRelatedTasksThatNeedAnUnsignedMachineSizeWord;
alias ptrdiff_t
TypeUsedForDifferencesBetweenPointers_ThatIs_ASignedMachineSizeWordAlsoUsableForOffsets;
a
We actually have a library replacement for octal literals:
http://dpldocs.info/octal
But until the C style syntax is disallowed, it doesn't change
anything. But, Walter is resistant to the change, last I knew.
bearophile:
> This kind of indentations is interesting:
I'm still trying to find something I like for this. Currently,
I see the contracts as part of the public interface, just like
the name, so I'm indenting them like I would if the argument list
ran too long.
void doSomethingBig(
int arg1
My implementation
http://arsdnet.net/tictactoe.d
source: 138 lines, 2420 bytes
You can see the byte count is comparable to the python 2, but I have
more lines. This reflects my preferences of one line = one instruction.
I usually prefer "Introduction to Programming" style code than
"functional c
My gut tells me you'd get much better results if you tried to
write D in D instead of Python in D.
I might take a stab at this myself. I can see lots of improvements
to the original code.
Jacob Carlborg wrote:
> The class "Post" maps to the database table "posts", no configuration is
> necessary. Then you can use the column names in the table as fields to
> set and get data, like this:
>
> post = Post.new
> post.title = "some title"
> post.body = "the body"
> post.save # will update
bearophile wrote:
> - assert(0); to mean HALT, that gives some problems
I like it. It's convenient and clear - assert(0) means
you cannot proceed in any situation, and that should include
release modes. (Indeed, IMO any assert that can be proven
to fail at compile time should always remain and one
Andrei wrote:
> I made one more pass and made the following changes:
I downloaded your new style to my site too and ran the automatic
table generator over std.stdio so we can see how it looks with
some different content.
http://arsdnet.net/d-web-site/std_stdio.html
I actually like that quite a b
> Same principle may even be the default for
> most modules, don't you think?
Indeed. It also lets us automatically generate stuff off
the existing files.
Here's my first go at automated tables:
http://arsdnet.net/d-web-site/std_algorithm2.html
I only tagged the map function in the std.algorith
Andrei Alexandrescu wrote:
> For now it's manual; I had to write the actual text which was the bulk
> anyway. Long term we'll need to look at generating the table by adding
> category tags to each function/class etc.
Right. I now think the best way to do it is something like this:
Macros:
WIKI =
Andrei Alexandrescu:
> Hmmm, this wrong jumping is a problem. I'll look into it. Offhand I
> don't know how to distinguish in the generated doc between an enum value
> and a function, but Adam did it. Adam?
My method is to track the level of nesting. The more tags above
you in the tag tree, the f
Andrei Alexandrescu Wrote:
> There are two tables, one with just the names and the other with names
> and a brief description. Let me know of any feedback. Thanks!
Did you decide on a manually maintained table or is it auto generated? I do
really think adding a Tags: section, or perhaps just pu
Steven Schveighoffer wrote:
> It does help, but I was kind of hoping for something that shows the
> structure.
Those relationships are in the HTML too try it now:
http://arsdnet.net/d-web-site/std_algorithm.html
(I know it needs some work still, I'm just sick of Javascript after
spending 20 m
> Say... I wonder... there's already a class "d_psymbol" in the
No, I'm wrong. That's only the currently referenced symbol. No
point linking back to itself!
Gotta go back to the drawing board for good cross referencing.
Steven Schveighoffer wrote:
> I'm all for it (voice with no authority).
Here it is with the brief css change to put it in a grid:
http://arsdnet.net/d-web-site/std_algorithm.html
It's a very small change that, to me, makes a huge difference.
> I really think ddoc needs to be revamped to do more
Andrei Alexandrescu wrote:
> We'd eliminate the unstructured "jump to" section and we create the
> grouping by hand (sigh).
Maybe we can get the best of both worlds: how about a "Group:" or
"Tags:" section in the ddoc that a program could automatically
pull out to make the listing?
I think we can
Steven Schveighoffer wrote:
> I think the main problem is with ddoc. This, from std.algorithm is a
> f**king mess IMO:
Note that that is generated through some short javascript in the
html header.
I remember writing a brief change to that to make it look a lot
better (organized into a simple gri
Ary Manzana
> The only think I don't like is the background image. I mean, I like
> the background, it just doesn't have to be an image. Each time I go to
> another page it shows me a white page and then loads everything.
That's not the image's fault. The image is cached and background
loaded, so
I have the code runner back up now. I tweaked the ulimits,
moved it all to a restricted and firewalled VM, and put it
on a separate domain (so if someone abuses the cgi passthrough,
they can't really do too much there either)
http://arsdnet.net/d-web-site/
Feel free to try to break it with arbitr
> Please read my messages in "D2 postgresql interface - Phobos2?" thread
(D.learn).
Wow, that looks outstanding!
I look forward to the release.
> I know I keep beating this horse, but in other languages, this is the
> textbook example for why annotations are useful. Adding metadata to
> code, even if it can only be examined at compile time, can be
> immensely useful.
I agree, I think the @attrs should have been shorthand for
user defined
Piotr Szturmaj wrote:
> I already have working postgresql row querying. There are typed and
> untyped rows. Untyped row is DBRow!(Variant[]), typed rows are
> encapsulated using struct or tuple, for example:
Very nice! I did something similar in two cases: one is the
byStruct in mysql.d (currently
Nick wrote:
> You should stick this in the announcements group.
Yeah, I'm still working some kinks out though. (Trial by fire - I
ended up pushing the *new* mysql module to the live work server in
an unrelated update yesterday! So now frantically fixing things
for tonight's launches...
The breaka
> When you compile, you have to provide a path anyhow, less hostile to
> user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler can (usually) figure it
out on its own. Try dmd -v and search for import lines.
B
> However, when there are breaking changes, random.garbage needs a new
version (e.g. 0.6.etc instead of 0.5.etc).
IMO the best way to do that would be to get everyone in the habit
of including the version in their modules.
module random.garbage.0.6;
import random.garbage.0.6;
That way, it is e
> Pre-built libs aren't all that useful anyway, for several reasons:
By "pre-built" I mean all the source is in one place, so the
compile Just Works, not necessarily being pre-compiled.
So if you downloaded mylib.zip, every file it needs is in there. No
need to separately hunt down random.garbage
Jesse Phillips wrote:
> But if they haven't done any development on it for the last year, but
> the library it depends on has...
Unless you give library authors write access to your hard drive,
it doesn't matter. They can't make your old, saved version
magically disappear. If you then distribute t
retard wrote:
> How it goes is you come up with more and more features if you spend
> sometime THINKING about the possible functionality for such a tool.
It, as written now, does everything I've ever wanted. If I try
to do every possible function, it'll never be done. The question
is what's trivia
Vladimir Panteleev wrote:
> Your tool will just download the latest version of Y and the
> whole thing crashes and burns.
My problem is I don't see how that'd happen in the first place. Who
would distribute something they've never compiled?
If they compiled it, it would have downloaded the other
> I meant that if the latest version 0.321 of the project 'foobar'
> depends on 'bazbaz 0.5.8.2'
Personally, I'd just prefer people to package their damned
dependencies with their app
But, a configuration file could fix that easily enough. Set one up
like this:
bazbaz = http://bazco.com/0.5
retard wrote:
> A build tool without any kind of dependency versioning support is a
> complete failure.
You just delete the old files and let it re-download them to
update. If the old one is working for you, simply keep it.
Daniel Gibson wrote:
> That'd suck horribly for bigger projects, and also when
> you've got a lot of dependencies, I guess
Maybe, especially if the dependencies have dependencies (it'd
have to download one set before knowing what to look for for
the next set), but that is a one time cost - after t
Andrei wrote:
> We need a package system that takes Internet distribution
> into account.
Do you think something like my simple http based system would work?
Fetch dependencies. Try to compile. If the linker complains about
missing files, download them from http://somewebsite/somepath/filename,
Jim wrote:
> I never claimed that file storage was an optimisation. The compiler
> can optimise better by seeing more source code (or a greater AST if
> you will) at compile time. Inlining, for example, can only occur
> within a compilation unit. I'm arguing that a file is not the optimal
> compila
Vladimir Panteleev wrote:
> Then the question is: does the time you spent writing and maintaining
> makefiles and build scripts exceed the time it would take you to
> set up a build tool?
I never spent too much time on it anyway, but this thread prompted
me to write my own build thing. It isn't 10
Vladimir Panteleev:
> I think [file/module name mismatches] is a misfeature.
Maybe. 9/10 times they match anyway, but I'd be annoyed if
the package names had to match the containing folder.
Here's what I think might work: just use the existing import
path rule. If it gets a match, great. If not,
Interestingly, my own experience with Ruby, a few years ago, was
almost 180 degrees opposite of the blogger's.
The two most frustrating aspects were documentation and deployment.
The documents were sparse and useless and deployment was the
hugest headache I've ever experienced, in great part due t
Jim wrote:
> Why can't the compiler traverse this during compilation in order to
> find all relevant modules and compile them if needed?
How will it find all the modules? Since modules and files don't
have to have matching names, it can't assume "import foo;" will
necessarily be found in "foo.d".
It seems to me that you actually want two separate functions:
repeat("abc", 3) => ["abc", "abc", "abc"]
join(repeat("abc", 3)) => "abcabcabc"
A join function already exists in std.string and does this, although
it expects a second argument for word separator. I'd be ok with adding
a default arg
I stuck with my CRT for a long time. What I really liked about it
was the bright colors. I've never seen an LCD match that.
But, my CRT started to give out. It'd go to a bright line in the
middle and darkness everywhere else at random. It started doing
it just every few hours, then it got to the p
> What are your use cases for these three functions?
I don't know about bearophile, but I used a lot of the functions
you are talking about removing in my HTML -> Plain Text conversion
function used for emails and other similar environments. squeeze the
whitespace, align text, wrap for the target,
Robert Jacques wrote:
> I've been working on an update to both std.json and std.variant.
Yes, I remember looking at it before. Both look outstanding, but
I haven't actually used them yet so the improvements haven't quite
sunk into my brain.
I think the differentiating point here is mainly that I'
Over the weekend, I attacked opDispatch again and found some old
Variant bugs were killed. I talked about that in the Who uses D
thread.
Today, I couldn't resist revisiting a dynamic kind of object, and
made some decent progress on it.
http://arsdnet.net/dcode/dynamic.d
(You can compile that; th
bearophile wrote:
> That doesn't shorten the code.
Completely irrelevant. We're not playing code golf. What matters
is: a) Is it easy to change? and b) Is it clear to read?
immutable is easy to change. It's just one word. immutable is clear
to read, it says what it means.
> [val is] clear enough
On 12/27/10, Steven Schveighoffer wrote:
> What about tools to make deallocation easier? For example, we have
> scope(exit) that you could potentially use to ensure a memory block is
> deallocated on exit from a scope, what about a thread exit?
It seems to me that the simplest thing might simply
spir wrote:
> Actually, do you know any editor _without_ this feature?
Notepad! I don't think elvis or gedit do either, all three of
which I've used for code in the past.
> But the actual issue is not about time at all, instead plain
> human laziness
There is more to it than laziness - it is fru
bearophile wrote:
> writing "immutable" often is boring and makes code longer.
im -> immutable
Really, I think you *desperately* need to get a better editor. Once
you get one with a decent auto-complete, you'll never care
about typing out 'boring' words again.
=== recommendation and sermon he
spir wrote:
> But that's true for explicite imports as well:
> import util : x1,x2,x3;
> -->
> import oauth : x1,x2,x3;
Yeah, that's not too bad, since the changes are still just in
import lines. Though like I said in my last post, I don't see
much of a benefit here either.
> (Name qualificatio
spir wrote:
> These are imo essential documentation needs unfulfilled.
> 1. at import place, does not tell the reader which symbols
> are actually used
Two things: a) Why does it really matter at all? The specific
functions won't change the fact that you depend on the module.
b) Even if you grant
Andrej Mitrovic wrote:
> Actually, D is equipped to solve even that problem
Indeed.
Though, that doesn't cover all the uses of shuffling things around.
My oauth.d module currently still includes some of my own specific
app, like my own api secret. (It was originally hard coded, then I
moved it to
sybrandy wrote:
> Now, the nice thing about this is that you immediately see what
> module this function came from.
Yes, that's like a static import in D. You can also use fully qualified
names with a standard import:
std.stdio.File -- optional long form for File
static import std.stdio; // you
Lars T. Kyllingstad wrote:
> find a better way of serving applications over
> the internet than running them in a glorified document viewer.
This is something I've been (very) slowly working on for a while,
with my D Windowing System project.
My idea was to take a fairly high level GUI API and pu
Andrew Wiley wrote:
> Web applications have zero-install
But they trade it in for registration, with those awful, awful
CAPTCHAs.
They don't just distinguish between humans and computers (sometimes).
They also distinguish between flawless humans with perfect vision
and expensive monitors and real
> Have you tried, for example, CoffeeScript:
I have not - my main problem with Javascript isn't so much the
language as the browsers in which it runs, which is why I feel things
like emscripten (and google native client) are pretty useless.
Browsers are good for displaying html pages. Javascript
Michael Stover wrote:
> Someone who was serious about making an application over the
> web would simply require Chrome or Firefox, and then 99% of your
> incompatibility issues go away, as well as your performance problems.
And, let's not forget, 50% of your potential users!
> Today being online matters for languages. I have found
> another way to (in theory) run D code on the web.
I've been running D code on the web, professionally, for almost a year now.
To toy around, I've also done C, C++, and even assembly.
How? It runs on the server, and the client browser is
Daniel Gibson wrote:
> Or maybe, with more magic and support within the D compiler
> s.main(i);
> s.foo(42,x);
We can do that today - write an opDispatch that forwards
to an associative array.
It's actually pretty trivial.
foobar wrote:
> I still haven't seen one example of generic code that uses a generic
> conversion.
> I remain unconvinced about this point and would appreciate an example.
Like half the generic code I've written does that. A direct example
for this is my web.d - it makes automatic wrappers for D
Graham Fawcett asked:
> Can I ask how you handled HTML templating?
Rolled my own. I started with a DOM implementation and added
templating stuff on top of it (my original
idea was to be able to copy/paste some of the D code into Javascript
with minimal changes - change auto to var, and see it work
Bruno Medeiros wrote:
> That's interesting, could you detail a bit more
> what the D2 program did, etc. ?
It's a (for pay) social networking / marketing website with a
variety of side programs to allow for scheduled messages, a
static (pre-compiled) website, and command line interaction
with some
> "Script mode" (actually - simple wrapper) would be better:
> It could do simple parsing of script, bringing all "import"
> clauses to the beginning and add some default imports
> (like std.stdio). It seems that all code below imports can be
> wrapped into main declaration.
My rund.d program doe
jdf wrote:
> Question 1. Nearly-Verbatim Translation:
> Does that fall under the .h license?
Yes, since it is a derivative work. Same for questions
2 and 3 - they are all based on the original .h, so they
all inherit its license too.
The only file currently in the etc.c package is zlib.d,
a direc
Lars T. Kyllingstad wrote:
> Have you ever considered cleaning it up and publishing it as
> a web app library for D, either on dsource or somewhere similar?
Yes, I'd like to do that eventually, but haven't gotten around to it yet. You
can
see, looking through the code, that I've been lax on docum
spir wrote:
> I thought once at a default interface between the command-line and a
> program's startup routine, main().
We could actually do this with a mixin.
==
int findword (string filename, string word, bool verbose=false) {...}
mixin MakeMain!(findword);
==
And that MakeMain temp
Nick Sabalausky wrote:
> (but I've done worse - I once tried to build HTML
> buy manually adding nodes to an XML DOM...it seemed like a good idea
> until I actually started doing it).
This is actually one of the methods I've been using in my D web apps throughout
the year. It's not that bad if you
Eric Poggel wrote:
> Are there any web-friendly languages that are mature, offer the sanity and
> static typing of C#, and the "immediate mode" of php?
We could do it in D, somewhat easily. Here's an implementation with only mild
bugginess:
===
import std.file;
import std.string;
import std.std
On 8/20/10, Adam B wrote:
> If only we could trap a segfault signal and have the OS tell us which
> thread caused it and provide some mechanism to resume the thread with
> an exception...
Windows actually does that.
On 8/20/10, Andrej Mitrovic wrote:
> I dunno, TDPL says:
> *snip*
That's true, though I think it is getting into nitpicking the
definition of global variable still, the module system resolves
conflicts in a way that C globals can't hope to do, which is
fantastic. All the benefits with none of
On 8/20/10, Andrej Mitrovic wrote:
> There are no global variables in D, afaik. But I haven't studied this
> closely yet.
The opposite: there are multiple kinds. You have enums in the global
scope, which are available to everyone, but don't take any storage
(that's what I used here), you have re
Last message in a row, I promise.
I just determined a work around for this - use a global variable. (the
config.d file defines several global variables already, but it is
stuff like companyName, domainName, etc.).
A global enum actually:
version(clientA)
enum bool withFeatureX = true;
=
Sorry for three messages in a row, but I just realized what I'm asking
for would break incremental compiles, since the version thing wouldn't
be propagated there. So I guess it is by design. I think the
documentation should be a bit more explicit about it.
That kinda sucks though. I can't have tha
r
other modules."
Striking the word "imported", since it being there implies it only
changes modules the defining file imports - a one way thing. This lack
of influence would in fact go both ways.
On 8/20/10, Adam Ruppe wrote:
> I just hit something that might be a compiler bug, or mi
I just hit something that might be a compiler bug, or might be a
documentation bug. (Of course, it can't be me! :P )
I have two modules:
config.d
===
version (clientA) {}
version ( clientB ) {
version = withFeatureX;
}
version (clientC) {
version = withFeatureX;
}
===
application.d
===
This is brought up somewhat often on this group. Problem with throwing
an exception in a segfault is that it is undefined behavior in POSIX.
However, I encountered exactly your problem: a null pointer in a big web app.
The way I solved it was to sprinkle
assert( var !is null );
before I start u
On 8/20/10, dsimcha wrote:
> How did you do this? Don't you lose some important stuff like label names
> in the translation?
Yes, though a lot of label names aren't all that helpful in the first
place. "done:" or worse yet, "L1:" don't help much. Those names are
obvious from context anyway.
> I
Glancing over it really quickly, High Level Assembly is /completely
insane/. The whole point of writing assembly language is to see and
write exactly what the computer sees and executes. This makes it
useful for coding, and also very easy to read (in the small, at
least).
The HLA examples on Wikip
On 8/19/10, Nick Sabalausky wrote:
> And Adam Ruppe did cgi in Asm:
>
> http://www.arsdnet.net/cgi-bin/a.out
Did I post that to this list, or did it find its way around the
Internet on its own? I saw it randomly pop up on a Google search last
year too, on a list I've never even
On 8/16/10, Yao G. wrote:
> Are you working on Gregorian documentation? Or the code itself?
I've just been (slowly) documenting std.date. I used it for a work
project, and hit a similar situation to Pedro: the module was good
enough for me, but I had to dive into the source before I knew it even
I started doing this too, and am planning to commit it for the next
release. I haven't finished it though.
If you email your modified copy of date.d to me (destructionator (at)
gmail.com), I'll integrate your changes with mine and commit it to
Phobos for you.
On 8/16/10, bearophile wrote:
> 'auto' in C++0x is a good and useful feature, just as it is useful in D, but
> as I have explained it has real risks, so it must be used with moderation,
> if you use it everywhere in the code, your code becomes harder to understand
> and modify.
I see it as the op
On 8/16/10, bearophile wrote:
> So I think size_t=>uint may require a cast on 32
> bit systems too, so when the code gets compiled with the 64 bit dmd this
> error isn't present.
I don't think that's a good idea because of what you say later in your
post: the cast punches a hole through the syste
To me, the biggest appeal of ddoc is that it doesn't require markup to
give good enough results. It's almost mindless to use.
On 8/13/10, Graham Fawcett wrote:
> Just FYI, if you add 'pragma(lib, "curl");' to the top of your
> curl.d file, you shouldn't need '-L-lcurl' any more; dmd will
> add it automatically during linking.
Very cool. For some reason, I thought that didn't work on linux... I
must have just been doing
Perhaps relevant to this discussion is the Old New Thing posts this
week. This last one has a good sentence:
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/13/10049634.aspx
"If I ruled the world, I would decree that the only thing you can do
in a finalizer is perform some tests to ensure tha
I've been using the curl library with a thin wrapper in D:
http://arsdnet.net/dcode/curl.d
Example use:
dmd test.d curl.d -L-lcurl
=
import std.stdio;
import arsd.curl;
void main() {
writefln("%s", curl("http://arsdnet.net/dcode/curl.d";));
}
=
That fetches the code off my si
On the subject of rebindable, what about:
const Object o; // not rebindable, the whole thing is set once and const
const(Object) o; // the Object is const, but the reference is not.
So, everything is rebindable unless the declaration has a
const/immutable on the outside.
int a; // rebindable (ob
Here's how I'd do it:
void main() {
const T[] buildArray() {
T[] t;
// fill in t
return t;
}
const T[] t = buildArray;
}
So the creation is factored away into that nested function which is
used to initialized the reference that you keep around.
On 8/8/10, Andrej Mitrovic wrote:
> I wonder if there's a way to get the static type, is there an equivalent
> function like typeid() for such a case?
Try this:
typeid(typeof( X ));
typeof() returns the static type of the variable. Then, you can get
the typeid of that returned static type
On 8/5/10, mwarning wrote:
> Google might help.
I know what it is, but I have /zero/ respect for people who shove
their dependencies on me. It shouldn't be my problem.
One of the reasons I went with Digital Mars early on is that DMC just
works when you unzip it. DMD continues that tradition, and
On 8/5/10, mwarning wrote:
> I assume that's what you call unusable?
I mean unusable in the literal sense:
$ ./ldc
./ldc: error while loading shared libraries: libelf.so.0: cannot open
shared object file: No such file or directory
I hear it also doesn't do D2 at all, which is unacceptable, and
On 8/4/10, bearophile wrote:
> I am sorry to say this, but I think porting the current back-end to 64 bit
> is a waste of time because it will not be used for professional usages. I
> think LLVM will be the main back-end for professional usages of D2
Get back to me when LDC starts to actually /wo
On 8/3/10, Andrei Alexandrescu wrote:
> BTW, speed of compilation of very short programs is not very relevant as
> long as it's reasonably good.
I don't know. Large programs is certainly very important, but I think
small ones are too. The reason is a very quick compile on small
programs means you
On 8/3/10, Walter Bright wrote:
> Andrei put together a benchmark that shows that D compiles 4 times faster
> than Go.
I've found D1 tends to be much faster than D2 as well. The dmd version
1 is so fast that I often think it doesn't even run!
D2's (relative) slowness I've tracked down to import
On 8/1/10, Tomek Sowiński wrote:
> Link, please. ;)
http://dpldocs.info
If any tried to use it last week, you would have noticed it was down:
my motherboard died, and the parts to fix it didn't arrive until
Friday. It should be up most the time now.
You can put in a search term to the box, or u
Lerdorf's quote strikes me as actually being somewhat close to what
Walter is talking about. Web applications don't focus on making a
thing that never fails, but instead achieve reliability by having an
external watchdog switch to backups - that is, a fresh copy of the
program - when something goes
101 - 200 of 272 matches
Mail list logo
