On 2013-01-28 23:09, alex wrote:
Yeah I just named it Expression evaluation - dunno why, just thought
that it could be used in a more general way than 'only' for mixin insight.
Should I do an extra input box where you could type in expressions and
other things that could be evaluated? Just
On 2013-01-29 03:14, alex wrote:
On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
Meaning, imagine your screen looks like:
CODE | EXAMPLE RESULTS
|
int
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to mark symbols for internal linkage at all? How about
something like @internal?
On Tuesday, 29 January 2013 at 09:42:49 UTC, Timon Gehr wrote:
On 01/29/2013 03:14 AM, alex wrote:
On Tuesday, 29 January 2013 at 00:48:24 UTC, F i L wrote:
...
http://mono-d.alexanderbothe.com/?attachment_id=817
My progress so far. Lots of internals to manage though. The
execute-button isn't
On Tuesday, 29 January 2013 at 08:02:27 UTC, Jacob Carlborg wrote:
...
Yeah, that was s cool. I also liked the code bubbles.
Instead of having a file as the minimum abstraction unit in the
IDE/editor it was a function/class/method.
Which can be done in Eclipse by just selecting e.g. a
On 2013-01-29 11:52, alex wrote:
Which can be done in Eclipse by just selecting e.g. a method or class in
the outline - iirc it'll just show the definition of the selected node
then, nothing else.
If I select an item in the outline view it will just scroll the editor
view to where that item
On 29/01/2013 10:52, alex wrote:
On Tuesday, 29 January 2013 at 08:02:27 UTC, Jacob Carlborg wrote:
...
Yeah, that was s cool. I also liked the code bubbles. Instead of
having a file as the minimum abstraction unit in the IDE/editor it was
a function/class/method.
Which can be done in
On 25/01/2013 13:43, Jacob Carlborg wrote:
On 2013-01-25 13:01, Bruno Medeiros wrote:
If I was going with that approach I likely would rather port the MonoD
parser since it looks just as good, if not better, and C# would be
easier to port to Java than D.
But the descent.compiler experience
On 11 January 2013 23:57, Namespace rswhi...@googlemail.com wrote:
At first: I apologize for any errors in my grammar because I'm from
Germany and therefore English is not my native language.
Dgame is a 2D framework for D and it is completly written in D.
You can find the documentation, a
Am 29.01.2013 15:54, schrieb Namespace:
I see no makefiles to build Dgame. :o)
Now. ;)
But actually the needed .lib files are in the directories 'Debug' and
'Release'.
Don't forget to read this tutorial:
http://dgame-dev.de/?page=tutorialtut=installation
I should link this on the download
On Tuesday, 29 January 2013 at 15:00:43 UTC, David wrote:
Am 29.01.2013 15:54, schrieb Namespace:
I see no makefiles to build Dgame. :o)
Now. ;)
But actually the needed .lib files are in the directories
'Debug' and
'Release'.
Don't forget to read this tutorial:
Am 29.01.2013 16:10, schrieb Namespace:
Ahh. That could be a problem: I hate makefiles and never wrote one.
Hehe,
to quote ibuclaw:
`make no-sense`
It doesn't need to be a makefile, some kind of build-script, which
automates the process of building the library. E.g. a d file which
compiles the
On 2013-01-29 13:34, Bruno Medeiros wrote:
Ah, fair enough. Yes, that could be an approach, although I dread a bit
the thought of having to interface D data to Java through a C API... it
might work though if one is carefull and manages to keep the interfacing
data simple enough (and leave the
On Tuesday, 29 January 2013 at 15:19:37 UTC, David wrote:
Am 29.01.2013 16:10, schrieb Namespace:
Ahh. That could be a problem: I hate makefiles and never wrote
one.
Hehe,
to quote ibuclaw:
`make no-sense`
It doesn't need to be a makefile, some kind of build-script,
which
automates the
Forget to say:
Because of the new build script you have now a lib file for each
package of Dgame.
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or ability to
mark symbols for internal linkage at all? How about something like
@internal?
I only oppose changing the meaning of static. I
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to
mark symbols for internal linkage at all? How about something
On 2013-01-29 13:26, Bruno Medeiros wrote:
By default, yes, but you can do what Jacob wanted with the Show Source
of Selected Element Only functionality:
http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.user/reference/views/ref-java-editor.htm
That's somewhat similar to what
On Tuesday, 29 January 2013 at 16:44:56 UTC, Timon Gehr wrote:
On 01/29/2013 11:29 AM, Dicebot wrote:
Fixing private is enough.
...
No need to screw this up.
By the way, do you oppose exactly static keyword usage or
ability to
mark symbols for internal linkage at all? How about something
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote:
http://wiki.dlang.org/DIP22
I think your going to need to give some evidence to the problems
with the current behavior.
dlang.org states that Private module members are equivalent to
static declarations in C programs. but this is
20 matches
Mail list logo
