Re: Dgame revived

2015-02-21 Thread uri via Digitalmars-d-announce

On Saturday, 21 February 2015 at 14:43:57 UTC, Namespace wrote:
Today I registered Dgame on DUB. Since I do not currently have 
much time (I'm currently in my exams period) I hope I did 
everything right. Let me know if not and what could be improved.


Since I left D a while ago, Dgame was also not maintained, but 
thanks to your demand I will maintain Dgame again. The current 
goal is to register Dgame successful on DUB. The next goal 
would be to adapt the webpage and the installation chapter and 
to re-register the domain dgame.dev.de
After that (and after my hopefully successful exams) I will 
rebuild Dgame from scratch with the goal of a more consistent 
and better structure and with the idea in mind to use @nogc 
wherever possible.


Great news, thanks heaps :-)


Re: Somewhat off-topic: Nemiver

2015-02-12 Thread uri via Digitalmars-d

On Friday, 13 February 2015 at 07:42:41 UTC, weaselcat wrote:
On Thursday, 12 February 2015 at 23:18:29 UTC, Brian Schott 
wrote:
I've been looking for a graphical front-end for GDB that's not 
terrible, and I've found that Nemiver works pretty well. It's 
worth trying out if you're on Linux.


https://wiki.gnome.org/Apps/Nemiver/Features


Nemiver works perfectly with D, is dead simple to use, and is 
probably one of the best debuggers(frontend, anyways) around 
IMO.



I was using Nemiver because it just worked really well with D.

Another great GDB frontend, especially for vim users is CGDB.

Cheers,
uri


Re: Better native D 2D graphics library?

2015-02-08 Thread uri via Digitalmars-d-learn

On Saturday, 7 February 2015 at 23:29:01 UTC, Namespace wrote:

On Saturday, 7 February 2015 at 22:09:03 UTC, Gan wrote:

Is there a better D graphics library in the works?

I'm using SFML(which is very easy and has lots of features) 
but it seems to use a lot of ram(if you leave it running for a 
while on a graphic intensive scene) and trying to make it 
include the dependencies with the compiled executable is 
complicated.


Is there a D 2D graphics library that's just as easy, cross 
platform, doesn't use X11, allows drawing to off-screen 
buffers and drawing those to screen? (plus supports nice 
drawing of shapes, circles, rectangles, lines)


I'm probably asking too much- I doubt such a thing exists.


I once wrote such a library: https://github.com/Dgame/Dgame
But since I left D I don't maintain it. Maybe that will change 
in the next few weeks. But otherwise you are free to use or 
improve it.


I use Dgame for hobby projects and can definitely recommend it.


Re: Should we remove int[$] before 2.067?

2015-02-01 Thread uri via Digitalmars-d

On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:



Whatever, anyway.


Translation of that being:

Boring pedestrian issues like simple string logging are 
bikeshedded for YEARS, yet PhD-level esoteric stuff makes it 
into phobos with relative ease.


https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md

cautios and determination, isn't? or, revolutionary and 
conservative, how I did put it...


+1

At least decisions are finally being made on several fronts 
recently though.


W.r.t this feature, I was personally looking forward to it ... 
guess I'll stick with the Octave/R/Python troika for rapid 
protoyping numerical analysis code.












Re: Should we remove int[$] before 2.067?

2015-02-01 Thread uri via Digitalmars-d
On Sunday, 1 February 2015 at 15:36:04 UTC, Andrei Alexandrescu 
wrote:

On 2/1/15 2:00 AM, uri wrote:

On Sunday, 1 February 2015 at 09:46:45 UTC, eles wrote:



Whatever, anyway.


Translation of that being:

Boring pedestrian issues like simple string logging are 
bikeshedded
for YEARS, yet PhD-level esoteric stuff makes it into phobos 
with

relative ease.

https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md

cautios and determination, isn't? or, revolutionary and 
conservative,

how I did put it...


+1

At least decisions are finally being made on several fronts 
recently

though.

W.r.t this feature, I was personally looking forward to it ... 
guess
I'll stick with the Octave/R/Python troika for rapid 
protoyping

numerical analysis code.


Which feature are you referring to? -- Andrei


int[$] a=[1,2,3];

The syntax sugar helps when prototyping ideas, which is why R and 
Octave (MATLAB) are so useful. I have reservations about this:


auto a=[1,2,3].s

Because the type is hidden from the programmer... For my use case 
(prototyping code) it's a don't care but in production code it 
might be a problem, as others have pointed out already. I 
actually use this trick already in my own code for malloc'd 
arrays to avoid the GC and add sugar to toStringz.


All in all it is great to see some decisions been made. I think 
it will help shut down bike shedding and get D moving forward at 
a faster rate.


Cheers uri


Re: One area where D has the edge

2015-01-26 Thread uri via Digitalmars-d

On Monday, 26 January 2015 at 22:53:15 UTC, Paulo Pinto wrote:

On Monday, 26 January 2015 at 22:12:24 UTC, Laeeth Isharc wrote:

 If Java consumes 15% more power doing it, does
it matter on a PC? Most people don't dare. Does it matter 
for small-scale server environments? Maybe not. Does it 
matter when you deploy Hadoop on a 10,000 node cluster, and 
the holistic inefficiency (multiple things running 
concurrently) goes to 30%? Ask the people who sign the 
checks for the power bill. Unfortunately, inefficiency 
scales really well.


No, Java does not consume 15% doing it, because there isn't 
just one implementation of Java compilers.


Most comercial JVMs do offer the capability of ahead of time 
native code compilation or JIT caches.


So when those 15% really matter, enterprises do shell out the 
money for such JVMs.


Oracle commercial JVM and the OpenJDK are just the reference 
implementation.


Thanks for the colour.  (For clarity, the content from the 
link wasn't by me, and I meant the general gist rather than 
the details).  How do commercial JVMs rate in terms of memory 
usage against thoughtful native (D) code implementations?  Is 
the basic point mistaken?



So far I just dabbled in D, because our customers choose the 
platforms, not we.


However, these are the kind of tools you get to analyse 
performance in commercial JVMs,


http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mission-control-1998576.html

http://www.oracle.com/technetwork/server-storage/solarisstudio/features/performance-analyzer-2292312.html

Just providing the examples from Oracle, other vendors have 
similar tools.


With them, you can drill down the whole JVM and interactions at 
the OS level and find performance bottlecks all the way down to 
generated Assembly code.



As for memory usage, Atego JVMs run in quite memory constrained 
devices.


Here is the tiniest of them, 
http://www.atego.com/products/atego-perc-ultra/


--
Paulo


There was also this one from 1998 that was very small

http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html

Java has some history running on small devices.

Cheers,
uri



Re: accept @pure @nothrow @return attributes

2015-01-26 Thread uri via Digitalmars-d
On Tuesday, 27 January 2015 at 04:10:24 UTC, Andrei Alexandrescu 
wrote:

On 1/26/15 7:25 PM, Zach the Mystic wrote:
On Tuesday, 27 January 2015 at 02:40:16 UTC, Walter Bright 
wrote:

On 1/26/2015 6:15 PM, Zach the Mystic wrote:
What's keeping you from committing to 'dfix' as the way to 
solve

issues like the
one in this thread?


Inertia of people being reluctant to use it. It's still work 
for

people to use, it's not part of their build process.


What about compiler integration? I'm talking about fundamental 
language
changes. Why would people use it if it didn't have official 
backing and

wasn't part of the compiler package? In this post:

http://forum.dlang.org/post/uimpnhiweuitnnbeq...@forum.dlang.org

... I said: 'For example, let's say dfix is included with the 
compiler

package.
Now you get an error, saying: Error: `@nogc` is no longer
accepted, but can be automatically replaced with `nogc`. Run 
dfix
on this file? (y/n)... or whatever is deemed the secure 
approach

to this feature.'

That's what I mean by commiting to dfix.


I'm ready to commit to dfix. Problem is many of the changes 
suggested are unlikely to mark much improvement, while miring 
us in the perpetual illusion of making progress. The fact that 
we can avail ourselves of a tactical tool that makes changes 
easy is helpful but also opens opportunity of abuse.


Let's stop shuffling the deck. I mean it. Stop shuffling the 
freaking deck. Fix the real issues in the language. Add new 
libraries. Be original. Be creative. Do real work.



Thanks,

Andrei


Well said.

I've been wavering for a few months between D and Python for 
teams on smaller internal projects. IMO this is the right 
attitude from core D devs to finish off D2.


Cheers,
uri


Re: accept @pure @nothrow @return attributes

2015-01-26 Thread uri via Digitalmars-d

On Tuesday, 27 January 2015 at 01:32:23 UTC, Mike wrote:

On Monday, 26 January 2015 at 19:51:08 UTC, Walter Bright wrote:

On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:

Personally, I'd much prefer that we not make this change.


It's good to have this discussion.

Previously, it's all been advocacy and break my code by 
forcing a change from pure = @pure.


Yes, please! (at least about the break my code part)



Just a few days ago on slashdot, an anonymous D user wrote:

 A horrible mix of keywords and annotation syntax for 
function/method
 attributes ('const', 'pure', and 'nothrow' are all keywords, 
but

 '@property', and '@nogc' are annotations)

for why he won't use D anymore.


Not a deal-breaker for me, but I agree with the sentiment, and 
I think it makes for a more professional language if such 
inconsistencies are addressed.




Frankly, I think that is a great bikeshedding non-issue that 
distracts us from what is important.


Yes, there is no correlation between what's important, and what 
people choose to work on, because there is no consensus on 
what's important, and if there is it's usually beyond the 
ability of most contributors, so it doesn't get worked on 
anyway.  Personally, I find small changes like this welcome 
because they make for a more polished experience.


I hope that by doing this PR, we can actually decide that it 
isn't worth it, i.e. I'd be happy to get consensus and revert 
it.


A dangerous precedent.  I suspect the push-back against this 
change has probably ruined any chance of further polishing the 
language.


From: https://issues.dlang.org/show_bug.cgi?id=13388#c27
***
I really think that we've passed the point where it's worth 
fixing it.


NO This attitude is the biggest problem D has.
Please, watch Scott Meyer's talk again. Most D code is yet to 
be written.

The future benefits of fixing this kind of crap, are huge.
***

In fact, it is the attitude against change that has put me on 
the fence about D, when I was quite an advocate about a year 
ago.  It has also made me reluctant to put forth the necessary 
effort to study and make any significant contributions because 
the controversy, as exhibited here, would likely erase my 
entire investment.  Instead, I have begun exploring other 
options while keeping one foot on the raft.


I agree that, in general, D should take a more disciplined 
approach to development, but keep in mind that if contributors 
have to go through too much controversy and bureaucracy we're 
not going to see much change (perhaps that's what some want).


I feel for Walter.  He's damned if he does and damned if he 
doesn't.  Somehow, this herd of cats need to figure out where 
it wants to go, and I need to figure out whether to go all in 
or jump ship.


Mike


+1 to all of this as it mirrors exactly how I feel about D at 
this point in time.


I get the impression it will never be finished because too many 
are afraid of important breaking changes that seem necessary to 
get through the last 5%-10% of D2.


Cheers,
uri


Re: D idioms list

2015-01-08 Thread uri via Digitalmars-d-announce

On Thursday, 8 January 2015 at 10:21:26 UTC, ponce wrote:
I've started a list of curated D tips and tricks here: 
http://p0nce.github.io/d-idioms/


Anything that you wished you learned earlier at one point in 
the D world is welcome to be added or suggested.


I think the focus should be on stuff that could make you more 
productive, or is just funky but that is up to debate.


Of course the D Cookbook still stays irreplaceable for a 
consistent, in-depth discussion of being D-enabled.


Thoughts?


This is great, thanks.

Something I personally would find useful is a comparison between 
the C++ way and idiomatic D with Phobos. I finding coming from 
C/C++ to D very easy but I'm always wondering if I'm doing things 
the D way.


Cheers,
uri


Re: D idioms list

2015-01-08 Thread uri via Digitalmars-d-announce

On Thursday, 8 January 2015 at 10:35:07 UTC, ponce wrote:

On Thursday, 8 January 2015 at 10:30:38 UTC, uri wrote:


This is great, thanks.

Something I personally would find useful is a comparison 
between the C++ way and idiomatic D with Phobos. I finding 
coming from C/C++ to D very easy but I'm always wondering if 
I'm doing things the D way.


Cheers,
uri


I'm not familiar with the terse, range-heavy, UFCS style that 
has emerged from Phobos so I'm not sure if I can write that.


What could help is a list of tasks for which you asked yourself 
what the D way was. Is there one?


No I admit I don't have any real list. It's always an in the 
moment sort of thing and I then just choose a D-ish/C++ style 
and promptly forget the exact details.


I'll start to compile a list each time this comes up. And if I 
find any good D idioms in the process I'll include them in the 
list as well.


Thanks,
uri


Re: An idea for commercial support for D

2015-01-07 Thread uri via Digitalmars-d
On Wednesday, 7 January 2015 at 02:16:47 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

On 06/01/15 23:32, uri via Digitalmars-d wrote:
The dmd backend is not under an OSS license, why haven't they 
left?  I suspect
there are not very many of the type of people you're talking 
about in the D

community.


It's possible that you're right but I don't see it happening. 
The backend
doesn't provide any benefit to GDC and LDC and Walter has a 
very good reason for

closing the backend sources which is understood by all.


Small point: the DMD backend may not be released under a free 
software license, but it is not closed -- the source is 
available, development happens in the open, and in a de facto 
(rather than de jure) sense there is little to distinguish from 
an open source project.  The licensing situation is obviously 
unfortunate, but it makes little practical difference 
considering that the vast majority of D language development is 
in the freely-licensed frontend, runtime or standard library, 
and there are two excellent free backends available.


This is a pretty good example of what I have referred to 
elsewhere in this thread, about the contextual nature of 
objections to non-free.


Thanks for the correction, and a very important one at that in 
the context of this thread. I wasn't aware the backend was open 
source.


Cheers,
uri


Re: An idea for commercial support for D

2015-01-06 Thread uri via Digitalmars-d

Hi,

Your business model is flawed for a number of reasons. Firstly, 
companies make money from their own products, not paying staff to 
figure out which bug fixes/features to cherry pick for the tool 
chain.


Secondly, no one makes money by locking out others when they 
themselves can be locked out in the same manner. This is 
basically what your model seems to boil down to.


Party 'A' provides patches X,Y,Z in the compiler and others have 
to pay for them. Party 'B' provides patches M,N,O and similarly, 
others pay for them.  Now party A does not benefit from M,N,O 
unless they pay for it and party B does not benefit from X,Y,Z 
unless they pay for it. So no one wins.


So the best solution is A and B both open their patches and both 
benefit from all contributions.


Thirdly, how can one separate the features? For example, say I'm 
willing to pay for features X,Y,Z but not M,N,O. How do the D 
devs split the features out so I only get M,N,O? Separate and 
special builds for each paying customer?


Fourthly, what about the OSS people using D?  Are the X,Y,Z and 
M,N,O features released GPL so they can benefit immediately or do 
they wait 6 months?


If it's 6 months why would anyone pay for the features? If it's 
longer than 6 months, or even if its GPL I think most will 
abandon D and go to Nim or Rust.



Cheers,
uri


Re: An idea for commercial support for D

2015-01-06 Thread uri via Digitalmars-d

On Tuesday, 6 January 2015 at 13:34:59 UTC, Joakim wrote:

Before you make such claims, you should probably think about 
them a little bit first.  Please tell me one company that does 
not buy outside commercial software which they then use to 
build their own products.  Some companies will want to cherry 
pick features, others will just buy an accumulated patchset 
against the point release from many devs.  The suggestion that 
all companies will have to spend a great deal of time picking 
what patches they want is just silly.


To me it doesn't make sense for a company to cherry pick compiler 
patches. The model you propose may work for applications where 
there is a clean distinction between user needs and wants but in 
a compiler you generally need all the features to work 
effectively and produce reasonable code. The optimizer may be a 
different story so perhaps that aspect of compilation could be 
split.


Besides splitting the compiler will result in a maintenance 
headache. Missing features in the compiler will not result in 
subset-D and complete-D but half-baked-nearly-working-D and 
working-D, if you're lucky.




This means A and B can't make any money off their patches, so 
they have to get some other job. That means they only have time 
to work on M and X on the occasional weekend and each of those 
patches takes six months to finish.  You are obviously okay 
with that glacial pace as long as you get their work for free, 
but others are willing to pay to get the pace of D development 
sped up.


This is only true if all patches are equally priced. Otherwise it 
breaks down and has been proven mathematically.



Glad you brought this up, there are several possibilities.  
Many users would probably just buy all the closed patches 
against a point release, so there is no question of splitting 
features.  But a handful of paying customers may be more 
adventurous, or cheap, ;) and choose to only buy a custom build 
with their needed features X,Y,Z.  This probably wouldn't 
happen right away, as it will take more time to setup a build 
process to support it, but supporting custom builds like that 
is definitely worthwhile.


OK, but the D devs still need to split the release between paid 
patches and non-paid patches. This is non-trivial in a compiler 
and adds additional work for the volunteers. Companies won't pay 
for the split because it isn't value adding for them so it will 
fall on the volunteers.


To begin with, D is not a GPL project, so why would they 
release them under the GPL?


So we wait some time period for the patch to be released.

As stated earlier, the patches would need to be funded up to 
some monetary and time limits before they would be released 
back to the OSS project.  So party A might contract with their 
paying customers that they'll release patches X,Y,Z once they 
accumulate $5k in payments from all the customers who buy those 
patches, plus a six month delay after that.  If they don't make 
$5k for a long time, the patches won't be released for a long 
time.


Then I think most OSS users would move on to another language. 
There is no point working with a compiler that is half-baked 
unless you pay for it. This is an issue because it's the OSS 
community that provides ongoing maintenance to the paid for 
patches. If OSS isn't there anymore then Digital Mars needs to 
start charging maintenance costs to upkeep the codebase. I don't 
think that will work, but it's only my opinion.


Why does anyone pay for software now?  It doesn't much matter 
to a paying customer that the feature will probably be free in 
a year or two if they need to use it to make money _now_.


But that's assuming an entity needs D to make money now. They 
don't because we have C++, Java, C# already. Why not just use one 
of those more mature languages?




As for people leaving because somebody else has developed a 
proprietary feature for D and not given it to them for free, 
companies like Sociomantic have already developed such features 
and they haven't been integrated upstream, why haven't most 
left already?


The features from Sociomantic features are all D1 and also there 
are devs from Sociomantic are trying to get features released 
upstream. Sociomantic isn't the blocker it's integrating the 
features into D2.



The dmd backend is not under an OSS license, why haven't they 
left?  I suspect there are not very many of the type of people 
you're talking about in the D community.


It's possible that you're right but I don't see it happening. The 
backend doesn't provide any benefit to GDC and LDC and Walter has 
a very good reason for closing the backend sources which is 
understood by all.


Maybe a handful of FOSS zealots would leave, but the resulting 
commercially supported D would be so much better, they'd be 
swamped by the new people coming on board. :)


We'll see :)

Cheers,
uri


Re: Worst Phobos documentation evar!

2014-12-28 Thread uri via Digitalmars-d
On Sunday, 28 December 2014 at 15:57:39 UTC, Ary Borenszweig 
wrote:


After programming in Ruby for a long time (and I think in 
Python it's the same) I came to the conclusion that all the 
sections (Return, Params, Example) just make writing the 
documentation a harder task. For example:


~~~
/*
 * Returns a lowered-case version of a string.
 *
 * Params:
 *   - x: the string to be lowered case
 * Return: the string in lower cases
 */
string lowercase(string x)
~~~

It's kind of redundant. True, there might be something more to 
say about the parameters or the return value, but if you are 
reading the documentation then you might as well read a whole 
paragraph explaining everything about it.


-1

Most of the time I know what the function does but I need the 
docs for the parameters and types.




For example, this is the documentation for the String#downcase 
method in Ruby:


~~~
def downcase(str)

Returns a copy of `str` with all uppercase letters replaced 
with their lowercase counterparts. The operation is locale 
insensitive—only characters “A” to “Z” are affected. Note: case 
replacement is effective only in ASCII region.


hEllO.downcase   #= hello
~~~

Note how the documentation directly mentions the parameters. 
There's also an example snippet there, that is denoted by 
indenting code (similar to Markdown).


Again, I don't want to wade through a wall of text just to get 
the parameter types or what a function returns. The signature 
itself is too noise IMO so explicit Return  Param sections are 
preferable IMO.



I'd also like to see TemplateParms: or TemplateTraits:, as others 
have already mentioned.




I think it would be much better to use Markdown for the 
documentation, as it is so popular and easy to read (although 
not that easy to parse).


DDoc is not hard to read or write so Markdown would be wasted 
effort. If DDoc generated Markdown that might be useful for the 
WIKI.




Then it would be awesome if the documentation could be smarter, 
providing semi-automatic links. For example writing 
#string.join would create a link to that function in that 
module (the $(XREF ...) is very noisy and verbose).


+1 I agree links to functions would be much simpler with a #tag.

Cheers,
uri






Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org

2014-12-22 Thread uri via Digitalmars-d-announce

On Monday, 22 December 2014 at 11:41:16 UTC, FrankLike wrote:
dco is a build tool,and very easy to use,it can build dfl64.lib 
,dgui.lib or other your projects,it can auto copy dfl.lib to 
the dmd2\windows\lib or lib64.
After you work on the dfl2,use the build.bat,you will feel it's 
very easy to use.


dco:
https://github.com/FrankLIKE/dco/
dfl2:
https://github.com/FrankLIKE/dfl2/

Frank


Thanks, I'm in the process of looking at CMake/SCons alternatives 
right at the moment and will have a look at dco.


I'm trying dub at the moment and it's working perfectly fine so 
far as a build tool. The alternatives, such as CMake and SCons, 
are proven technologies with D support that have also worked for 
me in the past.


Can I ask what the existing tools were missing and why did you 
felt it necessary to reinvented your own build tool?


Thanks,
uri







Re: dco can work for 64 bit,and base on D2.067b1:code.dlang.org

2014-12-22 Thread uri via Digitalmars-d-announce
On Monday, 22 December 2014 at 18:33:42 UTC, Russel Winder via 
Digitalmars-d-announce wrote:


On Mon, 2014-12-22 at 12:57 +, uri via 
Digitalmars-d-announce wrote:

[…]

Thanks, I'm in the process of looking at CMake/SCons 
alternatives right at the moment and will have a look at dco.


May I ask why SCons is insufficient for you?


It isn't. We review our build system every 12 months over Xmas 
quite period and tidy it all up. Part of the process is trying 
alternatives.


We use Python +SCons to drive our builds and CMake to generate 
native makefiles. We find this approach scales better in terms of 
speed and system load.


It is a pity CMake invented it's own noisy script though. I also 
find with CMake it can be extremely difficult to establish 
context when looking at the code. This is why we're slowly 
migrating to SCons.




I'm trying dub at the moment and it's working perfectly fine 
so far as a build tool. The alternatives, such as CMake and 
SCons, are proven technologies with D support that have also 
worked for me in the past.


Can I ask what the existing tools were missing and why did you 
felt it necessary to reinvented your own build tool?


The makers of Dub chose to invent a new build tool despite 
Make, CMake
and SCons. Although it is clear Dub is the current de facto 
standard
build tool for pure D codes, there is nothing wrong with 
alternate
experiments. I hope we can have an open technical discussion of 
these

points, it can only help all the build systems with D support.


I really like DUB for quick development, but in it's current form 
I don't see it scaling to larger builds. IMO the use of JSON puts 
it on par with the Java build tool Ant. JSON and XML (Ant) are 
data formats, not scripting languages and In my experience a 
large build system requires logic and flow control. I've had to 
do this before in Ant XML and it isn't pretty, nor is it flexible.


I use SCons for personal D projects that I think will be long 
lived and DUB for quick experiments. I was using CMake for 
personal work but that script is too ugly :)


Cheers,
uri








Re: Rectangular multidimensional arrays for D

2014-12-22 Thread uri via Digitalmars-d

On Tuesday, 23 December 2014 at 03:11:20 UTC, Laeeth Isharc wrote:

On Monday, 22 December 2014 at 22:46:57 UTC, aldanor wrote:
On Monday, 22 December 2014 at 22:36:16 UTC, H. S. Teoh via 
Digitalmars-d wrote:
FYI, Kenji's merge has since been merged. So now the stage is 
set for

somebody to step up and write a nice multidimensional array
implementation.


One important thing to wish for, in my opinion, is that the 
design of such implementation would allow for (future 
potential) integration with linear algebra libraries like 
blas/lapack without having to be rewritten from scratch (e.g. 
so it doesn't end up like Python's array module which got 
completely superceded by numpy).


You mean especially for sparse matrices ?  What is it that 
needs to be borne in mind for regular matrices ?


The layout in lapck/blas is column major so it can be handy using 
a wrapper around arrays to provide the FORTRAN indexing.


Also you need to pass the .ptr property of the array or a[0]. D 
arrays are fat and include their length.


Cheers,
uri


Re: DUB build questions

2014-12-22 Thread uri via Digitalmars-d-learn
On Saturday, 20 December 2014 at 08:36:15 UTC, Russel Winder via 
Digitalmars-d-learn wrote:


On Sat, 2014-12-20 at 05:46 +, Dicebot via 
Digitalmars-d-learn wrote:
On Saturday, 20 December 2014 at 04:15:00 UTC, Rikki 
Cattermole wrote:
  b) Can I do parallel builds with dub. CMake gives me 
  Makefiles so I can

  make -j does dub have a similar option?
 
 No


Worth noting that it is not actually a dub problem as much, it 
is simply not worth adding parallel builds because separate
compilation is much much slower with existing D front-end 
implementation and even doing it in parallel is sub-optimal

compared to dump-it-all-at-once.



From previous rounds of this sort of question (for the SCons D
tooling), the consensus of the community appeared to be that 
the only
time separate module compilation was really useful was for 
mixed D, C,
C++, Fortran systems. For pure D systems, single call of the 
compiler
is deemed far better than traditional C, C++, Fortran 
compilation
strategy. This means the whole make -j thing is not an issue, 
it
just means that Dub is only really dealing with the all D 
situation.


The corollary to this is that DMD, LDC and GDC really need to 
make use
of all parallelism they can, which I suspect is more or less 
none.


Chapel has also gone the compile all modules with a single 
compiler
call strategy as this enables global optimization from source 
to

executable.



Thanks for the info everyone.


I've used dub for just on two days now and I'm hooked!

At first I was very unsure about giving up my Makefiles, being 
the build system control freak that I am, but it really shines at 
rapid development.


As for out of source builds, it is a non-issue really. I like 
running the build outside the project tree but I can use 
gitignore and targetPath. For larger projects where we need to 
manage dependencies, generate code, run SWIG etc. I'd still use 
both SCons or CMake.



Regarding parallel builds, make -j on CMake Makefiles and dub 
build feel about the same, and that's all I care about.


I'm still not sure how dub would scale for large projects with 
100s-1000s of source modules. DMD ran out of memory in the VM 
(1Gb) at around 70 modules but CMake works due to separate 
compilation of each module ... I think. However, I didn't 
investigate due to lack of time so I wouldn't score this against 
dub. I am sure it can do it if I take the time to figure it out 
properly.


Cheers,
uri


Re: Lost a new commercial user this week :(

2014-12-19 Thread uri via Digitalmars-d

On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

me too. it's really disgusting how you guys treat (verbally
mistreat) others, who take a chance with D.
Good luck to you all on your pet project.


And how? Explaining mistakes and reasons why just taking a 
chance brings nothing (and can as well do a harm)?


Chris point was overblown, sure, but so was original post.

Manu has explained his case in great details and that was very 
good. However it was missing single most important part - 
explanation of what he wants to achieve, what actions he 
expects from community. So far it sounded like hey guys I know 
you are nerds so go implement everything I need for my projects 
instead of working on yours. I'd be glad to be mistaken but it 
still looks like that so far.


+1

What D needs right now is for people to stop complaining about 
the things that are wrong and start contributing.


Cheers,
uri


Re: Lost a new commercial user this week :(

2014-12-19 Thread uri via Digitalmars-d

On Friday, 19 December 2014 at 09:52:09 UTC, uri wrote:

On Friday, 19 December 2014 at 07:37:45 UTC, Dicebot wrote:

On Friday, 19 December 2014 at 07:25:20 UTC, ole wrote:

me too. it's really disgusting how you guys treat (verbally
mistreat) others, who take a chance with D.
Good luck to you all on your pet project.


And how? Explaining mistakes and reasons why just taking a 
chance brings nothing (and can as well do a harm)?


Chris point was overblown, sure, but so was original post.

Manu has explained his case in great details and that was very 
good. However it was missing single most important part - 
explanation of what he wants to achieve, what actions he 
expects from community. So far it sounded like hey guys I 
know you are nerds so go implement everything I need for my 
projects instead of working on yours. I'd be glad to be 
mistaken but it still looks like that so far.


+1

What D needs right now is for people to stop complaining about 
the things that are wrong and start contributing.


Cheers,
uri


And if you don't have time to contribute then submit an ER or bug 
report. Even that will be more constructive than having a pubilc 
tantrum when others disagree.


A bit embarrassing I'd say.


Cheers,
uri


Re: Lost a new commercial user this week :(

2014-12-19 Thread uri via Digitalmars-d
On Friday, 19 December 2014 at 11:54:42 UTC, ketmar via 
Digitalmars-d wrote:

On Fri, 19 Dec 2014 10:47:27 +
Sergei Nosov via Digitalmars-d digitalmars-d@puremagic.com 
wrote:


In the debugger case, Manu's point is that it's unusable. 
And Walter's implied point is debuggers aren't that useful 
anyway, so why it was a showstopper?.


My personal observation is that excellent programmers share 
the Walter's point on debuggers - they practically don't use 
it. And the uselessness is so obvious, that there's nothing 
even to talk about. At the same time, good programmers use 
it extensively, especially on Windows. It is so useful to 
them, that there's nothing even to talk about!


one of the things one can do if he is in corresponding position 
is to
ban debuggers. i found that after month or two people start 
producing

better code with better documentation and control knobs. and
surprisingly faster. debugger is just a kind of bad habit, and 
when
people faced the fact that they will not be payed for work 
simulation

(and why should we?), they either go or becomes more productive.


This is true. The first week for a new developer where I work is 
developing a better boot loader. The debugger is not allowed 
during this induction week and as a result our devs learn how to 
write better code first time through careful planning and 
understanding of what's going on at the machine level.



Cheers,
uri


Re: Lost a new commercial user this week :(

2014-12-19 Thread uri via Digitalmars-d
On Friday, 19 December 2014 at 12:53:32 UTC, Tobias Pankrath 
wrote:

On Friday, 19 December 2014 at 12:44:26 UTC, Kiith-Sa wrote:
On Friday, 19 December 2014 at 09:13:07 UTC, Walter Bright 
wrote:

On 12/18/2014 2:24 AM, Manu via Digitalmars-d wrote:
Docs need to have examples which are plain and obvious, and 
the

language will be absorbed by osmosis.


I agree. Can you point to specific cases that need an example?


If it doesn't have an example, it needs an example, no matter 
how trivial it is. That's a good place to start. Of course, 
then there are lazy examples that don't really help in real 
use. These need to be identified and rewritten.


• If you look up how to do $x in the documentation and it is 
takes you time to figure that out, consider to add an example 
for $x to the documentation.


• If you answer/ask a question in D.learn on how to do $x, 
consider to add an example for $x to the documentation.


This way we should build up exactly those examples that are 
useful.


+1

No different to adding unit tests where possible for each 
reported bug.


DUB build questions

2014-12-19 Thread uri via Digitalmars-d-learn

Hi All,

I'm very happy with CMakeD but thought I'd try dub because CMake 
script is a PITA. So I have a couple of questions.


a) Can dub do out out of source builds and how would I set that 
up.


b) Can I do parallel builds with dub. CMake gives me Makefiles so 
I can make -j does dub have a similar option?



I looked around on the DUB registry website but couldn't find any 
info.


Thanks,
uri



Re: DUB build questions

2014-12-19 Thread uri via Digitalmars-d-learn
On Saturday, 20 December 2014 at 04:15:00 UTC, Rikki Cattermole 
wrote:

On 20/12/2014 11:14 a.m., uri wrote:

Hi All,

I'm very happy with CMakeD but thought I'd try dub because 
CMake script

is a PITA. So I have a couple of questions.

a) Can dub do out out of source builds and how would I set 
that up.

There is e.g. preBuildCommands.

b) Can I do parallel builds with dub. CMake gives me Makefiles 
so I can

make -j does dub have a similar option?


No

I looked around on the DUB registry website but couldn't find 
any info.


Thanks,
uri


OK thanks.


Re: VLA in Assembler

2014-12-17 Thread uri via Digitalmars-d-learn

On Wednesday, 17 December 2014 at 11:39:43 UTC, Foo wrote:
On Wednesday, 17 December 2014 at 10:59:09 UTC, bearophile 
wrote:

Foo:


Hi,
Could someone explain me, if and how it is possible to 
allocate a variable length array with inline assembly?

Somewhat like

int[] arr;
int n = 42;
asm {
  // allocate n stack space for arr
}

I know it is dangerous and all that, but I just want it know. 
;)


Doing it with alloca is simpler:


void main() @nogc {
   import core.stdc.stdlib: alloca, exit;

   alias T = int;
   enum n = 42;

   auto ptr = cast(T*)alloca(T.sizeof * n);
   if (ptr == null)
   exit(1); // Or throw a memory error.
   auto arr = ptr[0 .. n];
}


Bye,
bearophile
Yes I know, but I really want it in inline assembly. It's for 
learning purpose. :)


You could look at the disassembly.


Re: Sargon component library now on Dub

2014-12-16 Thread uri via Digitalmars-d-announce

On Tuesday, 16 December 2014 at 23:16:32 UTC, poucave wrote:

On Sunday, 14 December 2014 at 13:31:57 UTC, disapoint wrote:
On Sunday, 14 December 2014 at 03:26:56 UTC, Walter Bright 
wrote:

http://code.dlang.org/packages/sargon

These two modules failed to generate much interest in 
incorporating them into Phobos, but I'm still rather proud of 
them :-)


Here they are:

◦sargon.lz77 - algorithms to compress and expand with LZ77 
compression algorithm


◦sargon.halffloat - IEEE 754 half-precision binary floating 
point format binary16


I'll be adding more in the future.


how about you take the time to add a complete set of window 
headers before more people loose customers or their reputation?


http://www.linternaute.com/proverbe/710/un-mauvais-ouvrier-a-toujours-de-mauvais-outils/


touché :-)


Re: i want my bounty!

2014-12-15 Thread uri via Digitalmars-d
On Monday, 15 December 2014 at 08:54:24 UTC, ketmar via 
Digitalmars-d wrote:

On Mon, 15 Dec 2014 13:19:01 +1100
Daniel Murphy via Digitalmars-d digitalmars-d@puremagic.com 
wrote:


ketmar via Digitalmars-d  wrote in message 
news:mailman.3160.1418550079.9932.digitalmar...@puremagic.com...


 but talking seriously, i don't need any bounty, i just want 
 somebody to
 take a look at that and either tell me what to fix or 
 integrate it in
 mainline. along with this one: 
 https://issues.dlang.org/show_bug.cgi?id=13526


Review of patches for dmd are done on github: 
http://wiki.dlang.org/Pull_Requests#Create_a_pull_request

so DON'T ALLOW THE FUCKIN' BUGZILLA TO HOST PATCHES!

and stop pretending that D is normal open-source project where 
anyone
can send patches. that's blatant lies. i can see why i have to 
register
on D bugtracker, which has the address issues.dlang.org. but 
i can't
see why i must register on some 3rd-party site which has 
NOTHING in

common with D.


You were looking forward to that, in fact I'd say trolling for 
it...


Your contribution is welcome and if you don't want to use Github, 
the chosen tool of D development, that's fine. But you cannot 
expect to dictate when others will turn your patches into PRs for 
you to get them into the D ecosystem.


You'll just have to wait, unless you submit the PR yourself of 
course.


Cheers,
uri

PS: You don't even have to join Github with your real name and 
email...


Re: i want my bounty!

2014-12-15 Thread uri via Digitalmars-d
On Monday, 15 December 2014 at 09:31:28 UTC, ketmar via 
Digitalmars-d wrote:

On Mon, 15 Dec 2014 09:07:53 +
uri via Digitalmars-d digitalmars-d@puremagic.com wrote:

You were looking forward to that, in fact I'd say trolling for 
it...
that's not the first time i asking why bugzilla is still able 
to host
patches. i just wanted to make myself sure that any input is 
valuable

is blatant lies. one last time.


OK, fair point.



Your contribution is welcome and if you don't want to use 
Github, the chosen tool of D development, that's fine. But you 
cannot expect to dictate when others will turn your patches 
into PRs for you to get them into the D ecosystem.
i.e. shut the fuck off and get lost with your stupid patches, 
nobody
is interested. this is not welcome, this is github or get 
lost.


You'll just have to wait, unless you submit the PR yourself of 
course.
i waited for several month for *any* reaction. as my past 
expirience
shows, the only reliable way to make somebody look at bugzilla 
patches

is to start trollfest here. but i'm tired of that.

PS: You don't even have to join Github with your real name and 
email...
i don't even understand why i have to join github in the first 
place. i
don't want to be a part of github, i'm not interested in that. 
that's

why i registered on official D bugzilla.


Ideally there'd be a tool to turn Bugzilla patch submission into 
a Github PR. But again it's work *someone* has to do and it isn't 
*that* much of a hurdle to get onto Github with a made up account 
just for D.


Cheers,
uri.


Re: Lost a new commercial user this week :(

2014-12-15 Thread uri via Digitalmars-d
On Tuesday, 16 December 2014 at 05:48:27 UTC, Rikki Cattermole 
wrote:

On 16/12/2014 5:11 p.m., MattCoder wrote:
On Tuesday, 16 December 2014 at 03:50:59 UTC, Rikki Cattermole 
wrote:
I started writing a small booklet on this, if you got an 
email if

you're interested or some way to send you. Please let me know.


Do you mind to share with us all? :)

Matheus.


https://drive.google.com/file/d/0B-EiBquZktsLc0czUzZVeGlLM00/view?usp=sharing
No guarantees of how long it'll stay up there.

And to reiterate, its only just a start. And I don't know if I 
ever complete it. There isn't really enough material for an 
actual book. Maybe booklet but meh.


This is a great start, keep going with it!!

A book that looked at the details of CTFE with examples and 
comparison of patterns implemented in CTFE vs. RT would be a 
really nice addition to the D books already available.




Re: Lost a new commercial user this week :(

2014-12-14 Thread uri via Digitalmars-d

On Sunday, 14 December 2014 at 15:36:47 UTC, yawniek wrote:

On Sunday, 14 December 2014 at 14:09:57 UTC, Joakim wrote:


As always, different tools for different uses.  Hopefully, D 
can one day be polished and mainstream enough for the 
enterprise use case and it will be efficient enough to be 
deployed at scale too. :)


when will that be? windows version 25, sqlite version 1147?

...[snip]...

Perhaps when more people start helping out we'll see things 
progress more quickly.


D needs more than developers. Right now it needs a few volunteers 
who will update the web site; documentation, news feeds of recent 
PRs closed, recent PRs that are generating interesting 
discussion, roadmaps for the next 12 months indicating what core 
devs are working and status. Stuff that get's people excited 
about the next release and the future of D.


Cheers,
uri


Re: Why do you write D2 compiler using C++ language?

2014-12-14 Thread uri via Digitalmars-d

On Sunday, 14 December 2014 at 16:44:09 UTC, ddj wrote:
On Saturday, 13 December 2014 at 23:02:52 UTC, Mike Parker 
wrote:

On 12/13/2014 10:55 PM, ddj wrote:


But so many issues and bug fixes scares me from using it.



That's just the wrong way to look at it. Take a look at the 
bug list for gcc, any of the Java compilers, or clang. Are you 
afraid to use them as well?


Maybe, but gcc and java compilers have long history of stable 
releases and many programs and libraries written. Clang has 
standards to implement and! static analyzer.


As Mike said, look at the bug tracker history for these projects. 
Even with all those stable releases there were always lots of 
open bugs and today in GCC 4.9 there are issues:


http://lkml.iu.edu//hypermail/linux/kernel/1407.3/00650.html

We use GCC 4.8 at my work where we develop class II and class III 
health-care devices - A life support system is class III...how 
well do you trust GCC? :-).


Joking aside we design for failure and have a 4 year verification 
process that weeds out critical bugs in our code and the compiler.


Cheers,
uri





Re: D game development: a call to action

2014-12-13 Thread uri via Digitalmars-d

On Saturday, 13 December 2014 at 22:49:10 UTC, Joel wrote:

On Tuesday, 6 August 2013 at 06:23:09 UTC, qznc wrote:
On Monday, 5 August 2013 at 18:18:30 UTC, Jonathan A Dunlap 
wrote:
I am one of the few who have taken a keen interest in D for 
game development. The concise language and modern 
conveniences may be able to reduce many hours worth of 
development time off a game project, while making the code 
more maintainable. Aside from the core language, Dlang 
graphics bindings have a way to go before even earning 
acceptance in the indie gaming scene, but it's making great 
strides to get there.


The main challenge I've hit is the lack of any sort of path 
for adopting a media engine. Bindings (like SFML 
https://github.com/krzat/SFML-D) all suffer from:


A) No information about its current status: this is scary if 
its repo hasn't been updated in months.
B) Usually are complex to get working in a new project 
(manually building or searching for undocumented dependency 
DLLs)
C) Lack practical references and tutorials for real would 
usage
e.g. how to create an OpenGL window or how to render a 
triangle
versus something like how to load from disk an image texture 
onto a quad and move it around using keyboard events


SFML bindings are also in 
https://github.com/aldacron/Derelict3 but I couldn't find a 
scrap of information on how to use it, how to compile 
correctly, or example usage. It's unclear if the library is 
even usable in its current state.


Please don't take this as blind criticism, but rather a plea 
to action for the community to provide better library 
documentation support for: current lib status, getting 
started adding it, and a general use tutorial/example. If we 
start doing this, it'll make a big impact for other game 
developers who are new to Dlang to adopt the language. Thanks 
for listening!


I am using DAllegro 5 for 2D stuff. So far, it went very 
smooth.

I just use the original documentation.

https://github.com/SiegeLord/DAllegro5


Who else uses DAllegro 5? I like it, just can't get it to work 
on OS X.


I'm also using the Allegro bindings for a project and have run 
into no issues on  Linux. I'm using Dgame on another project on 
and that also works very well.



@SiegeLord: It would be good to get those bindings listed on the 
main Allegro site here:


http://alleg.sourceforge.net/bindings.html
(there is an old listing for Allegro 4 but not 5)

and in their news here if possible:
http://alleg.sourceforge.net/news.html

I believe you just need to send a request to the mailing list 
here:

http://sourceforge.net/p/alleg/mailman/?source=navbar

Cheers
uri


Re: D3

2014-12-09 Thread uri via Digitalmars-d

On Tuesday, 9 December 2014 at 10:49:13 UTC, Chris wrote:
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via 
Digitalmars-d wrote:
On 12/8/14, Russel Winder via Digitalmars-d 
digitalmars-d@puremagic.com wrote:

It seems that D3 is already available:

https://github.com/mbostock/d3


Guess we'll just have to skip a number and call the next D - 
D4. :)


Well, the name of D is D not D(n), so there should be no 
problem in case they want to sue Walter.


But really, it had to be JavaScript of all languages! At least 
it's not PHP.


I prefer PHP, at least it's an explicit hack on sight.


Re: @property usage

2014-12-09 Thread uri via Digitalmars-d-learn
On Tuesday, 9 December 2014 at 07:31:21 UTC, Nicholas Londey 
wrote:
as this can break some invalid code (the code where people 
using

properties as functions)


Does @property ever make sense for a free floating function? I 
would have thought no but was recently asked to add it if using 
the function with uniform call syntax.


https://github.com/D-Programming-Language/dub/pull/455#discussion_r21430311


After a quick grep I see phobos uses quite a few free floating 
@property...




Re: Need help deciphering posix.mak

2014-12-05 Thread uri via Digitalmars-d

On Friday, 5 December 2014 at 10:48:15 UTC, Daniel Murphy wrote:
Dicebot  wrote in message 
news:kgogertqxpmczhoqr...@forum.dlang.org...


That or just clean up the existing makefiles (getting rid of 
DMC make and using GNU make on all platforms would be ideal). 
Or just doing nothing - while existing build system is quite a 
mess, the problem is not critical enough to extend the 
infrastructure.


As much as I dislike digital mars make, requiring GNU make on 
windows would be worse.  One of these days I'm going to rewrite 
the dmd test suite to not require make at all, but I'm going to 
have to figure out how it works first.


I think I'd much rather GNU make.

No offence, but there's no chance your little tool will ever get 
the same test coverage or real-world use testing of GNU make on 
Windows.


This is why I prefer CMake like tools over dub. Plus make -jX is 
*much* faster than dub build (and SCons for that matter).



/uri



@property usage

2014-12-04 Thread uri via Digitalmars-d-learn

Hi All,

Do you guys use @property much, or is it largely ignored/avoided?

Thanks,
uri


Re: @property usage

2014-12-04 Thread uri via Digitalmars-d-learn
On Thursday, 4 December 2014 at 10:24:00 UTC, Rikki Cattermole 
wrote:

On 4/12/2014 11:21 p.m., uri wrote:

Hi All,

Do you guys use @property much, or is it largely 
ignored/avoided?


Thanks,
uri


When it makes sense I use it.

https://github.com/Devisualization/window/blob/master/interfaces/devisualization/window/interfaces/window.d#L144

vs

https://github.com/rikkimax/Dobol/blob/master/source/dobol/parser/dobol/parser/defs.d


Thanks for the examples. As always I found what I needed just 
after posting:


http://wiki.dlang.org/Property_Discussion_Wrap-up


/uri


Re: Dgame 0.3.2

2014-11-22 Thread uri via Digitalmars-d-announce

On Saturday, 22 November 2014 at 15:38:35 UTC, Namespace wrote:

On Saturday, 22 November 2014 at 06:49:04 UTC, uri wrote:

On Saturday, 22 February 2014 at 10:00:46 UTC, Namespace wrote:
On a side note, the author in the code is Stewart but it is 
still me :). It is my middle name, which the auto-header 
vim script grabs from the login.
Yes that I have also seen. Otherwise, I would have used your 
github name. :)

Cheers,
ed (stewart)


I just saw it up on the website, very cool, thanks :)
I have to thank. Another game looks great on the page and 
it's nice to see that Dgame is used.



The Dgame website has been down for a while now ... is it 
coming back?


/uri


Since I left D a while ago, I quit the domain. But the website 
itself is still on my webspace: http://rswhite.de/dgame4/


Cool, thanks :)

Sorry to hear you've left D behind! Hopefully it's only 
temporarily because I'm finding Dgame is great fun to use.



Cheers,
uri


Re: Dgame 0.3.2

2014-11-21 Thread uri via Digitalmars-d-announce

On Saturday, 22 February 2014 at 10:00:46 UTC, Namespace wrote:
On a side note, the author in the code is Stewart but it is 
still me :). It is my middle name, which the auto-header vim 
script grabs from the login.
Yes that I have also seen. Otherwise, I would have used your 
github name. :)

Cheers,
ed (stewart)


I just saw it up on the website, very cool, thanks :)
I have to thank. Another game looks great on the page and it's 
nice to see that Dgame is used.



The Dgame website has been down for a while now ... is it coming 
back?


/uri


Re: Why is `scope` planned for deprecation?

2014-11-20 Thread uri via Digitalmars-d
On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof 
Datsørg wrote:
On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright 
wrote:
On 11/18/2014 1:23 PM, Ola Fosheim Grøstad 
ola.fosheim.grostad+dl...@gmail.com wrote:
I am arguing against the position that it was a design 
mistake to keep the
semantic model simple and with few presumptions. On the 
contrary, it was the
design goal. Another goal for a language like C is ease of 
implementation so

that you can easily port it to new hardware.


The proposals I made do not change that in any way, and if KR 
designed C without those mistakes, it would have not made C 
more complex in the slightest.



VLAs have been available in gcc for a long time. They are not 
useless, I've used

them from time to time.


I know you're simply being argumentative when you defend VLAs, 
a complex and useless feature, and denigrate simple ptr/length 
pairs as complicated.


Argumentative ?!! More like a fucking gaping fucking asshole. 
His

posts are the blight of this group.


Wow that's uncalled for.

I don't always agree with Ola but his posts are rarely uninformed 
and often backed up with actual code examples or links supoprting 
his arguments. They generally lead to very interesting 
discussions on the forum.


Cheers,
uri


Re: write multiple lines without \n with writeln

2014-11-20 Thread uri via Digitalmars-d-learn

On Thursday, 20 November 2014 at 08:28:11 UTC, Suliman wrote:

In dco source code I have found:

void ShowUsage()
{
writeln(
dco build tool  ~ strVersion ~ 
written by FrankLIKE.
Usage:
dco [switches...] files...
for example: dco
or: dco app.d
build for dfl2: dco

}

I do not see here any \n. Why this code is output all one by 
line, and not in single line?


Why my code:
writeln(App name: ~ appName ~
App version: ~ appVersion ~
To see help please use -h\\-help option);
writeln(args);

output:
App name:CoolAppApp version:0.0.1To see help please use 
-h\-help option[.\\app1

.exe]


In all string literal forms, an EndOfLine is regarded as a 
single \n character.


http://dlang.org/lex.html



It's by design but is *really* annoying and should be limited to 
WysiwygString literals IMO.


Auto-formatting with clang-format or astyle can mess up writeln 
formatting completely.


Cheers,
uri


Re: write multiple lines without \n with writeln

2014-11-20 Thread uri via Digitalmars-d-learn

On Thursday, 20 November 2014 at 10:41:24 UTC, bearophile wrote:

uri:


It's by design


And it's a nice handy design.

Bye,
bearophile


For Wysiwyg strings I agree that it's great but I prefer 
C/C++/Python like behaviour for double quoted strings. I guess 
it's what I'm used to :)





Cheers,
uri




Re: print yyyy-mm-dd

2014-11-20 Thread uri via Digitalmars-d-learn

On Thursday, 20 November 2014 at 20:38:08 UTC, MrSmith wrote:

On Thursday, 20 November 2014 at 13:50:49 UTC, Suliman wrote:
I can't understand how to get date in format -MM-dd from 
Clock.currTime

auto time = Clock.currTime;

And what next? Could anybody give any examples?


http://dpaste.dzfl.pl/73c0438f9d1e

currTime returns SysTime;
You can then cast is to Date.
And Date has toISOExtString which converts Date to a string 
with the format -MM-DD.


There's no need to cast, SysTime supports conversion to string

http://dlang.org/library/std/datetime/SysTime.toISOExtString.html
http://dlang.org/library/std/datetime/SysTime.toISOString.html

If you want just the -MM-DD slice it

Clock.currTime.toISOExtString[0..10].writeln;
Clock.currTime.toISOString[0..8].writeln;

Cheers,
uri



Re: 'int' is enough for 'length' to migrate code from x86 to x64

2014-11-19 Thread uri via Digitalmars-d
On Wednesday, 19 November 2014 at 18:09:11 UTC, Ary Borenszweig 
wrote:

On 11/19/14, 7:03 AM, Don wrote:
On Tuesday, 18 November 2014 at 18:23:52 UTC, Marco Leise 
wrote:


Weird consequence: using subtraction with an unsigned type is 
nearly

always a bug.

I wish D hadn't called unsigned integers 'uint'. They should 
have been
called '__uint' or something. They should look ugly. You need 
a very,

very good reason to use an unsigned type.

We have a builtin type that is deadly but seductive.



I agree. An array's length makes sense as an unsigned (an 
array can't have a negative length, right?) but it leads to 
the bugs you say. For example:


~~~
import std.stdio;

void main() {
  auto a = [1, 2, 3];
  auto b = [1, 2, 3, 4];
  if (a.length - b.length  0) {
writeln(Can you spot the bug that easily?);
  }
}
~~~

Yes, it makes sense, but at the same time it leads to super 
unintuitive math operations being involved.


Rust made the same mistake and now a couple of times I've seen 
bugs like these being reported. Never seen them in Java or .Net 
though. I wonder why...


IMO array length should be unsigned but I'd like to see unsafe 
operators on unsigned types illegal. It is trivial to write 
(a.signed - b.signed) and it should be explicit in the code, i.e. 
not something that the compiler will do automatically behind the 
scenes.


Cheers,
uri






Re: Compiling with SQLite

2014-11-17 Thread uri via Digitalmars-d-learn

On Tuesday, 18 November 2014 at 01:14:26 UTC, impatient-dev wrote:
I'm new to D, and I'm trying to use SQLite, but I can't get 
this basic program to compile:


import etc.c.sqlite3 : sqlite3_open;

void main(string[] args){
sqlite3_open(test.sqlite, null);
}

When compiling with DMD v2.066.1, I get this error:

test.o: In function `_Dmain':
test.d:(.text._Dmain+0x2f): undefined reference to 
`sqlite3_open'

collect2: ld returned 1 exit status
--- errorlevel 1

Any idea what I'm doing wrong? I'm on Ubuntu 12.04 64-bit, but 
I doubt that matters. I've tried a couple alternatives, but 
they didn't work either.



Are you linking with libsqlite3.a?

For example:

$ dmd prog.d -L-lsqlite3




Which SciD to use (if at all)?

2014-11-03 Thread uri via Digitalmars-d-learn

Hi All,

I've just started using kyllingstad/scid but it hasn't been 
updated for a while and I just found a fork which references some 
GSoC work.


Is SciD is still maintained and which should I use?

https://github.com/kyllingstad/scid

or

https://github.com/cristicbz/scid


Or is there an alternative that is more active?


Cheers,
uri


template type deduction of static 2d arrays

2014-10-24 Thread uri via Digitalmars-d-learn

Hi All,

I was wondering why in the code below f1() works but f2 template 
version called in the same manner does not. Is there a good 
reason from a language/compiler perspective?


Thanks.
uri


---
auto f1(int[2][2] m)
{
return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}
auto f2(T)(T[2][2] m)
{
return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}

void main()
{
auto res = f1( [[1,2],[3,4]]); // works
assert(res == -2);

res = f2([[1,2],[3,4]]); // deos not work
}

Calling f2() as done above gives the following error:

Error: cannot deduce function from argument types !()(int[][]), 
candidates are:

f2(T)(T[2][2] m)


Re: template type deduction of static 2d arrays

2014-10-24 Thread uri via Digitalmars-d-learn
On Friday, 24 October 2014 at 23:20:02 UTC, ketmar via 
Digitalmars-d-learn wrote:

On Fri, 24 Oct 2014 22:32:57 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com 
wrote:



Hi All,

I was wondering why in the code below f1() works but f2 
template version called in the same manner does not. Is there 
a good reason from a language/compiler perspective?


Thanks.
uri


---
auto f1(int[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}
auto f2(T)(T[2][2] m)
{
 return m[0][0]*m[1][1]-m[0][1]*m[1][0];
}

void main()
{
 auto res = f1( [[1,2],[3,4]]); // works
 assert(res == -2);

 res = f2([[1,2],[3,4]]); // deos not work
}

Calling f2() as done above gives the following error:

Error: cannot deduce function from argument types 
!()(int[][]), candidates are:

f2(T)(T[2][2] m)

by the way, this will work too:

  int[2][2] v = [[1,2],[3,4]];
  res = f2(v);

'cause 'v' has correct type, and initializing 'v' does 'magic 
casting'.


Thanks for replying.

I think it should work because there's no ambiguity. I now have 
to uglify my code and make it !@safe or create a temporary.


I also noticed this when trying things out:

auto f2(T)(int[2][2] m) // Same error as above
auto f2()(int[2][2] m) // Works as per non-template function


On a related note, does the D spec guarantee the following will 
be rectangular in memory?


auto a = [ [1,2],[3,4] ];


Cheers,
uri




Re: template type deduction of static 2d arrays

2014-10-24 Thread uri via Digitalmars-d-learn

On Friday, 24 October 2014 at 23:46:28 UTC, uri wrote:



On a related note, does the D spec guarantee the following will 
be rectangular in memory?


auto a = [ [1,2],[3,4] ];


Cheers,
uri


I just checked the docs and auto a = [ [1,2],[3,4] ] will be an 
an array of pointers. So this cannot work (unless the compiler 
truly is magical :)


auto a = [ [1,2],[3,4] ];
cast(int[2][2])(a);

but this should work:

enum a = [ [1,2],[3,4] ];
cast(int[2][2])(a);


(all untested)

Thanks,
uri


Re: template type deduction of static 2d arrays

2014-10-24 Thread uri via Digitalmars-d-learn
On Saturday, 25 October 2014 at 00:00:54 UTC, ketmar via 
Digitalmars-d-learn 



we have a nice PR from Kenji that allows the following 
declarations:


  int[$][$] a = [ [1,2],[3,4] ];

but alas, it's not in the mainline yet.




This will be cool, especially auto[$][$] also works.

thanks,
uri


Re: How to convert from ubyte[] to and from float?

2014-10-20 Thread uri via Digitalmars-d-learn
On Sunday, 19 October 2014 at 03:14:26 UTC, Charles Hixson via 
Digitalmars-d-learn wrote:
What is the best way to convert from a part of a ubyte[] to a 
float?


I've tried converting the ubyte[] into a uint, but neither 
casting the uint to a float nor to!float work.


I suppose I could use a trick record union, but that seems 
inelegant.  If I use pointers, the alignment may 
(unpredictably) not be proper (whatever that means these days).


Is this what you're after?
http://dlang.org/phobos/std_bitmanip.html#.peek
http://dlang.org/phobos/std_bitmanip.html#.read
http://dlang.org/phobos/std_bitmanip.html#.write

These accept indices, or you can just slice the ubyte[] to the 
part you need.


---

import std.stdio;
import std.bitmanip;
import std.system;
void main()
{
// UBYTE[] to FLOAT
//
// 6.5535000E+004   00-FF-7F-47
ubyte[] ubval = [0, 0xff, 0x7f, 0x47];
auto fval = ubval.peek!(float, Endian.littleEndian);
writefln(%s as float: %s, ubval, fval);
writefln(%s as float: %s, ubval, ubval.read!(float, 
Endian.littleEndian));


// 16383.8  00-FF-7F-46
ubval = [0, 0xff, 0x7f, 0x46];
fval = ubval.peek!(float, Endian.littleEndian);
writefln(%s as float: %s, ubval, fval);
writefln(%s as float: %s, ubval, ubval.read!(float, 
Endian.littleEndian));


// FLOAT to UBYTE[]
ubval = [0, 0, 0, 0];
std.bitmanip.write!(float, Endian.littleEndian)(ubval, 
65535.0f, 0);

writefln(%s as ubyte[]: %s, fval, ubval);
ubval = [0, 0, 0, 0];
std.bitmanip.write!(float, Endian.littleEndian)(ubval, fval, 
0);

writefln(%s as ubyte[]: %s, fval, ubval);


}

---


is scid still maintained

2014-09-20 Thread uri via Digitalmars-d-learn

Hi All,

I'm wondering if SciD is still maintained because the last commit 
to this repo is a while ago now...


https://github.com/kyllingstad/scid


Is there a fork, or some other repo that is more up to date I 
should look at?




Thanks,
uri


Re: Friendly C link

2014-08-28 Thread uri via Digitalmars-d

These are of similar nature I believe for c++

http://www.csse.monash.edu.au/~damian/papers/PDF/ModestProposal.pdf
http://www.csse.monash.edu.au/~damian/papers/PDF/SPECS.pdf

This paper was by my c++ lecturer at the time it was published. A 
fantastic coder as well as academic who unfortunately was lost to 
Perl around the same time :D Below is an example of what that 
does to a person :)


http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

Cheers uri


Re: SWIG?

2014-08-27 Thread uri via Digitalmars-d

On Thursday, 28 August 2014 at 01:08:43 UTC, Scott Wilson wrote:
SWIG has D support. But it seems old and out of fashion. 
Community here does not buzz about it much either. Whats the 
word on the street about the quality of SWIG-D stuff?


Scott

PS thankyou Walter for replying


The swig bindings are good and I use them quite a bit to 
interface with legacy C++ projects.


This might be fixed already, I don't know and haven't tracked it 
but I had to make a minor change to the binding generator, as 
shown below.


edit commoncore_im.d and change the following:
---
mixin template SwigOperatorDefinitions() {
...
  static if (is(typeof(swigOpEquals(rhs {
return swigOpEquals(rhs);
  } else {
...
---
to
---
mixin template SwigOperatorDefinitions() {
...
  static if (is(typeof(swigOpEquals(rhs {
return cast(bool)(swigOpEquals(rhs)); // -- cast(bool) 
added

  } else {
...
---

cheers, uri


Re: Getting RefCounted to work with classes

2014-08-26 Thread uri via Digitalmars-d-learn

On Monday, 25 August 2014 at 21:14:03 UTC, Bienlein wrote:

Hello,

the code below compiles and runs fine. However, when I change 
Payload from struct to class I get compiler errors:


Error	1	Error: template instance 
std.typecons.RefCounted!(Payload, 
cast(RefCountedAutoInitialize)1) does not match template 
declaration RefCounted(T, RefCountedAutoInitialize autoInit = 
RefCountedAutoInitialize.yes) if (!is(T == 
class))	C:\Users\Nutzer\Windows Ordner\Documents\Visual Studio 
2013\Projects\RefCountedScratch\RefCountedScratch\main.d	26	


I tried many things, but nothing did it. Any help appreciated 
:-).

Thanks, Bienlein


import std.stdio;
import std.typecons;

struct Payload
{
private int num = 0;

this(int i)
{
num = i;
writefln(Payload's constructor called);
}

~this()
{
 writefln(Payload's destructor called);
}
}



int main(string[] argv)
{
alias RefCounted!(Payload, RefCountedAutoInitialize.yes) 
Data;


int bar = 12;
Data data = Data(bar);

return 0;
}


RefCounted does not work with classes. Classes are reference 
types already.



The key is in the error message ...if(!is(T == class))... 
restricts the template to non-class types only.


cheers,
uri


D with no druntime

2014-08-20 Thread uri via Digitalmars-d-learn

Hi All,

I am playing with a small hack OS for fun and in 2066 there are 
these undefined refs (I have no druntime):


_d_arraybounds (new to 2066)
_d_assert (new to 2066)
_d_unittest (new to 2066)
_Dmodule_ref (also in 2065)
_d_dso_registry (also in 2065)

It is trivial to stub these out but it got me wondering...

Is there any way to compile D that has no dependencies?


Thanks,
uri





Auto attributes for functions

2014-08-19 Thread uri via Digitalmars-d-learn

Hi all,

Bit new to D so this might be a very naive question...

Can the compiler auto infer function attributes?

I am often adding as many attributes as possible and use the 
compiler to show me where they're not applicable and take them 
away. It would be great if this could be achieved like so:


auto function() @auto
{}

instead of manually writing:

auto function() pure @safe nothrow @nogc const
{}

cheers,
uri







Re: implicit conversion

2014-08-12 Thread uri via Digitalmars-d-learn
Sorry should add this is on 2.066.0-rc2 and it used to work on 
2.064.


Cheers,
uri

On Tuesday, 12 August 2014 at 06:21:19 UTC, uri wrote:

Hi,

I'm trying to allow implicit conversions for my own type 
happening. I have the following:



import std.math;
import std.traits;

struct S(T)
if(isFloatingPoint!T)
{
T val;
alias val this;
}
void main()
{

auto s = S!float();
assert(isNaN(s));
s = 10.0;
assert(!isNaN(s));
}


But I get a compile time error:


Error: template std.math.isNaN cannot deduce function from 
argument types !()(S!float), candidates are:


std/math.d(4171):std.math.isNaN(X)(X x) if 
(isFloatingPoint!X)



Is there a way I can to do this, maybe opCall/opCast (I tried 
these but failed)?


Cheers,
uri




implicit conversion

2014-08-12 Thread uri via Digitalmars-d-learn

Hi,

I'm trying to allow implicit conversions for my own type 
happening. I have the following:



import std.math;
import std.traits;

struct S(T)
if(isFloatingPoint!T)
{
T val;
alias val this;
}
void main()
{

auto s = S!float();
assert(isNaN(s));
s = 10.0;
assert(!isNaN(s));
}


But I get a compile time error:


Error: template std.math.isNaN cannot deduce function from 
argument types !()(S!float), candidates are:


std/math.d(4171):std.math.isNaN(X)(X x) if 
(isFloatingPoint!X)



Is there a way I can to do this, maybe opCall/opCast (I tried 
these but failed)?


Cheers,
uri


Re: implicit conversion

2014-08-12 Thread uri via Digitalmars-d-learn
On Tuesday, 12 August 2014 at 06:37:45 UTC, Jonathan M Davis via 
Digitalmars-d-learn wrote:

On Tue, 12 Aug 2014 06:21:17 +
uri via Digitalmars-d-learn digitalmars-d-learn@puremagic.com 
wrote:



Hi,

I'm trying to allow implicit conversions for my own type
happening. I have the following:


import std.math;
import std.traits;

struct S(T)
if(isFloatingPoint!T)
{
 T val;
 alias val this;
}
void main()
{

 auto s = S!float();
 assert(isNaN(s));
 s = 10.0;
 assert(!isNaN(s));
}


But I get a compile time error:


Error: template std.math.isNaN cannot deduce function from
argument types !()(S!float), candidates are:

std/math.d(4171):std.math.isNaN(X)(X x) if
(isFloatingPoint!X)


Is there a way I can to do this, maybe opCall/opCast (I tried
these but failed)?


The problem is that isNaN is now templatized, and its 
constraint uses
isFloatingPoint, which requires that the type _be_ a floating 
point type, not
that it implicitly convert to one. So, as it stands, isNAN 
cannot work with
any type which implicitly converts to a floating point value. 
Either it will
have to be instantiated with the floating point type - e.g. 
isNaN!float(s) -
or you're going to have to explicitly cast s to a floating 
point type.


You can open a bug report - https://issues.dlang.org - and mark 
it as a
regression, and it might get changed, but the reality of the 
matter is that
templates don't tend to play well with implicit conversions. 
It's _far_ too
easy to allow something in due to an implicit conversion and 
then have it not
actually work, because the value is never actually converted. 
In general, I
would strongly advise against attempting to give types implicit 
conversions

precisely because they tend to not play nicely with templates.

- Jonathan M Davis


Thanks for the info. I'm happy to change my code and remove the 
implicit conversion. It was just for a convenience factor (floats 
with accumulated error).



Cheers,
uri



Re: undefined references

2014-08-10 Thread uri via Digitalmars-d-learn

On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]


this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}

[snip]

The following gives an error in 2066

struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // -- ERROR: declaration 
hacks.main.s is already defined

}


Cheers,
uri



Re: undefined references

2014-08-10 Thread uri via Digitalmars-d-learn

On Monday, 11 August 2014 at 04:02:12 UTC, uri wrote:

On Monday, 11 August 2014 at 03:12:45 UTC, Vlad Levenfeld wrote:
[snip]


this (Elements...)(Elements elements)
if (Elements.length == length)
{
foreach (i, element; elements)
components[i] = element;
}
this (Element element)
{
components[] = element;
}

[snip]

The following gives an error in 2066

struct S(F, size_t L)
{
F[L] c;
this(E...)(E el)
if(E.length == L)
{
foreach(i, e; el) {
c[i]= e;
}
}
this(F e) {
c[0] = e;
}
}
void main()
{
auto s = S!(double, 1)(1);
auto s = S!(double, 3)(1,2,3); // -- ERROR: declaration 
hacks.main.s is already defined

}


Cheers,
uri


Bah, never mind me I'm having a moment !

The above example works in 2066 when the second 's' is renamed to 
s1, as does this:



auto s = S!(float, 1)(1); // eq: S!(float, 1)(1)
auto s1 = S!(float, 2)(1); // eq: S!(float, 2)(1,nan)
auto s2 = S!(float, 2)(1, 2) // eq: S!(float,2)(1,2)


Cheers,
uri



Re: GtkD 2.4.0 released, GTK+ with D.

2014-08-05 Thread uri via Digitalmars-d-announce

On Tuesday, 5 August 2014 at 21:11:03 UTC, Mike Wey wrote:
GtkD is a D binding and OO wrapper of Gtk+ and is released on 
the LGPL

license.

The most notable changes in this release are the 
discontinuation of the support for D1, and better support for 
installing more than one version of GTK+ on Windows.

A full list of changes is available in the change log:
http://gtkd.org/changelog.html

GtkD 2.4.0 is now available on gtkd.org:
http://gtkd.org/download.html

Unlike previous releases this one doesn't come with an update 
to the latest release of GTK+. This is being worked on but 
changes in the gtk documentation means we need to switch to the 
gir files for generating the code.


Thanks heaps for this, GtkD is terrific!


Re: Case for std.experimental

2014-07-29 Thread uri via Digitalmars-d

On Tuesday, 29 July 2014 at 17:22:38 UTC, Dicebot wrote:
[snip]

I wonder what are other opinions.


Here's what I'd like to see as a D user with std.experimental...

dub:
== free-for-all libraries of varying quality
== Promoted on official D website.
== Included in the D download

std.experimental:
== Released with Phobos
== Reviewed modules by core D devs, akin to BETA/RC
== Guarantees on API stability but not set in stone.
== [maybe?] Changes require deprecation and another round in 
std.experimental



std:
== High quality with API in stone.
== Modules have been through 2 rounds of review
== Changes require deprecation over a longer period.





Cheers,
uri.











Re: Voting: std.logger

2014-07-29 Thread uri via Digitalmars-d
On Wednesday, 30 July 2014 at 00:15:26 UTC, H. S. Teoh via 
Digitalmars-d wrote:
On Tue, Jul 29, 2014 at 04:55:04PM -0700, Andrei Alexandrescu 
via Digitalmars-d wrote:

On 7/29/14, 4:16 PM, H. S. Teoh via Digitalmars-d wrote:
On Tue, Jul 29, 2014 at 11:09:27PM +, Robert burner 
Schadek via Digitalmars-d wrote:
On Tuesday, 29 July 2014 at 06:09:25 UTC, Andrei 
Alexandrescu wrote:

[...]
4. Replace defaultLogger with theLog. Logger is a word, 
but one

that means lumberjack so it doesn't have the appropriate
semantics.  The use is generally acceptable as a nice play 
on words
and as a disambiguator between the verb to log and the 
noun
log. When we actually want to talk about the current log 
in an

application, we should, however, call it the log. This is
negotiable.

I really don't care how a global Logger instance is called. 
Anyone

else has an opinion on this? Otherwise Andrei wins.
[...]

I propose 'stdlog'.

I thought of the same but then rejected it - stdlog looks like
offering the same interface as stdout and stderr. Nevertheless 
it's a

sensible choice, too. -- Andrei


I don't like 'theLog'. What about 'defaultLog'?


T


+1 for !theLog. I actually like dlog because I hate typing but 
defaultLog would be fine.



/uri


Re: [OT] Re: Redesign of dlang.org

2014-07-28 Thread uri via Digitalmars-d

On Monday, 28 July 2014 at 09:16:44 UTC, Gary Willoughby wrote:

You said you don't like it and you were heard the first time



I'm speaking the truth which often hurts.



Yes and I don't see w0rp running off and sulking about it either.

Your problem is you are not able to take any criticism 
whatsoever against this piece of work. The design is awful, 
period.


I have nothing against you personally and i think it's good 
that you are initiating this effort but the design is the first 
thing that should be addressed and in no way be an 
afterthought. I apologise if i sound terse but usually in my 
line of work shoddy efforts have to be address upfront and with 
prejudice.


w0rp et. al. have asked for your contributions in art/design 
because you say you know how to do a better job.




The very first thing you should of done is to create mockups 
(in photoshop, etc) of what each page should look like and make 
sure the design can accommodate all the content. Once the 
design is approved then implement the site. The backend is 
inconsequential, use whatever you are comfortable with. Vibe.d, 
LAMP it doesn't matter. Users don't care about the backend. 
What matters is the user experience (especially within the 
documentation) and that is what should be addressed in a 
thoughtful professional matter. This is not optional or 
something that should be done along the way.


Stating something is crap in a volunteer project is useless 
unless you can follow it up with something equally useful.


For an engineer you sound just like our marketing team at work: 
Always ready to produce some warm and fuzzy ideas but light on 
the specifics and actual work.


/uri


Re: DSnips - making D coding awesome in Vim (with GIFs!)

2014-07-17 Thread uri via Digitalmars-d-announce

On Thursday, 17 July 2014 at 20:57:10 UTC, Kiith-Sa wrote:
DSnips is a set of UltiSnips snippets for D (now with GIFs 
showing each snippet in action (image-heavy))


https://github.com/kiith-sa/DSnips

This is an attempt to overhaul the D snippets I got merged to 
UltiSnips (now a separate vim-snippets repository), as the 
previous snippets had quite a few bugs. The snippets should now 
be easy to use together/chain (e.g. an imp (import) snippet 
places the cursor on the beginning of the next line so imp 
can be used for another import, wrap in try/catch places the 
cursor to be ready to add more catch blocks, module license 
can be replaced by using another snippet inside it, etc.


There are some rather intelligent snippets, e.g. an operator 
builder for opBinary/opUnary/opOpAssign that will generate the 
skeleton for all operators typed in by the user, automatic DDoc 
Params: generation from function parameters, etc.


I want to eventually try to merge this back to the default 
repository, but I'd like some comments/criticism/ideas first. 
Should any snippets be removed? Added? Any problems with the 
current snippets? (the wrap in try/catch in the previous 
version had issues with wrapping indented text, for example)


Trying this out now. It's very good so far, nice work!

/uri


Re: DMD v2.066.0-b4

2014-07-16 Thread uri via Digitalmars-d-announce
On Wednesday, 16 July 2014 at 04:56:14 UTC, ketmar via 
Digitalmars-d-announce wrote:
bug tracker is just a thing to collecting dust. you can write 
your
report there, or to /dev/null, or not write it at all -- the 
result

will be the same.

i know at least 3 bugs in phobos and at least one very nasty 
bug in
compiler (which causes UB, so-called heisenbug), but have no 
motivation

to report. did i mention that i have fixes too?

but it's ok, spice must flow, new releases must be done.



You spent the effort implementing a fix, the time talking about 
your fix but cannot be buggered submitting a PR for the fix?


D has a problem ATM of too many talkers, not enough doers. Please 
submit a PR if you have a fix for anything in the bug tracker.


bye,
uri


Re: Random points from a D n00b CTO

2014-07-14 Thread uri via Digitalmars-d
On Monday, 14 July 2014 at 06:13:38 UTC, Manu via Digitalmars-d 
wrote:
On 14 July 2014 14:47, uri via Digitalmars-d 
digitalmars-d@puremagic.com

wrote:


On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:



- I was *very* disappointed that using base library locks you 
into GC vs

ref. counting.
Separate, I like how Objective C has NSObject for GC 
purpose(I'd love a
framework that is just ref counting), but there should be 
dual libs and

base should not be GC.



This topic was bashed to death. There were compelling arguments
from both sides, but in the end no one pushing for ARC could
produce evidence that it was better than GC.



Andrei himself pushed such evidence in an interesting case 
study that
explored a high-end ARC implementation. It compared 
impressively with 'the
fastest GC's' (or some description very close to that). D's GC 
is certainly
not among those in comparison, which suggested the paper's tech 
would

probably be a win for D no matter how you look at it.

And the counter evidence is overwhelming. As many times as I've 
asked the
experts for comment, I've still *NEVER* heard anybody disagree 
that D's GC
will probably remain really bad for the indefinite future. Even 
the ones
that are strongly in favour of GC; nobody seems to know how to 
do it, and

many have said it's probably impossible.
Even if it was theoretically possible, that only solves one of 
numerous
problems... Nobody has ever addressed the low-available-memory 
argument
I've put forward a number of times, which is the standard 
operating

environment of most embedded computers.

So, I don't feel like there was any such conclusion as you 
suggest.
Personally, I just became horribly apathetic and gave up. My 
general
participation and motivation in this community has declined 
significantly

as a result.

I'm among the minority that REALLY care about this, and it's 
clear (and
it's been made clear) that if I'm not prepared to work on it 
myself, then

it won't move forward.
That's fine, and it's perfectly reasonable. But I'm not in the 
least bit
interested in working on GC technology myself - I'm not an 
expert, and it's
not a field that interests me, thus I decided to desist 
participating in

discussions.

Currently there's a big push to remove hidden GC allocs from

Phobos, starting with @nogc.

std.allocators is just around the corner as well, which will
provide a solid framework to build better allocation 
strategies.



We're yet to see how to use the allocators API to specify a 
replacement
default allocator used by the languages intrinsic allocations, 
which makes

it rather less exciting.
Anyone can invent an allocator interface, but designing it such 
that it can
be used to configure the languages implicit allocations is much 
more
complex. I'm concerned that Andrei's allocator interface 
doesn't actually
address this... At least, I haven't seen any discussion about 
how it will.
That said, I'm not trying to down-play the importance of a 
standard
allocator API, and Andrei's development is very important and 
appreciated,
but I am yet to find out how it actually addresses any of my 
real concerns

relating to allocation.

As I see it, I have zero concern about allocations I control. I 
am entirely
concerned with intrinsic/implicit allocations that I don't, and 
may

potentially (likely) originate from within 3rd party libraries.


All good points. Thanks and my bad for the misinformation, sorry.

uri



Re: Random points from a D n00b CTO

2014-07-13 Thread uri via Digitalmars-d

On Monday, 14 July 2014 at 03:55:02 UTC, Vic wrote:

Hi all,
I'm a CTO at a start up and interested in porting our Java 
project to D. Some points, I have been lurking on D for years, 
went to my first D conf recently. Also I was one of top 20 
people to join Java Struts, and that grew to 3million plus end 
users so I have some 'cred'. Hope this helps:


- Confusing forum. First listed forum on 'D' is not for D 
users, but it's called D! It is in fact for D commiters. This 
causes frustration for both users and commiters. (yes there is 
'learn D' but it's 4th down. Commiters forum should be slightly 
hidden and user questions should not be answered in commuters 
but politely asked to post in the proper forum.).


I agree. It doesn't bother me personally, but I think the
discussions about lang design etc. should be under D Programming
Language - Development.

A new user might be put off by all the heated discussion about
the language design and get the impression D is still in flux.



- I was *very* disappointed that using base library locks you 
into GC vs ref. counting.
Separate, I like how Objective C has NSObject for GC 
purpose(I'd love a framework that is just ref counting), but 
there should be dual libs and base should not be GC.


This topic was bashed to death. There were compelling arguments
from both sides, but in the end no one pushing for ARC could
produce evidence that it was better than GC.

Currently there's a big push to remove hidden GC allocs from
Phobos, starting with @nogc.

std.allocators is just around the corner as well, which will
provide a solid framework to build better allocation strategies.



- D is/has become complex. metaprograming, generics, macros, 
etc. This is a culture issue, very hard to fix cultural issues 
w/o losing most commiters. Just a fast system lang w/o headers, 
'boost' and such. All this other stuff can be 3rd party eco 
system and should be pushed out from D proper into 
implementations and add ons.




This is why I use D. After many years in C++ I am not fond of
templates but in D they are almost transparent and so simple to
use. They provide amazing code reuse and CTFE for almost zero
additional complexity over run-time code.


- Dub rocks.


That is does, although I still use CMake :)



- Very little 'user' outreach. Meetups such as 'learn D'  (set 
up editor w/ DUB, and write some vibe.d DNS client/server in 4 
lessons). Or how to use a c .so lib.


So hth. FYI I plan to hire 3+ 'D lang' programmers (users, not 
commuters) to rewrite the Java project in Dallas and/or San 
Jose (CA) over the next few months (Feel free to ping me 
@puppetMaster3, ideal candidate is 'prolific' and career 
programmer)


Cheers, Vic


Good luck! Thankfully I can use D at work now, if I couldn't you
would have my CV within the hour :-)

Cheers,
uri


Will std.experimental be shipped with DMD zip package?

2014-06-05 Thread uri via Digitalmars-d

I assume it will but thought I'd ask all the same...

I only use the latest official release and would still like to 
bash on std.experimental modules so I hope it will be in 
2.066.zip.


Thanks,
uri


Re: Adam D. Ruppe's D Cookbook now available!

2014-05-29 Thread uri via Digitalmars-d-announce

On Thursday, 29 May 2014 at 10:28:45 UTC, Chris wrote:

On Wednesday, 28 May 2014 at 18:14:28 UTC, Walter Bright wrote:

http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book

http://www.amazon.com/D-Cookbook-Adam-D-Ruppe/dp/1783287217

http://www.reddit.com/r/programming/comments/26pn00/d_cookbook_officially_published_consists_of_d/

After watching Adam's most excellent presentation at Dconf, 
I'm sure the book will be great! My copy gets here on Friday.


I dug into Chapter 3 about ranges. It clarifies a lot of things 
about ranges. These little questions I kept asking my self, 
like is this good practice or a hack? etc. Thanks to one of 
his examples (+explanation) I've already been able to improve 
my production code. Thanks a million Adam!


+1, just purchased my copy :)


Re: Template delegate/function ptr struct member

2014-05-13 Thread uri via Digitalmars-d-learn

On Tuesday, 13 May 2014 at 07:50:09 UTC, Rikki Cattermole wrote:

On 13/05/2014 7:28 p.m., ed wrote:
I'm porting some C++ code to D and a struct has the following 
member:


struct S
{
// ...
 //void* (*createMethod)();

void* function() createMethod;

}

I'd like to extend this as little to accept delegates for 
future use

without breakage to existing code...

Is it possible to template this so createMethod can be a 
delegate() or
function() of any type *and* have the compiler infer the type 
from ctor

parameters?

For example:
---
struct S(F)
{
// ...
F createMethod;
this(alias F)() {createMethod = F;}
}
static void* func() {return null;}

void main() {
auto s1 = S(func);
auto s2 = S(Object.classinfo.create);

// s1 is S!(void* function())
// s2 is S!(Object delegate() const);
}
---

Is this a good idea or am I way off?

Thanks,
ed


I would recommend going the route of property functions and 
using delegates as the default.


alias createMethodDel = void* delegate();
alias createMethodFunc = void* function();

struct S {
private createMethodDel createMethod_;

@property {
createMethodDel createMethod() {
return createMethod_;
}

void createMethod(createMethodDel func) {
createMethod_ = func;
}

void createMethod(createMethodFunc func) {
import std.functional : toDelegate;
createMethod_ = toDelegate(func);
}
}
}

That way you know what you have access to is always callable 
and won't break any code.


I was so focused on a template solution that I never even thought 
of doing it that way, nice one :)



Thanks,
ed