Re: half datatype?
On 18/11/12 12:21, Manu wrote: I've often wondered about having an official 'half' type. It's very common in rendering/image processing, supported by most video cards (so compression routines interacting with this type are common), and it's also supported in hardware by some cpu's. ARM for instance supports 'half's in hardware, and GCC has an __fp16 type which would map nicely if D supported the type in the front end. The alternative us to use ushort everywhere, which is awkward, because it is neither unsigned, nor is it an integer, and it's not typesafe (allows direct assignment to ints and stuff)... It would be nice if: cast(half)someFloat would yield the proper value, even if it is performed in software in most architectures, it could be mapped to hardware for those that do it. It could be done in a library, but then GCC couldn't map it properly to the hardware type, and since D has no way to describe implicit casts (that I know of?) it becomes awkward to use. someFloat = someHalf <- doesn't work, because a cast operator expects an explicit cast, even though this is a lossless conversion and should be exactly the same as someDouble = someFloat. Thoughts? I suspect that what you want in nearly all cases is conversion from half[] <-> float[] ie, a pack/unpack operation. I think it would be quite rare to want to operate on a single half. Although it's supported natively on GPUs, for D's purposes it is more natural to view it as compressed data.
Re: The annoying D build system
On 11/20/12, Jacob Carlborg wrote: > I think you misunderstood what I was trying to say, or I am > misunderstanding you. I'm showing the path of least resistance for how to build either dmd/druntime/phobos/dlang-org > One solution that instantly pops in my mind is using git submodules. They are buggy on Windows. The last time I've used them Git started showing thousands of error messages, crashed and erased my repo and commit history, but one of the last few commits were left in the reflog so I managed to recover my files. It also copied the submodule repo directory into randomly selected folders in an upper directory. Maybe it's just an msysgit thing, but I'm never touching submodules again.
Re: split dmd frontend into separate project
Jacob Carlborg wrote: > On 2012-11-19 15:46, Iain Buclaw wrote: > >> Yes it would make sense - no it can't be done because gdc/ldc makes >> changes to their own copies of dfe. The solution would be to fix dfe >> so that multiple backends can use it. But that it not currently the >> case. > > Wouldn't those changes be easier to make and maintain if the front end > was a separate project, even if it can't be used unmodified. >From an outsiders view I'd believe that it would be much simpler to fork git branches for the dmd frontend versions of gdc and ldc and use the git machinery for merges. - But the developers must decide. I don't want to annoy them. Regards, Thomas
Re: Bret Victor - Inventing on Principle
On Tuesday, 20 November 2012 at 04:30:19 UTC, Andrei Alexandrescu wrote: On 11/19/12 7:50 PM, Walter Bright wrote: On 11/19/2012 6:26 AM, Regan Heath wrote: Hope no-one minds.. I stumbled across this video which I thought was pretty darn cool: http://www.youtube.com/watch?v=PUv66718DII Can you give us a summary or synopsis? "Worth watching." Andrei Usually I dislike watching videos instead of slides, but this time I agree. I think that this video is about giving instantaneous feedback to users and what they can gain from it: so slides aren't "good enough" here. That said, when he plays with numeric values in the code, I can't help thinking: this is wrong there shouldn't be "magical" numerical value in the code as this is not maintainable/readable. renoX
Re: @property needed or not needed?
Am 20.11.2012 05:12, schrieb Andrei Alexandrescu: > On 11/19/12 5:23 PM, Rob T wrote: >> I don't have an answer, but there may be more to the picture than we think. > > I agree. In particular I find it a specious argument to insist on religiously > associating "()" with > function calling and the lack thereof with variable access. I don't see > myself, when seeing an > expression like "generator(x, y, z).map!(x => x * x)()", going like "holy > cow, good I saw those > trailing parens, otherwise I would've sworn it was a variable". Trailing > parens in UFCS chains are > just warts, this is the reality. Let's deal with it. > > > Andrei Isn't it more that they seem like warts whenever a parameterless (or pseudo-parameterless in the case of UFCS) template function is called, because template instantiations already look a lot like function calls? Anyway, my take on this is, while I find it a bit sad, that there is no visual distinction between variables and functions for various reasons, in the presence of properties this distinction has already gone long time ago. So realistically this argument has no weight anymore. Personally, I started to like a partially relaxed approach like the one Adam Ruppe describes a lot, so a DIP would definitely be a great step.
Re: The annoying D build system
On 2012-11-20 09:21, Andrej Mitrovic wrote: I'm showing the path of least resistance for how to build either dmd/druntime/phobos/dlang-org The build systems for the repositories are still breaking out of their top level directory. They are buggy on Windows. The last time I've used them Git started showing thousands of error messages, crashed and erased my repo and commit history, but one of the last few commits were left in the reflog so I managed to recover my files. It also copied the submodule repo directory into randomly selected folders in an upper directory. Maybe it's just an msysgit thing, but I'm never touching submodules again. I haven't had any problems with submodules so far. I don't really understand why they wouldn't work as good on Windows as the other platforms. -- /Jacob Carlborg
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson Little wrote: Would a minor refactor of vibe.d be acceptable? This is pretty much what I'm looking for: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d Except that I'd remove some parts of it, like JSON parsing. I think that vibe.d could benefit from moving some of the code there into Phobos. I guess it comes down to whether it makes sense to make a standard HTTP library. BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json. Nicolas
Re: Something needs to happen with shared, and soon.
On Monday, 19 November 2012 at 04:57:16 UTC, deadalnix wrote: Le 17/11/2012 05:49, Jason House a écrit : On Thursday, 15 November 2012 at 16:31:43 UTC, Sean Kelly wrote: On Nov 11, 2012, at 6:30 PM, Walter Bright wrote: To make a shared type work in an algorithm, you have to: 1. ensure single threaded access by aquiring a mutex 2. cast away shared 3. operate on the data 4. cast back to shared 5. release the mutex So what happens if you pass a reference to the now non-shared object to a function that caches a local reference to it? Half the point of the attribute is to protect us from accidents like this. The constructive thing to do may be to try and figure out what should users be allowed to do with locked shared data... I think the basic idea is that no references can be escaped; SafeD rules could probably help with that. Non-shared member functions might also need to be tagged with their ability to be called on locked, shared data. Nothing is safe if ownership cannot be statically proven. This is completely useless. Bartosz's design was very explicit about ownership, but was deemed too complex for D2. Shared was kept simple, but underpowered. Here's what I remember of Bartosz's design: - Shared object members are owned by the enclosung container unless explicitly marked otherwise - lockfree shared data is marked differently - Non-lockfree shared objects required locking them prior to access, but did not require separate shared and non-shared code. - No sequential consistency I really liked his design, but I think the explicit ownership part was considered too complex. There may still be something that can be done to improve D2, but I doubt it'd be a complete solution.
Re: @property needed or not needed?
On 2012-11-19 23:23, Rob T wrote:
Also do not forget that we can not only drop the (), but also perform
assignments to functions that take in one variable, but I'm not sure if
the return must be void for that to work. It seems strange to allow
arbitrarily dual function/variable constructs for functions, but being
strange does not necessarily mean it is wrong.
The return value doesn't have to be void. I always return the new value
from my setters, to allow chained assignments. If chained assignment
can't be used the property hasn't emulated a variable properly.
class Foo
{
private int bar_;
@property int bar () { return bar_; }
@property int bar (int value) { return bar_ = value; }
}
auto foo = new Foo;
int a = foo.bar = 3;
Of course the correct solution would be to implement a form of property
rewrite in the compiler. Transforming the following code:
int a = foo.bar = 3;
To:
foo.bar = 3;
int a = foo.bar;
If "foo.bar" is a method/@property.
--
/Jacob Carlborg
Re: @property needed or not needed?
On 11/20/12 2:48 AM, thedeemon wrote:
[snip]
"one two three".split.map{|s| s.reverse}.join(' ')
in Ruby
print . unwords . map reverse . words $ "one two three"
in Haskell
"one two three" |> split " " |> List.map reverse |> String.join " " |>
print_string
in OCaml
and something similar and even without dots in Scala.
Ease of chaining functions together is one of the things that make those
languages so pleasant to work with. I love to have the same in current D
and it would be a pity to lose it due to a clash with some old-fashioned
tradition.
A very good argument. Thanks!
Andrei
Re: The annoying D build system
On 20-11-2012 09:21, Andrej Mitrovic wrote: On 11/20/12, Jacob Carlborg wrote: I think you misunderstood what I was trying to say, or I am misunderstanding you. I'm showing the path of least resistance for how to build either dmd/druntime/phobos/dlang-org One solution that instantly pops in my mind is using git submodules. They are buggy on Windows. The last time I've used them Git started showing thousands of error messages, crashed and erased my repo and commit history, but one of the last few commits were left in the reflog so I managed to recover my files. It also copied the submodule repo directory into randomly selected folders in an upper directory. Maybe it's just an msysgit thing, but I'm never touching submodules again. Er... what? I certainly cannot say I've had the issues you describe. Submodules have always worked flawlessly on Windows for me. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
Re: @property needed or not needed?
On 2012-11-20 08:48, thedeemon wrote:
This is just an old habit to see identifier with parens as a function
call and identifier without parens as a variable, so calling functions
without parens seem too unconventional to you. However there are many
languages which dropped this tradition and they are known for being
expressive and concise, that's why people love them. Recently we saw an
article from Walter about component programming which one could say was
really about function composition. It's really convenient to write code
in conveyor-style, this is what we see often in functional languages, as
well as some dynamic OO ones. For example, the task of reversing words
in a string may look like:
I completely agree.
"one two three".split.map{|s| s.reverse}.join(' ')
in Ruby
In this particular case you can use a shorter form of the map call:
"one two three".split.map(&:reverse).join(' ')
print . unwords . map reverse . words $ "one two three"
in Haskell
"one two three" |> split " " |> List.map reverse |> String.join " " |>
print_string
in OCaml
and something similar and even without dots in Scala.
Wouldn't the Scala syntax look fairly similar to Ruby:
"one two three".split.map(reverse).join(' ')
Ease of chaining functions together is one of the things that make those
languages so pleasant to work with. I love to have the same in current D
and it would be a pity to lose it due to a clash with some old-fashioned
tradition.
I completely agree again.
--
/Jacob Carlborg
Re: Bret Victor - Inventing on Principle
On Tue, 20 Nov 2012 09:54:43 -, renoX wrote: That said, when he plays with numeric values in the code, I can't help thinking: this is wrong there shouldn't be "magical" numerical value in the code as this is not maintainable/readable. Agreed. Imagine if the magical numbers were all defined with CONSTANT's as any good programmer would do. In that case clicking one and dragging the slider would by default, change the value for all uses of CONSTANT. Alternately, there could be a hot-key which defines a new CONSTANT with the new slider value for that single usage. All doable with a sufficiently clever IDE. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: @property needed or not needed?
On 2012-11-19 19:02, Adam D. Ruppe wrote: On Monday, 19 November 2012 at 15:01:36 UTC, Andrei Alexandrescu wrote: Would you please start a DIP with a paste of this idea? here it is: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21 I tried to implement this a while ago and hit some pain after some early success. The pain was trying to get assignments to work without breaking other cases like returning ref. My plan was to make any reference to a @property change to a CallExp or whatever. But if you do that and it is on the left hand side of an assignment, you do the wrong thing. foo = foo + 1; should generally become: foo(foo() + 1); but if there isn't a setter, we should leave it as foo() = foo() + 1; and finding the setter is a bit of a pain. Then, of course, we ideally want foo += 1 to work too.. It would be really nice if we could implement property rewriting in the compiler. Maybe someone who knows the compiler better than me will make it look easy though. Should this be allowed for functions that isn't marked with @property: foo = 3; -- /Jacob Carlborg
Re: Bret Victor - Inventing on Principle
On Tue, 20 Nov 2012 00:50:42 -, Walter Bright wrote: On 11/19/2012 6:26 AM, Regan Heath wrote: Hope no-one minds.. I stumbled across this video which I thought was pretty darn cool: http://www.youtube.com/watch?v=PUv66718DII Can you give us a summary or synopsis? Sorry, I really should have done that. As bearophile says it's hard to summarise, but as Andrei mentioned it's well worth watching. It is essentially about making it easier to "create" things. Finding areas where the process of creating something is difficult and analysing why. In most of the cases he shows the problem is a detachment between the method of creation and the result. Like code for example, we write code but get no immediate feedback of our changes. Instead we have to compile, copy/installing/etc the result>, then run the program to see the results. He shows an interactive IDE which displays the program output side by side with the code, in this case a game with a character that jumps about the place. He can click on a variable and alter it's value with a slider and see immediate feedback. There are also some neat tools for manipulating time allowing you to see the result of changes over time and tweak values to exactly those values you want/need. (This example reminded me of the game Braid). Another example is of defining a new algorithm. In this example the IDE asks for example input values, and then it shows the variables of the algorithm at each stage as the programmer defines them. It shows the values for each iteration of a loop, and allows the coder to test various input and actually "see" the results rather than having to imagine them all in their head. Both of these are examples of where creation is hindered by the programmer having to visualise the result as they design - something all good developers can do well, sure, but why force ourselves to pretend to be a computer when we have a computer sitting in front of us which is infinitely better at it than we are? How many times have we sat there and written the content of a string out on paper, labeled the indexes, drawn pointers to characters, etc in order to design an algorithm that deals with strings. I still do this fairly frequently, even when I'm confident sure I've got it right, simply to verify my work and check for edge cases. One further example shows him designing an animation in the conventional way using key frames and then again using a new system of touch based commands. This example was born out of the frustration he experienced spending a whole day animating a leaf falling from a tree in a natural way (using key frames) - a task he accomplishes in less than 2 minutes as you watch using his new system. A killer IDEA like those shown should be doable in D, for D. We have a debugger (or code that can debug D) and the compile time speed of D is such that on-the-fly compile and display shouldn't be prohibitively slow. All it needs is someone motivated and perhaps easier/better linking between the required parts i.e. D front end, compiler, debugger, GUI toolkit.. Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Bret Victor - Inventing on Principle
On Tue, 20 Nov 2012 12:44:51 -, Regan Heath wrote: A killer IDEA ... s/IDEA/IDE -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote: Should this be allowed for functions that isn't marked with @property: foo = 3; Hell no!
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote: Should this be allowed for functions that isn't marked with @property: foo = 3; Yes. We should *only* be changing the way @property is implemented. (Namely, actually implementing it!) Don't want to break existing code. The new changes must be opt in. If there's both an @property setter and a regular function, the property should be used here.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 05:31:09 UTC, deadalnix wrote: This make it impossible to only define a getter only when one want to return by reference. If there isn't a setter, you don't change things. If setter is present: foo = foo + 1; // becomes: foo(foo() + 1); If setter is not present: foo = foo + 1; // becomes: foo() = foo() + 1; If foo returns an rvalue, this is a natural error. If it returns ref, it works fine.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference. We can just define this away: &funName if it isn't a @property is the address of the function. If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()).
Re: @property needed or not needed?
On Tue, 20 Nov 2012 13:20:10 -, monarch_dodra wrote: On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote: Should this be allowed for functions that isn't marked with @property: foo = 3; Hell no! +1 I think this "feature" should just be removed, and @property implemented fully/correctly. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: @property needed or not needed?
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe wrote: On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote: Should this be allowed for functions that isn't marked with @property: foo = 3; Yes. We should *only* be changing the way @property is implemented. (Namely, actually implementing it!) Don't want to break existing code. The new changes must be opt in. Usually I'd agree but this is a case of a wart we should just remove IMO. The fix for breaking cases is simple, add @property. If there's both an @property setter and a regular function, the property should be used here. Agreed. But it's waay clearer whats going on if @property is required to call functions using this syntax. R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu
wrote:
We sorely need a server expert on board with the time and
inclination to write a good server-side networking framework.
I agree with this but it really should be generic; working at
probably the file descriptor level, so we can do whatever
protocols along with files, pipes, ... and ideally, any kind of
injected event. I'd really like it if we could run one event loop
and be able to do keyboard/joystick input, timers, GUI, threads,
etc., including third party libraries, as well as networking.
(Combining two different event loops is a pain in the butt.)
I have an implementation in mind (I'd use select() because I
don't know libev, but we should be able to change that without
changing the interface)...
... but I'm behind on my other work and have yet another deadline
looming so can't do it myself right now. I can't wait till I'm
retired!
And they milk that for all it's worth: any discussion, article,
or blog post about Go gravitates toward the five-lines HTTP
server with the same implacable reach as conversations with
ideologists, which inevitably converge towards their
ideological stronghold.
You know, I'll never understand this. Anybody can do a five line
http server. Hell, with my lib:
import arsd.cgi;
void hello(Cgi cgi) { cgi.write("hello!"); }
mixin GenericMain!hello;
Look, tiny http server (on port 8080)! Also works as cgi,
fastcgi, scgi, and easy command line testing with a different
compile option.
But not really that special language wise... yay, you can call a
library function. Who can't do that?
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
Usually I'd agree but this is a case of a wart we should just
remove IMO. The fix for breaking cases is simple, add
@property.
meh, I sometimes use it, but if overloading on @property works,
that's easy enough to allow both ways.
I use it in some big chaining things:
Element.make("div").className("foo").value = "bar";
vs
auto element = Element.make("div");
element.className = "foo";
element.value = "bar";
Using one or the other depending on if I have a variable name
there anyway. This would be arguably *better* with separation,
but I don't have the level of hatred for one function used both
ways (on setter nor getter) the way a lot of people do.
Re: @property needed or not needed?
BTW I've been pasting some of my posts into the wiki thing http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP21#section4 Kinda sloppy to just paste, but this way everything on my mind is in one place so we don't have to reread the thread to get it together. Of course, being a wiki, feel free to do the same with anything you want to note.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 14:13:51 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 13:50:10 UTC, Regan Heath wrote:
Usually I'd agree but this is a case of a wart we should just
remove IMO. The fix for breaking cases is simple, add
@property.
meh, I sometimes use it, but if overloading on @property works,
that's easy enough to allow both ways.
I use it in some big chaining things:
Element.make("div").className("foo").value = "bar";
vs
auto element = Element.make("div");
element.className = "foo";
element.value = "bar";
That's a good point. If the property is a "setter", then both
"value = bla" and "value(bla)" is legal.
If the property is a getter, then only "=" works. But I think it
would be fine if "value(bla)" were tanslated to "value = bla" in
that case.
However, if you allow "foo = rhs" => "foo(rhs)" on a non-propety,
then code like this becomes legal:
writeln = 5;
And that's bullshit.
Re: [OT] [RFC] A huge problem with Github diff
14.11.2012 19:27, Denis Shelomovskij пишет: P.S. Looks like Github's owners doesn't care at all about current users, only abut needless features and GUI glance to involve new ones because otherwise I have no explanation of this sad situation. OK, probably Github isn't that bad as it helps some single Japanese: https://github.com/norinori/boyfriend_require/blob/master/README-en.md But it's still not for programmers... -- Денис В. Шеломовский Denis V. Shelomovskij
Re: Downloadable spec for D version 2
On Tuesday, 20 November 2012 at 02:27:08 UTC, Edward Diener wrote: Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ? I got it from amazon for kindle for $0.99. http://www.amazon.com/D-Programming-Language-Specification-ebook/dp/B005CCQPKK/ref=sr_1_1?s=books&ie=UTF8&qid=1353422974&sr=1-1&keywords=d+programming+language+specification If you don't have a kindle you could still read with amazon cloud reader - but this is not great because no search or copy/paste. However, you can download and convert the amazon format to mobi and probably pdf with calibre which is a great tool. Thanks Dan
Re: Normal/Gaussian random number generation for D
Just to update everyone, Jerro and I have been knocking around a few discussions and code tweaks on GitHub: https://github.com/WebDrake/phobos/pull/1#issuecomment-10319570 If anyone wants to comment or give feedback, please feel free. It's surely useful that we get as many concerns covered and addressed before submitting an official Phobos pull request!
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard wrote: On Tuesday, 20 November 2012 at 03:49:57 UTC, Tyler Jameson Little wrote: Would a minor refactor of vibe.d be acceptable? This is pretty much what I'm looking for: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/common.d https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/http/server.d Except that I'd remove some parts of it, like JSON parsing. I think that vibe.d could benefit from moving some of the code there into Phobos. I guess it comes down to whether it makes sense to make a standard HTTP library. BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json. Nicolas vibe.d is MIT licensed. (Like almost every other WEB related library) Guess you have to ask Soenke for a permission.
Re: Is there interest in a std.http?
On Tue, Nov 20, 2012 at 03:09:23PM +0100, Adam D. Ruppe wrote: > On Tuesday, 20 November 2012 at 04:26:02 UTC, Andrei Alexandrescu > wrote: > >We sorely need a server expert on board with the time and > >inclination to write a good server-side networking framework. > > I agree with this but it really should be generic; working at > probably the file descriptor level, so we can do whatever protocols > along with files, pipes, ... and ideally, any kind of injected > event. I'd really like it if we could run one event loop and be able > to do keyboard/joystick input, timers, GUI, threads, etc., including > third party libraries, as well as networking. (Combining two > different event loops is a pain in the butt.) The event loop itself should be a generic component in Phobos, not specific to anything else. It should work at the file descriptor level, perhaps even combining with signal handling (using the self-pipe trick), and handle timers and scheduled events as well. Everything else should be pluggable into this generic module. I have written such things before in C/C++, but in D this will be much easier to implement, thanks to delegates (which make writing event-loop based programs so much less painful). Having a standard event loop will make it much less painful to integrate many components together in a seamless way. Combining two event loops, as Adam says, is a royal pain in the neck. Making the generic event loop a Phobos standard will eliminate this problem. > I have an implementation in mind (I'd use select() because I don't > know libev, but we should be able to change that without changing > the interface)... The interface should be generic enough that you don't have to worry about whether select or poll (or whatever the windows equivalent is) is used. I think it's a good idea to implement the select version first, as that's generic across Posixes, whereas libev is Linux-specific IIRC. T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Re: Is there interest in a std.http?
whereas libev is Linux-specific IIRC. Libev is a polling abstraction. It has select, epoll and kqueue backends (and there may be others I don't know about). So it is particulary useful for unices, where epoll (linux) and kqueue (OSX and BSD) are preferred async IO mechanisms. It can also be used on Windows, but with the select() backend, which doesn't scale well with many file descriptors. select() is also limited to 64 file descriptors by default on windows IIRC (that limit can be raised, but only to 4096 if I am not mistaken).
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 15:21:12 UTC, H. S. Teoh wrote:
It should work at the file descriptor level, perhaps even
combining with signal handling (using the self-pipe trick)
I was thinking we'd send pointers and a type hash through a pipe.
It'd keep the read/write very simple.
Now, the event data must be defined to be transient, unless
specifically told otherwise (e.g. immutable types), because then
we can reuse the data structures to avoid allocations.
But take a gander at this:
http://arsdnet.net/dcode/typehash.d
We can take any type tuple, do a mangle of and get a unique
name for any combination of arguments. Then hash it, and we
have a nicely unique, fixed size message to send down the pipe.
One one end, we'll cast to a void* and send that along with the
hash.
On the other side, only listener functions who's
ParameterTypeTuple matches the typehash will receive a message.
They can then cast the void* back to the argument type with
confidence.
This lets us define custom messages as plain types:
struct MyMessage {
string text;
}
event.listen((MyMessage m) { writeln("Received: ", m.text); }
event.send(MyMessage("hello!"));
event.loop(); // we should receive the message and call the above
func
If there's no listener that matches the hash, we ignore the
message. Now there'd be some care needed to not send pointers to
stack data down the pipe, as that could be destroyed, but eh.
Some details gotta be worked out but I really like the idea of
using type names like this.
Re: Bret Victor - Inventing on Principle
On Monday, 19 November 2012 at 14:27:51 UTC, Regan Heath wrote: Hope no-one minds.. I stumbled across this video which I thought was pretty darn cool: http://www.youtube.com/watch?v=PUv66718DII R Original on vimeo: http://vimeo.com/36579366
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 16:09:37 UTC, Adam D. Ruppe wrote: But take a gander at this: http://arsdnet.net/dcode/typehash.d I have such a hard time focusing on work when there's something like this to play with updated the link to show the concept actually working, not just hashing. All event listeners must take exactly one argument and it is all statically typed, but it works and can do the hash+pointer message. The hash function down there is borrowed from druntime. I couldn't find it accessible as a stdlib import so I copy/pasted. But ignoring that, the rest is actually simple code. Problem is this probably isn't @safe... and might not be @trusted either because you can send stack info.. maybe we could do further constraints, or copy the data into a queue, or something. I really think we could make it work though and it'd be pretty cool.
Re: [RFC] A huge problem with Github diff
On 11/14/12, Alex Rønne Petersen wrote: > You need to manually configure your monospaced font in Phabricator in > your display preferences. I did again and using latest Chrome. I can set font settings from the the code diff via View Options -> Configure Editor, but no matter what font I type in and click save it doesn't change the diff font. Here's what the diff looks like: http://i.imgur.com/TGArz.png That font is Arial, and it stays that way no matter what I put in the font settings. And in another view I a different font is rendered: http://i.imgur.com/RClAS.png Might just be a bug. Btw, what does "Clowncopterize" and "Cook the books" mean? I hate software that tries to act cute. It also doesn't have a good folder tree view, files and folders are intermixed. But maybe there's a setting for this somewhere.. Anyway all of that is nitpicking, I don't want to be negative towards this software if it would actually make us review and merge pulls faster. SVN->Github was a win, maybe this would be one too.. I have no experience using Phabricator so I don't know. From a first look it seemed complicated compared to Github, maybe with time it would grow on me.
Re: Is there interest in a std.http?
On Tuesday, 20 November 2012 at 12:12:27 UTC, Nicolas Sicard wrote: BTW, the actual JSON module in viba.data.json in richer in functionality and easier to use than the one in std.json. The module has virtually no dependency on other parts of vibe.d. I whish it was also moved to Phobos or at least inspired a refactoring of std.json. Nicolas I have not yet looked at the vibe.d JSON yet, but I certainly will. I agree with you that the std.json could use some improvement, it's not all that fun to use that's for sure. --rt
Re: Normal/Gaussian random number generation for D
On Tuesday, 20 November 2012 at 15:04:53 UTC, Joseph Rushton Wakeling wrote: Just to update everyone, Jerro and I have been knocking around a few discussions and code tweaks on GitHub: https://github.com/WebDrake/phobos/pull/1#issuecomment-10319570 If anyone wants to comment or give feedback, please feel free. It's surely useful that we get as many concerns covered and addressed before submitting an official Phobos pull request! I agree, it's a good idea to ask the community for feedback. I've replied to you in the github thread, but maybe it would be better to continue the discussion here?
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 13:26:17 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg
wrote:
Should this be allowed for functions that isn't marked with
@property:
foo = 3;
Yes. We should *only* be changing the way @property is
implemented. (Namely, actually implementing it!)
Don't want to break existing code. The new changes must be opt
in.
Here's another way to test if the idea is sound, by asking a few
questions:
For some time, we've had the unrestricted ability to drop empty
"()" and perform assignments to any function with appropriate
sig. Has there been a chorus of complaints about having it? Any
flood of problems caused by it? More importantly, how many of us
are now making good use out of it without even a seconds thought?
How many of us would really miss it if taken out?
I still think there's a lot more to the picture, but I cannot yet
pin it down well enough to say what it is.
I'll try and share my thoughts, so that maybe someone more
knowledgeable than me can figure it out.
What is really bugging me, is that I know there's something more
generalized going on here that we may have an opportunity to take
advantage of, before things get cast in "unbreakable" stone, so
to speak.
I've been asking myself some questions, off the wall stuff, not
necessarily possible for D due to practical limitations, but
perhaps possible for E:
1) Why must a variable operate as it does and why must a function
operate as it does? Are the two "things" really all that much
different? I can successfully imagine that a variable is a
function wrapper around a data store.
2) We're allowing only some functions to operate like variables,
and this is because not all functions are allowed to operate in
this way due to their parameter signature. Specifically, if the
function has more than one parameter, it cannot be used as if it
were a variable.
Example:
// We can do this
void Foo( int ){ ... };
int Foo(){ ... };
Foo = 5;
int Y = Foo;
// so why not something like this?
void Foo( int, string, float ){ ... };
( int, string, float )Foo(){ ... };
Foo = { 1, "test", 3.456 };
{ someint, somestring, sonefloat } = Foo;
Why must we be limited to a single return and a single assignment
value?
(I recall this topic was brought up before, and I know we can use
struct to emulate a similar effect)
3) If some functions can operate like variables, then why must no
variable be able to operate like some functions?
This is not allowed in D:
int x, y;
x(1);
y = x();
y(x());
Why must this be so?
4) Which syntax or constructs are easier to understand, and which
are not, given the context they are used in? If we had choice,
will the context prefer one syntax over another in terms of
clarity? If we don't have choice, then the context may enforce
poor clarity in some cases.
5) We really enjoy the power we get from generic templates, yet
the generic abilities of templates may possibly be lessened
considerably because of the incompatibility between variables and
functions, and I would also say classes and structs, although
with UFCS the situation has improved (which may be why we like
having them so much).
6) What advantage do we get by making variables and functions
incompatible with each other (in terms with how they are
manipulated or operated on), and what advantages could we get if
we made them fully compatible (or at least more compatible).
Hopefully some of these questions will provide food for some
thought on the @property matter.
--rt
Re: @property needed or not needed?
Just a quick thought... it's not like a = 10 has no way to trigger a function anyway. opAssign does it. Is that evil? This discussion kinda reminds me of some of the C++ arguments over operator overloading. They argue overloaded operators are evil because they don't look like function calls... but I think most of us agree that is generally useful. D's properties of course aren't exactly the same but I think there's some similarities there that matter.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote: Here's another way to test if the idea is sound, by asking a few questions: After thinking about it a bit more, I think there may be two conflicting notions: a) The use of optional parenthesis. b) The @property switch, which allows a function to emulate an attribute, namelly, allow writting "bla = a.foo;" or "a.foo = 5;", when "foo" isn't actually an attribute of a. I *could* see parenthesis being optional, but I'll never accept "a.foo = 5" calling "a.foo(5)" if "foo" isn't attribute qualified.
Re: @property needed or not needed?
On Tuesday, November 20, 2012 19:48:01 monarch_dodra wrote: > On Tuesday, 20 November 2012 at 18:06:22 UTC, Rob T wrote: > > Here's another way to test if the idea is sound, by asking a > > > few questions: > After thinking about it a bit more, I think there may be two > conflicting notions: > > a) The use of optional parenthesis. > b) The @property switch, which allows a function to emulate an > attribute, namelly, allow writting "bla = a.foo;" or "a.foo = > 5;", when "foo" isn't actually an attribute of a. Yes, you basically have folks who want to have strictly defined properties which emulate variables (similar to what C# has), and you have folks who simply want to leave off parens (especially when they're using UFCS and already forced to provide a template argument - e.g. with map or filter or whatnot). On some level, they can coexist, and on some level, they're conflicting notions. Given the fact that this subject is extremely devisive, I suspect that the best that we can hope for at this point is for lax property enforcement - that is that it's enforced that @property functions are used as properties but there is no enforcement that non-@property functions be called with parens. We might be able to further restrict them so that they can't be used with the setter syntax (making it so that they must be @property for that to work), but with UFCS and the use of templated functions taking predicates, dropping parens is way too popular to disallow it, much as I personally hate the idea. - Jonathan M Davis
__gshared implicitly convertible to shared?
Would it make sense to make it so that __gshared implicitly converted to shared? It's my understanding that the main purpose of __gshared is to be able to better interact with C code, but given the issues with shared, lots of people have just used __gshared instead of shared. This causes a problem in some cases. For instance, none of Mutex's functions are currently shared in spite of the fact that it really doesn't make sense to have a Mutex which is thread-local, but it can't have all of its functions be only shared, because then it wouldn't work with __gshared. That means that in order to work with both __gshared and shared, all of its functions must be duplicated, which is obviously less than ideal. So, given that __gshared is shared across threads like shared is (just with fewer protections), would it make sense to make it so that __gshared implicitly converts to shared? Then a type like Mutex which is intended to be shared, can just make all of its member functions shared, and it'll work with both __gshared and shared. It may also be necessary to make shared implicitly convert to __gshared for that to work cleanly (particularly when you get stuff like a member function returning a reference variable which then must be shared, even if the original variable were __gshared - because the function itself is shared), and I don't know how big a problem that would be. But I think that the basic idea of allowing implicit conversions at least from __gshared to shared (if not shared to __gshared) is worth exploring. Is there a major reason why it would be a bad idea? My experience with both is limited, and I may just be completely missing something here. - Jonathan M Davis
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
wrote:
Given the fact that this subject is extremely devisive, I
suspect that the
best that we can hope for at this point is for lax property
enforcement
@property shouldn't be about enforcement. This is the fundamental
flaw in the -property switch. While I think you and I are talking
about the same goal, this is an important distinction to make:
the fix isn't syntax. It is a semantic rewrite.
After referencing a property is rewritten to be a call, the
syntax will just work:
@property int foo() {}
int a = foo(); // the error here is NOT "you must not use () on
properties". It is "type int is not callable"
This is something that's bothered me about the @property debate
since day one: we spend all this time talking about syntax
but that's a side effect, not the core question.
Re: Should core.sync.mutex.Mutex, core.sync.condition.Condition, etc. have all their methods be shared?
On Sunday, November 18, 2012 14:48:02 Sean Kelly wrote: > On Nov 18, 2012, at 12:44 PM, Jonathan M Davis wrote: > > So, I concur in that I don't see how the semantics of shared could > > possibly > > not be appropriate for mutexes. I started this thread primarily because I > > was shocked that Mutex, Condition, etc. weren't marked with shared > > already, and I didn't see how they could even be used without it (and > > apparently, the answer to that is that almost everyone cops out and uses > > __gshared). > > I tried this once and it cascaded to requiring modifications of various > definitions on core.sys.posix to add a "shared" qualifier, and since I > wasn't ready to do that I rolled back the changes. I guess the alternative > would be to have a shared equivalent for every operation that basically > just casts away shared and then calls the non-shared function, but that's > such a terrible design I've been resisting it. Well, this is certainly going to need to be sorted out. And given that it's not unreasonable that both shared and __gshared be used with the type is core.sync, I don't think we have much choice to duplicate most of those functions (probably using casting internally to avoid actually duplicating the implementation in most cases) unless __gshared becomes implicitly convertible to shared. - Jonathan M Davis
Re: @property needed or not needed?
On Tuesday, November 20, 2012 20:12:56 Adam D. Ruppe wrote:
> On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
>
> wrote:
> > Given the fact that this subject is extremely devisive, I
> > suspect that the
> > best that we can hope for at this point is for lax property
> > enforcement
>
> @property shouldn't be about enforcement. This is the fundamental
> flaw in the -property switch. While I think you and I are talking
> about the same goal, this is an important distinction to make:
> the fix isn't syntax. It is a semantic rewrite.
>
> After referencing a property is rewritten to be a call, the
> syntax will just work:
>
> @property int foo() {}
>
> int a = foo(); // the error here is NOT "you must not use () on
> properties". It is "type int is not callable"
>
> This is something that's bothered me about the @property debate
> since day one: we spend all this time talking about syntax
> but that's a side effect, not the core question.
It's the same result. @property means that the function is treated as a
variable, so it doesn't make sense that parens be used. If the error treats it
like a variable to the point that it complains about trying to use parens on
the variable rather than the fact that you tried to use parens on an @property
function, all the better.
- Jonathan M Davis
Re: Normal/Gaussian random number generation for D
On 11/20/2012 07:00 PM, jerro wrote: I agree, it's a good idea to ask the community for feedback. I've replied to you in the github thread, but maybe it would be better to continue the discussion here? I replied in the GitHub thread before reading this email! :-P My feeling is that the core normal RNG code is probably fairly well defined, and won't need too many more tweaks. What I see lacking right now are unittests (so far the ones I've written have just been to test that the type inference rules work correctly) and possibly also some additional necessary type constraints (e.g. it would be good to have something like isNormalRandomNumberEngine, and I don't know if you want to add some extra type checks to some of your Ziggurat-related functions). I'd particularly appreciate it if community members could give the type checking a once-over to see if it's adequate/appropriate, whether there are any important checks missing and whether in some cases it's actually too strict (e.g. could we reasonably replace the isNumeric checks with isScalar?). As I wrote on GitHub, I also think it's worth considering if some of the helper functions/structs introduced in these patches could better be moved out to other parts of Phobos for general-purpose use, e.g. your isPowerOfTwo. Lastly, we need to make sure that this new functionality is well documented. Perhaps a good start here could be for people to take a look at the code and describe what isn't clear or easy to understand just from looking ... ? Best wishes, -- Joe
Re: Is there interest in a std.http?
11/20/2012 11:45 PM, Dmitry Olshansky пишет: [snip] I currently had to work with Java (a painful journey after D) to create a couple of server components and surprisingly found the Netty project to be quite nice. The obligatory link: https://netty.io/ -- Dmitry Olshansky
Re: Is there interest in a std.http?
11/20/2012 8:26 AM, Andrei Alexandrescu пишет: On 11/19/12 3:38 PM, Tyler Jameson Little wrote: I'd like to see an HTTP module in Phobos, but I wanted to gauge interest first and see if this has been discussed before. I can say the following. We sorely need a server expert on board with the time and inclination to write a good server-side networking framework. We have a couple, but for various reasons I have been unable to convince them (through newsgroup and private exchanges) to invest time in such an endeavor. That's mostly because lack of time - speaking for myself, I wish I found the time to learn about all that, which as far as I understand gravitates around notions such as asynchronous I/O, libevent/libevt, select(), and the such. I've never used them so I'd need to start from scratch. Having done quite some work on this before - both with frameworks and barehanded. The recipe for scalable and fast server itself is not that hard: asynchronous I/O + event-based notification + separate thread pool for user-defined handlers Asynchronous I/O is well understood to have far less overhead then thread per client/descriptor model. Both in terms of memory usage and time spent on the context switching. Event based notification can be traded for select() polling but then you'd waste a lot of cycles (in kernel mode) walking through huge descriptor sets when number of simultaneous clients is high enough. A separate "worker" thread pool insures your event-loop is not ever blocked thus insuring responsiveness w.r.t dispatching I/O requests. Arguably this could be an opt-in. If this combo is implemented even half-decently it should give us great speed. The fine-tuning and topping the performance however is the other 70% of work and that makes the real difference. The devil is in the details. Not to mention fiddling with socket options and imposing limits on transfer rate/timeouts etc. I currently had to work with Java (a painful journey after D) to create a couple of server components and surprisingly found the Netty project to be quite nice. Though being overly Java-escue it has some great ideas (aside from the above basic concepts): - The composable pipeline abstraction that allows passing user data through a series of transformations seamlessly. Think the stack of TCP|HTTP|encryption/compression or TCP|framing|ProtocolBuffers etc. - Flexible and zero-copy (quite hard for Java I guess) buffer abstraction. It reminds the power of ranges but in a heck of a more limited scale - it's more about chaining and slicing. These limitations are mostly because of the way the OS works. We really need an expert. Look at the Go programming language - it's not remarkable, but it benefits of full-time dedication of experts in server-side programming, so it has acquired excellent library support for networking servers. Can help with a proper asynchronous (network) I/O support on Windows. I doubt I'll find time to flesh out the whole design though. What it irks me that I haven't seen a good enough backend for Windows in the open source (of those I've peeked at the source of). A lot of event-based backends seem to just ignore this OS or fallback to select-loop. Meanwhile M$ introduced the new RIO socket API targeted at high-load servers. Was planing to try it out since the day it was introduced. And they milk that for all it's worth: any discussion, article, or blog post about Go gravitates toward the five-lines HTTP server with the same implacable reach as conversations with ideologists, which inevitably converge towards their ideological stronghold. I see no reason we can't beat them in their favorite game. -- Dmitry Olshansky
Re: @property needed or not needed?
On 11/20/2012 02:49 PM, Regan Heath wrote:
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
Yes. We should *only* be changing the way @property is implemented.
(Namely, actually implementing it!)
Don't want to break existing code. The new changes must be opt in.
Usually I'd agree but this is a case of a wart we should just remove
IMO. The fix for breaking cases is simple, add @property.
If there's both an @property setter and a regular function, the
property should be used here.
Agreed. But it's waay clearer whats going on if @property is required
to call functions using this syntax.
R
Not really.
@property T front(T)(T[] arr) { return arr[0]; }
[1,2,3,4].front;
front = [1,2,3,4];
Re: DConf 2013 on kickstarter.com: we're live!
On 10/22/2012 10:25 AM, Andrei Alexandrescu wrote: We're on! For one month starting today, we're raising funding for DConf 2013. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Please pledge your support and encourage your friends to do the same. Hope to see you in 2013! Thanks, Andrei Woohoo! With a dollar to spare: :) 155 Backers $30,000 pledged of $29,999 goal Ali
DConf 2013 on kickstarter.com: we made it!
I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Lets hold a big congrats to Andrei and Walter. Look forward to seeing you all in April/May.
Re: DConf 2013 on kickstarter.com: we're live!
On 11/20/12 3:18 PM, Ali Çehreli wrote: Woohoo! With a dollar to spare: :) 155 Backers $30,000 pledged of $29,999 goal We did it! Congratulations to everyone who helped and to the entire D community! Now let's get to work - we've got a lot of planning to do. Please start thinking about submitting a talk proposal (title, abstract, and bio). Andrei
Re: DConf 2013 on kickstarter.com: we made it!
On 11/20/12 3:23 PM, Iain Buclaw wrote: I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Thanks! Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 11/20/12 3:18 PM, Ali Çehreli wrote: Woohoo! With a dollar to spare: :) 155 Backers $30,000 pledged of $29,999 goal Ali On reddit: http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0? Andrei
Re: DConf 2013 on kickstarter.com: we're live!
On 11/20/12 3:42 PM, Andrei Alexandrescu wrote: On 11/20/12 3:18 PM, Ali Çehreli wrote: Woohoo! With a dollar to spare: :) 155 Backers $30,000 pledged of $29,999 goal Ali On reddit: http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0? I mean: http://www.reddit.com/r/programming/comments/13iz81/the_d_conference_2013_raises_3_on/ Andrei
Re: half datatype?
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote: Nice case study! Thanks! Looks like a cool little game too :P Watched the video. Interesting looking game, but how long it was taking to move around the ships gives a sense of size, making me ask myself 'my god, how big IS that ship?'.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference. We can just define this away: &funName if it isn't a @property is the address of the function. So this is impossible to get the address of the returned reference. If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()). I agree that this is ho it should work.
Re: DConf 2013 on kickstarter.com: we made it!
On 11/20/2012 12:42 PM, Andrei Alexandrescu wrote: On 11/20/12 3:23 PM, Iain Buclaw wrote: I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Thanks! Woo-hoo!
Re: Bret Victor - Inventing on Principle
On 11/19/2012 8:30 PM, Andrei Alexandrescu wrote: On 11/19/12 7:50 PM, Walter Bright wrote: On 11/19/2012 6:26 AM, Regan Heath wrote: Hope no-one minds.. I stumbled across this video which I thought was pretty darn cool: http://www.youtube.com/watch?v=PUv66718DII Can you give us a summary or synopsis? "Worth watching." Ok, I watched it. I thought his principle was a great one, although it's pushing on a well-known idea that the faster the feedback cycle on a design, the more you can "play" with the design to optimize it.
Re: DConf 2013 on kickstarter.com: we made it!
On Tuesday, 20 November 2012 at 20:23:56 UTC, Iain Buclaw wrote: I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Lets hold a big congrats to Andrei and Walter. Look forward to seeing you all in April/May. Awesome :)
Re: @property needed or not needed?
On 11/20/2012 09:56 PM, deadalnix wrote: On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference. We can just define this away: &funName if it isn't a @property is the address of the function. So this is impossible to get the address of the returned reference. &funName() If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()). I agree that this is ho it should work. +1.
Re: DConf 2013 on kickstarter.com: we made it!
On 2012-11-20 21:23, Iain Buclaw wrote: I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Lets hold a big congrats to Andrei and Walter. Look forward to seeing you all in April/May. Really great :) -- /Jacob Carlborg
Re: half datatype?
I've used half in C++, although mostly just to feed to the GPU since its pretty common that you don't want to waste the bandwidth on 32 bit floats.
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 19:12:58 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2012 at 19:06:22 UTC, Jonathan M Davis
wrote:
Given the fact that this subject is extremely devisive, I
suspect that the
best that we can hope for at this point is for lax property
enforcement
@property shouldn't be about enforcement. This is the
fundamental flaw in the -property switch. While I think you and
I are talking about the same goal, this is an important
distinction to make: the fix isn't syntax. It is a semantic
rewrite.
After referencing a property is rewritten to be a call, the
syntax will just work:
@property int foo() {}
int a = foo(); // the error here is NOT "you must not use () on
properties". It is "type int is not callable"
Yes
This is something that's bothered me about the @property debate
since day one: we spend all this time talking about syntax
but that's a side effect, not the core question.
+1
Re: @property needed or not needed?
On Tuesday, 20 November 2012 at 21:19:20 UTC, Timon Gehr wrote: On 11/20/2012 09:56 PM, deadalnix wrote: On Tuesday, 20 November 2012 at 13:35:14 UTC, Adam D. Ruppe wrote: On Tuesday, 20 November 2012 at 06:06:21 UTC, deadalnix wrote: I'm not sure how it fit in the DIP but &funName is ambiguous when funName return a reference. We can just define this away: &funName if it isn't a @property is the address of the function. So this is impossible to get the address of the returned reference. &funName() So now funName and funName are not equivalent anymore. Special cases should be removed, not added. If it is a @property, ALL operations work on the return value, so it is rewritten as &(funName()). I agree that this is ho it should work. +1.
Re: DConf 2013 on kickstarter.com: we made it!
On 11/20/12 21:23 , Iain Buclaw wrote: I got tired of the suspense, so I pledged the remainder $550 to push you over the finish line. http://www.kickstarter.com/projects/2083649206/the-d-programming-language-conference-2013-0 Lets hold a big congrats to Andrei and Walter. Look forward to seeing you all in April/May. Cowabunga! \o/
Google Fight - D vs Go
This probably doesn't mean all that much, but I find it interesting that Go is only slightly ahead of D when comparing d programming and go programming, and D is only slightly ahead of Go when comparing "d programming and "go programming": http://www.googlefight.com/index.php?lang=en_GB&word1=d+programming&word2=go+programming http://www.googlefight.com/index.php?lang=en_GB&word1=%22d+programming%22&word2=%22go+programming%22 The hit count when using parens is pretty low though. Regardless, I find it somewhat interesting that D and Go are getting such similar search results in terms of numbers. Given that it's from google, I would have expected Go to do better than it's doing in comparison to us (though it's quite possible that the search for Go is returning more useful hits). - Jonathan M Davis
Re: __gshared implicitly convertible to shared?
On Tuesday, 20 November 2012 at 19:15:01 UTC, Jonathan M Davis wrote: Would it make sense to make it so that __gshared implicitly converted to shared? It's my understanding that the main purpose of __gshared is to be able to better interact with C code, but given the issues with shared, lots of people have just used __gshared instead of shared. This causes a problem in some cases. For instance, none of Mutex's functions are currently shared in spite of the fact that it really doesn't make sense to have a Mutex which is thread-local, but it can't have all of its functions be only shared, because then it wouldn't work with __gshared. That means that in order to work with both __gshared and shared, all of its functions must be duplicated, which is obviously less than ideal. So, given that __gshared is shared across threads like shared is (just with fewer protections), would it make sense to make it so that __gshared implicitly converts to shared? Then a type like Mutex which is intended to be shared, can just make all of its member functions shared, and it'll work with both __gshared and shared. It may also be necessary to make shared implicitly convert to __gshared for that to work cleanly (particularly when you get stuff like a member function returning a reference variable which then must be shared, even if the original variable were __gshared - because the function itself is shared), and I don't know how big a problem that would be. But I think that the basic idea of allowing implicit conversions at least from __gshared to shared (if not shared to __gshared) is worth exploring. Is there a major reason why it would be a bad idea? My experience with both is limited, and I may just be completely missing something here. - Jonathan M Davis I'm short on time, and so can't double-check the online docs or the book, but as I recall (having never actually used __gshared... yet) they differ in that shared is a type constructor and __gshared is a declaration attribute. So I'm just not sure. On the one hand, the compiler would always be able to see that either the left or right side of an assignment (or the inside of an argument list) includes a __gshared variable, and could do the "right" thing... But on the other hand it would be an odd special case of a type qualifier being cast away because of a variable's attribute. Is this something we want? Or is it intended as a short-term workaround until shared is more fully/correctly defined semantically?
Re: Downloadable spec for D version 2
On 11/20/2012 9:53 AM, Dan wrote: On Tuesday, 20 November 2012 at 02:27:08 UTC, Edward Diener wrote: Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ? I got it from amazon for kindle for $0.99. http://www.amazon.com/D-Programming-Language-Specification-ebook/dp/B005CCQPKK/ref=sr_1_1?s=books&ie=UTF8&qid=1353422974&sr=1-1&keywords=d+programming+language+specification If you don't have a kindle you could still read with amazon cloud reader - but this is not great because no search or copy/paste. However, you can download and convert the amazon format to mobi and probably pdf with calibre which is a great tool. So the D Language Spec version 2 is only in Kindle format, and not in PDF or HTML anyplace it can be downloaded ?
Re: Normal/Gaussian random number generation for D
isNormalRandomNumberEngine, and I don't know if you want to add some extra type checks to some of your Ziggurat-related functions). Yes, I need to add some checks. Currently, there aren't any :D Lastly, we need to make sure that this new functionality is well documented. Perhaps a good start here could be for people to take a look at the code and describe what isn't clear or easy to understand just from looking ... ? By functionality, do you mean just the API or also the implementation? I assume my Ziggurat algorithm implementation isn't easy to understand without some kind of description. I'll need to write a ton of comments in there.
Re: Downloadable spec for D version 2
On Wednesday, 21 November 2012 at 00:44:11 UTC, Edward Diener wrote: ... So the D Language Spec version 2 is only in Kindle format, and not in PDF or HTML anyplace it can be downloaded ? Yes... Not good ! I'm interested in "D". Still. Working on. I bought the Alexandrescu book, fine. I am always ok to buy good books. But why not to provide, in some way, references, in the classical "smart Unix/FSF... way" ?? I think it's not a good way. Not good for "promoting" a good language. In fact, as an old Unix aficionado, often, for some topics, if I cannot get source + doc, the tool goes away... And sure I'm not alone. Have you seen the case for "go". Couldn't find any doc, must be online for reference !
Re: Downloadable spec for D version 2
On Tuesday, 20 November 2012 at 02:27:08 UTC, Edward Diener wrote: Is there a downloadable spec for the D version 2 language, in either PDF or HTML format ? The HTML version is in the ZIP with dmd... G.
Re: half datatype?
On Tuesday, 20 November 2012 at 09:11:07 UTC, Manu wrote: Nice case study! Thanks! Looks like a cool little game too :P AFAIK, tart also has a prototype of realtime GC, but I don't know whether it can solve your problem. Such things are of little priority now for D and general purpose programming, I think.
Re: @property needed or not needed?
Le 20/11/2012 12:18, Timon Gehr a écrit :
On 11/20/2012 02:49 PM, Regan Heath wrote:
On Tue, 20 Nov 2012 13:26:15 -, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2012 at 12:44:44 UTC, Jacob Carlborg wrote:
Should this be allowed for functions that isn't marked with @property:
foo = 3;
Yes. We should *only* be changing the way @property is implemented.
(Namely, actually implementing it!)
Don't want to break existing code. The new changes must be opt in.
Usually I'd agree but this is a case of a wart we should just remove
IMO. The fix for breaking cases is simple, add @property.
If there's both an @property setter and a regular function, the
property should be used here.
Agreed. But it's waay clearer whats going on if @property is required
to call functions using this syntax.
R
Not really.
@property T front(T)(T[] arr) { return arr[0]; }
[1,2,3,4].front;
front = [1,2,3,4];
I conclude that @property should be limited to member function or UFCS
calls. Otherwize, we get really weird stuffs going on.
Re: A working way to improve the "shared" situation
Le 15/11/2012 08:56, Sönke Ludwig a écrit : Since the "Something needs to happen with shared" thread is currently split up into a low level discussion (atomic operations, memory barriers etc.) and a high level one (classes, mutexes), it probably makes sense to explicitly state that this proposal here applies more to the latter. One problem remains : even with isolated like you propose, some memory barriers are required (acquire/release semantic is required). So it does seems pretty hard to get away with it only using lib.
Re: @property needed or not needed?
Le 20/11/2012 04:33, Jacob Carlborg a écrit :
On 2012-11-20 08:48, thedeemon wrote:
This is just an old habit to see identifier with parens as a function
call and identifier without parens as a variable, so calling functions
without parens seem too unconventional to you. However there are many
languages which dropped this tradition and they are known for being
expressive and concise, that's why people love them. Recently we saw an
article from Walter about component programming which one could say was
really about function composition. It's really convenient to write code
in conveyor-style, this is what we see often in functional languages, as
well as some dynamic OO ones. For example, the task of reversing words
in a string may look like:
I completely agree.
"one two three".split.map{|s| s.reverse}.join(' ')
in Ruby
In this particular case you can use a shorter form of the map call:
"one two three".split.map(&:reverse).join(' ')
print . unwords . map reverse . words $ "one two three"
in Haskell
"one two three" |> split " " |> List.map reverse |> String.join " " |>
print_string
in OCaml
and something similar and even without dots in Scala.
Wouldn't the Scala syntax look fairly similar to Ruby:
"one two three".split.map(reverse).join(' ')
Note the map(reverse) and not map(&reverse)
Ease of chaining functions together is one of the things that make those
languages so pleasant to work with. I love to have the same in current D
and it would be a pity to lose it due to a clash with some old-fashioned
tradition.
I completely agree again.
Re: @property needed or not needed?
On 2012-11-21 07:55, deadalnix wrote: Note the map(reverse) and not map(&reverse) I said "fairly similar" not "exactly the same" :) -- /Jacob Carlborg
Re: __gshared implicitly convertible to shared?
On 2012-11-20 20:14, Jonathan M Davis wrote: Would it make sense to make it so that __gshared implicitly converted to shared? It's my understanding that the main purpose of __gshared is to be able to better interact with C code, but given the issues with shared, lots of people have just used __gshared instead of shared. I don't think it's just because there are issues with "shared". If "shared" means other semantics than just a global variable the D code will have different semantics when accessing the variable compared to the C code. I don't think that's a good idea. If it's not safe to just access the variable as is, I think it's better to add a safe wrapper then changing the semantics of the bindings. -- /Jacob Carlborg
Re: A working way to improve the "shared" situation
Am 21.11.2012 07:11, schrieb deadalnix: > Le 15/11/2012 08:56, Sönke Ludwig a écrit : >> Since the "Something needs to happen with shared" thread is currently split >> up into a low level >> discussion (atomic operations, memory barriers etc.) and a high level one >> (classes, mutexes), it >> probably makes sense to explicitly state that this proposal here applies >> more to the latter. > > One problem remains : even with isolated like you propose, some memory > barriers are required > (acquire/release semantic is required). So it does seems pretty hard to get > away with it only using > lib. Right, it only solves the lock-based part of the shared world, where the mutex ensures proper acquire/release. As for the rest, after all that discussion I'm still not convinced that letting the compiler insert something automatically makes sense - it may impair performance, just avoids a small part of the pool of potential bugs and only really works for small types. Just disallowing all usual operations on shared values*, making sure that access follows volatile semantics and providing the appropriate atomic operations/barriers as functions/intrinsics looks like a sufficient solution to me, given how seldom this is needed and how critical the details are - and that seems about to be the status quo. But since I only have lock-free stuff in a few places and I'm sure that those can be kept working with whatever the final system will look like, I'm not so strongly opinionated there. It's different with lock based stuff, this is currently just an unusable mess and a strict/safe solution that is later relaxed is probably a better plan than the opposite (e.g. if synchronized classes would automatically provide access to their non-shared fields from inside of their methods). * Just noticed that this is another case for Rebindable!T as you usually do not want to disallow non-atomic access to a shared class reference, but sometimes you need to. A nice little syntax for the head-X and X distinction would be so nice :-/
