headers
Adam D. Ruppe | 7 Feb 2012 01:04
Picon

Re: std.xml and Adam D Ruppe's dom module

On Monday, 6 February 2012 at 23:15:50 UTC, Alvaro wrote:
> Its "dom" module has that sort of Javascript-like DOM 
> manipulation code

I'm biased (obviously), but I've never seen a more convenient
way to work with xml. I like my convenience functions a lot.

> I thus suggest, if licensing allows (?

It is Boost licensed, so you can use it (I put the license
at the bottom of my files).

I don't know if it is phobos material, but if there's demand,
maybe I can make that happen.

> A lot of that can be left out in XML.

Right, though you can ignore it too. I sometimes use it
to work with other kinds of xml (web apis sending and receiving),
RSS, and others.

It works well enough for me.
Permalink | Reply | 4 comments |
headers
Steven Schveighoffer | 7 Feb 2012 01:16
Picon
Favicon
Gravatar

Re: Possible to pass a member function to spawn?

On Mon, 06 Feb 2012 16:38:03 -0500, Oliver Puerto <saxo123 <at> gmx.de> wrote:

> Hello,
>
> I'm very new to D. Just started reading "The D programming language". I  
> should read it from beginning to end before posting questions here. I  
> know ... But I'm just too impatient. The issue seems not to be that  
> simple, nevertheless. The code below compiles with Visual Studio.
>
> I want to have something like my actor class that I can start running in  
> it's own thread like in Scala or other languages that support actors. So  
> at best, I would like to do something like this:
>
>     MyActor myActor = new MyActor();
>     auto tid = spawn(&start, &myActor.run());
>
> However, this doesn't work. So I came up with the solution below where  
> the start function is called with myActor as an argument.

Welcome to D!

Unfortunately, it looks like functions are the only runnable types via  
spawn.  There should technically be a delegate version, and then you would  
be able to do:

auto tid = spawn(&myActor.run);

which would run the run() method of myActor in a separate thread.  I'm not  
sure what the technical limitation, but I think it has to do with  
guarantees that no unshared data is passed (I don't believe it was
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonathan M Davis | 7 Feb 2012 02:03
Picon
Favicon

Re: Deprecated language features

On Friday, February 03, 2012 02:46:31 Daniel Murphy wrote:
> There are a bunch of features that are planned for removal, and some that
> are already deprecated, but no clear timeline for removal.  I'd like to make
> a comprehensive list, pick suitable durations, then I'll make a wiki page
> for this.
> 
> What I've got so far is...
> 
> Planned for deprecation:
> - float.min
> - complex and imaginary types
> - NCEG operators
> - array.sort and array.reverse
> - delete?
> 
> Deprecated:
> - Using length inside index expressions
> - typedef
> - variable shadowing
> - invariant as an alias for immutable
> - derefencing arrays with *
> - delete aa[key] (same as aa.remove(key))
> - .offset
> - escape string literals
> - 'l' suffix for integer literals
> - octal literals
> - 'I' suffix for imaginary literals
> - html source files
> - Type.typeinfo syntax
> - base class protection
(Continue reading)

Permalink | Reply | 0 comments |
headers
H. S. Teoh | 7 Feb 2012 02:13

Re: [OT] Programming language WATs

OK, so this thread was supposed to be about WATs in D. Today I found
one.

	std.stdio.File != std.stream.File

which means you can't assign stdin to InputStream.

Yes I know, you need to import cstream and use cstream.din instead, but
this is very counterintuitive to a newcomer. It certainly elicited a WAT
from me today when I first ran into this schizophrenic split between
std.stdio (which is pretty much used in every D code example I've seen,
which gives the impression that it's the "native" and "default" thing to
use) and std.stream (which one would expect should naturally extend the
functionality of std.stdio, but it doesn't).

T

--

-- 
The best compiler is between your ears. -- Michael Abrash
Permalink | Reply | 6 comments |
headers
Jonathan M Davis | 7 Feb 2012 02:18
Picon
Favicon

Re: [OT] Programming language WATs

On Monday, February 06, 2012 17:13:28 H. S. Teoh wrote:
> OK, so this thread was supposed to be about WATs in D. Today I found
> one.
> 
> 	std.stdio.File != std.stream.File
> 
> which means you can't assign stdin to InputStream.
> 
> Yes I know, you need to import cstream and use cstream.din instead, but
> this is very counterintuitive to a newcomer. It certainly elicited a WAT
> from me today when I first ran into this schizophrenic split between
> std.stdio (which is pretty much used in every D code example I've seen,
> which gives the impression that it's the "native" and "default" thing to
> use) and std.stream (which one would expect should naturally extend the
> functionality of std.stdio, but it doesn't).

I guess that it depends on how you think or what you're used to. I wouldn't 
necessarily expect std.stream to be related to std.stdio at all. Certainly. in 
C++, stream-based and non-stream-based I/O isn't related at all (or if it is, 
it's an implementation detail). So, my general expectation is that they're 
completely separate, though I suppose that they don't _have_ to be designed 
that way.

Given that std.stream has its own File type, that would make it pretty obvious 
that the File from std.stdio would not work with std.stream. But I guess that 
you could see a function taking File in std.stream without having read enough 
of std.stream's documentation to realize that it had its own File type.

- Jonathan M Davis
(Continue reading)

Permalink | Reply | 5 comments |
headers
bearophile | 7 Feb 2012 02:23
Picon

Front-end tools, Coccinelle and acceleration

From a recent blog post by Bartosz Milewski
(http://bartoszmilewski.com/2012/02/06/call-your-headhunter/ ):

>Chandler Carruth had an interesting talk about the progress of the Clang project. They have open-sourced
their C++ front-end and made possible the creation of smart tools that can work on very large C++ projects.
Large projects sooner or later enter the stage when maintenance is nightmare. Chandler demonstrated
that it doesn’t have to be so. Instead of propagating a top-level modification by hand through millions
of lines of code, you can write a short program that uses the C++ front-end to make exactly the
modifications that are needed -- more reliably than a human. This includes understanding and, if
necessary, modifying macros.<

In https://github.com/D-Programming-Language/dmd/ I have seen several times long patches that have
required a long time to be created, despite they are boring and are just a repetition of the same little
change carried on  a lot of code.

More tools to perform similar boring tasks more automatically will probably improve the life of future D
programmers, so I think they are important for the spreading of D language.

There is Coccinelle, able to perform semantic patching:
http://coccinelle.lip6.fr/
http://lwn.net/Articles/315686/

Coccinelle is nice, but I don't know how badly it works on D code, and if you want to use it you need some time to
learn its pattern language.

Beside tools like Coccinelle, that surely it's possible to write for D too, is it possible to improve the D
language (or the D front-end, to give something like those smart Clang tools) to help future refactoring
tools? Experience has shown that such meta-tools (like GitHub) are sometimes very useful.

Bye,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan M Davis | 7 Feb 2012 02:46
Picon
Favicon

assumeSafeAppend and purity

At present, assumeSafeAppend isn't pure - nor is capacity or reserve. AFAIK, 
none of them access any global variables aside from GC-related stuff (and new 
is already allowed in pure functions). All it would take to make them pure is 
to mark the declarations for the C functions that they call pure (and those 
functions aren't part of the public API) and then mark them as pure. Is there 
any reason why this would be a _bad_ idea?

Appender runs into similar difficulties. Would it make sense to just mark the 
various memory-related functions in core.memory as pure (or at least some 
subset of them)? The fact that they aren't in spite of the fact that they 
involve memory like new does really makes it hard to both use pure and 
optimize code in a number of cases - especially when dealing with arrays. We 
might also want to just mark malloc as pure for the same reason.

What are the downsides to doing this? It probably wouldn't be a good idea to 
mark functions like free pure, but the ones that involve allocating or 
reallocating memory seem like good candidates for it.

- Jonathan M Davis
Permalink | Reply | 0 comments |
headers
Vladimir Panteleev | 7 Feb 2012 02:54
Favicon
Gravatar

Re: assumeSafeAppend and purity

On Tuesday, 7 February 2012 at 01:47:12 UTC, Jonathan M Davis 
wrote:
> At present, assumeSafeAppend isn't pure - nor is capacity or 
> reserve. AFAIK, none of them access any global variables aside 
> from GC-related stuff (and new is already allowed in pure 
> functions). All it would take to make them pure is to mark the 
> declarations for the C functions that they call pure (and those 
> functions aren't part of the public API) and then mark them as 
> pure. Is there any reason why this would be a _bad_ idea?

pure void f(const(int)[] arr)
{
	debug /* bypass purity check to pretend assumeSafeAppend is pure 
*/
	{
		assumeSafeAppend(arr);
	}
	arr ~= 42;
}

void main()
{
	int[] arr = [0, 1, 2, 3, 4];
	f(arr[1..$-1]);
	assert(arr[4] == 4, "f has a side effect");
}
Permalink | Reply | 1 comment |
headers
Jonathan M Davis | 7 Feb 2012 03:01
Picon
Favicon

Re: assumeSafeAppend and purity

On Tuesday, February 07, 2012 02:54:40 Vladimir Panteleev wrote:
> On Tuesday, 7 February 2012 at 01:47:12 UTC, Jonathan M Davis
> 
> wrote:
> > At present, assumeSafeAppend isn't pure - nor is capacity or
> > reserve. AFAIK, none of them access any global variables aside
> > from GC-related stuff (and new is already allowed in pure
> > functions). All it would take to make them pure is to mark the
> > declarations for the C functions that they call pure (and those
> > functions aren't part of the public API) and then mark them as
> > pure. Is there any reason why this would be a _bad_ idea?
> 
> pure void f(const(int)[] arr)
> {
> 	debug /* bypass purity check to pretend assumeSafeAppend is pure
> */
> 	{
> 		assumeSafeAppend(arr);
> 	}
> 	arr ~= 42;
> }
> 
> void main()
> {
> 	int[] arr = [0, 1, 2, 3, 4];
> 	f(arr[1..$-1]);
> 	assert(arr[4] == 4, "f has a side effect");
> }

Except that assumeSafeAppend was misused. It's dangerous to use when you don't
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Helyer | 7 Feb 2012 03:03
Picon
Gravatar

Re: [OT] I ported Empire to D2 and made it cross platform.

On Monday, 6 February 2012 at 18:04:24 UTC, Stewart Gordon wrote:
> On 06/02/2012 13:48, Bernard Helyer wrote:
> <snip>
>> I started with Walter's original 2.01 D release. The font I'm 
>> using is proportional, so
>> I've not a problem there.
>
> You mean "The font I'm using is fixed"?  You'd have to for it 
> to make any sense.

Derp. Yeah.

>
> But do look at the StatusPanel class in my version if you 
> haven't already.  (You'll notice that it's a bit of a hack that 
> works because the code treats strings passed into it as 
> immutable, although immutable doesn't exist with it being D1.  
> Of course, when porting to D2, they would be declared as such.
>
> BTW I've attached my list of bugs I found and changes I made.  
> Use it as a checklist if you like (and you find the inclination 
> to carry on working on it).

Thanks!

>
> Stewart.
Permalink | Reply | 0 comments |

Gmane