date:20170804


On Saturday, 5 August 2017 at 01:22:46 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote:

Hey Guys,
I just trans-compiled a brainfuck mandelbrot into ctfeable D.
newCTFE is able to execute it correctly (although it takes 3.5 
minutes to do so).


You planning to do the same thing with other languages?


Other Domain-Specific-Langauges ?
Sure that is a useful application.

However if you are asking about translating non-trivial langauges 
like c++;

Frankly, there is little point in doing so.
Since non-trivial languages require non-trivial amounts of 
parsing and semantic-processing.
This would more fittingly done in a separate application rather 
then doing it at ctfe.

Re: ASCII-ART mandelbrot running under newCTFE


On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote:

Hey Guys,
I just trans-compiled a brainfuck mandelbrot into ctfeable D.
newCTFE is able to execute it correctly (although it takes 3.5 
minutes to do so).


The code is here
https://gist.github.com/UplinkCoder/d4e4426e6adf9434e34529e8e1f8cb47

The gist it evaluates the function at runtime since the newCTFE 
version capable of running this, is not yet available as a 
preview release.


If you want a laugh you can compile the code with ldc and -Oz 
flag set.
LLVM will detect that the function is pure and will try to 
constant-fold it.
I do not know how long this takes though since my patience is 
limited.


Cheers,
Stefan


You planning to do the same thing with other languages?

Re: Calling D from Ruby for GPU computing

2017-08-04 Thread Michael via Digitalmars-d-announce


On Saturday, 29 July 2017 at 06:54:47 UTC, Prasun Anand wrote:

Hi,

I wrote a Linear Mixed Model tool for Genome Wide Association 
Studies(GWAS) called
[faster_lmm_d](https://github.com/prasunanand/faster_lmm_d). It 
is built on LDC
and is faster than its Python alternative. Also, its the only 
GWAS tool with a GPU

backend.

I am interested in porting ` faster_lmm_d` to Ruby. Though, it 
is still a work in progress, I have written a blog about my 
findings.


Blog: 
http://www.prasunanand.com/gpu-computing/2017/07/25/gsoc17-calling-d-from-ruby-for-gpu-computing.html


I would love to hear your feedback.

Regards,
Prasun

[Previously posted on LDC thread: 
http://forum.dlang.org/thread/rzrawenyssbiidsgt...@forum.dlang.org]


I don't know much about your work but it sounds like an 
interesting application for D. How easy was it interfacing with 
cuda? Was it just cuda you targeted or would it also work with 
OpenCL? What made you choose D over going straight to C to work 
directly with cuda?

[Issue 17722] Wrong diagnostic using vector && vector expressions.

https://issues.dlang.org/show_bug.cgi?id=17722

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org
   Assignee|nob...@puremagic.com|ibuc...@gdcproject.org

--

[Issue 17722] New: Wrong diagnostic using vector && vector expressions.

https://issues.dlang.org/show_bug.cgi?id=17722

  Issue ID: 17722
   Summary: Wrong diagnostic using vector && vector expressions.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

import core.simd;
byte16 v1,v2,v3;
static assert(__traits(compiles, v1 && v2));
static assert(__traits(compiles, v1 || v2));

The error(s) I get are:
Error: static assert  (__traits(compiles, (__error) && (__error))) is false

Other expressions look fine, it's just && and ||.

--

Re: ASCII-ART mandelbrot running under newCTFE


On Saturday, 5 August 2017 at 00:59:01 UTC, Johnson Jones wrote:

On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote:

[...]



Any screenshots? I don't wanna have to install something I 
won't use but once or twice but would be interested in seeing 
what is going on since I used to be a fractal freak ;)


all you need is dmd.
almost any version will do.

dmd mandelb.d
./mandelb

Re: ASCII-ART mandelbrot running under newCTFE


On Friday, 4 August 2017 at 22:50:03 UTC, Stefan Koch wrote:

Hey Guys,
I just trans-compiled a brainfuck mandelbrot into ctfeable D.
newCTFE is able to execute it correctly (although it takes 3.5 
minutes to do so).


The code is here
https://gist.github.com/UplinkCoder/d4e4426e6adf9434e34529e8e1f8cb47

The gist it evaluates the function at runtime since the newCTFE 
version capable of running this, is not yet available as a 
preview release.


If you want a laugh you can compile the code with ldc and -Oz 
flag set.
LLVM will detect that the function is pure and will try to 
constant-fold it.
I do not know how long this takes though since my patience is 
limited.


Cheers,
Stefan



Any screenshots? I don't wanna have to install something I won't 
use but once or twice but would be interested in seeing what is 
going on since I used to be a fractal freak ;)

Re: Fix gtkD api display

2017-08-04 Thread Johnson Jones via Digitalmars-d-learn


On Friday, 4 August 2017 at 23:14:38 UTC, Adam D. Ruppe wrote:

On Friday, 4 August 2017 at 21:53:14 UTC, Johnson Jones wrote:
When I click on gtk on the link you gave it gives basically an 
empty page(a single module).


Yeah, there is no overview page in the source code... but I can 
make it create one automatically.




http://dpldocs.info/experimental-docs/gtk.HButtonBox.HButtonBox.html

Does not list any members to the left.


That's intentional, actually. For the left nav, I show parents 
and siblings, not children (that's in the main content on the 
right). I sometimes miss children there too, but siblings are 
actually usually more useful to me.


Easier to see the value in Phobos since it is flatter:
http://dpldocs.info/experimental-docs/std.algorithm.sorting.isSorted.html

you can see the bolded isSorted showing where you are now, and 
then its other siblings to navigate the module over there.




Yeah, that is a nice feature. But I do not think we are talking 
about the same thing.


While having the siblings only is also nice and desirable to 
reduce clutter, one needs to quickly see all methods in a module 
rather than having to hunt and peck.


This is actually done in the phobos link you gave and is what am 
I talking about. The problem then is that we do not see the 
hierarchy of all the modules and how they relate without having 
to click clinks.


e.g.,

http://dpldocs.info/experimental-docs/std.algorithm.sorting.nextPermutation.html

but

http://dpldocs.info/experimental-docs/std.html

shows all the modules in the main view which is very long and 
takes time to scroll. It would be nice if those were shown in the 
left pane rather than nothing.


This way, instead of having to scroll down the long list to find 
a module one can see it usually instantaneously to the left. 
Basically the same as the functions that are listed in the first 
link.


The way I would do it, probably, is to have a complete hierarchy 
tree.


std
   ...
   experimental
  ...
  allocator
 ...
 building_blocks
...
region
   ...
   InSituRegion


Now, obviously this is a very big list. (For speed, probably ajax 
would be used to load only the most relevant)


Also, everything cannot be expanded at the start. Only the most 
current position is expanded + any siblings.


So, it is sorta like what you have but offers a way to see the 
entire library and navigate it relatively quickly but without 
having to leave that panel to find something. It's all their, 
just not the descriptions, etc.(although mouse over could provide 
some basic description when required)


Because humans are amazing and have figured out vast ways to do 
things, I'd probably have a small toolbar at the top that lets 
one go between different views. If you want a flat list you click 
the flat button. If you want a full hierarchy you can click a 
button for that. If you want a reduced hierarchy(immediate module 
only, still in tree form but all the other branches off the root 
are not shown) you could get that. Siblings only would have a 
button.


Since all these are basically just different "views" of the same 
data, they all have their pros and cons and some are more useful 
than others at different times. The more ways one can view data 
the more ways one can understand the data.






gtkd has really shallow modules with just one class per module, 
so this appears less useful... but in general I find it really 
easily to navigate. Maybe I could detect the one class per 
module pattern and collapse it though.


My problem with gtkD's docs is that one cannot quickly(within a 
click) go from one module to another.


One must select the packages tab then find the module and click 
on it. Do whatever, then when one wants to go to another module, 
repeat the process. It's not slow in an absolute sense(whatever 
that means) but it takes a few seconds when it can be done < 1s.


Since the packages and module are tabbed, one can't have them 
both open. If they were side by side, it would probably work 
fine... not much different than a tree view.


Also, the package tree is not collapsed by default. This means 
more scrolling. Scrolling is a slow process. It may seems fast 
but it's just a waste of time ultimately because we cannot do 
anything while we are doing it... and all those little scrolls 
add up to significant time loss. It's similar to how banks try to 
get a few extra cents per customer because it's billions at the 
end of the day... or how manufactures try to cut costs on a 
product that are a few cents work per product but add up to 
billions.  Similar for programmers. Imagine if we could instantly 
find the help we wanted how much more time we would have over our 
lives. E.g., some type of brain interface device that we could 
transmit our thoughts in to and it would do a search for the data 
and present the results. That is effectively what we have with 
google or

Please document packages/libraries before putting them on dub registry

2017-08-04 Thread aberba via Digitalmars-d

Those packages without documentation might be useful but no one 
except you will use it because only you know how and what it 
does. We spend hours writing code but can't spend minutes getting 
people to use them.


Intro
Purpose
Usage
...
To do
Contributions

Basic stuff.

[Issue 17721] Wrong expression type using vector extensions with certain operands

https://issues.dlang.org/show_bug.cgi?id=17721

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org
   Assignee|nob...@puremagic.com|ibuc...@gdcproject.org

--

[Issue 17721] New: Wrong expression type using vector extensions with certain operands

https://issues.dlang.org/show_bug.cgi?id=17721

  Issue ID: 17721
   Summary: Wrong expression type using vector extensions with
certain operands
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

The operands encapsulated by the following classes have a result type that is
implicitly bool.

CmpExp
EqualExp
IdentityExp


The operands encapsulated by the following classes have a result type that is
implicitly int.

ShlExp
ShrExp
UshrExp


When handling vectors, the resultant type of the expression should also be a
vector. i.e:
---
float4 f1 = [1, 9, 8, 9];
float4 f2 = [2, 8, 0, 5];
float4 fr = f1 > f2;
assert((f1 > f2).array == [0, -1, -1, -1]);

int4 i1 = [1, 2, 3, 4];
int4 i2 = [2, 4, 8, 16];
int4 ir = i1 << i2;
assert(ir.array == [4, 32, 768, 262144]);
---

This is not a concern for dmd, who rejects these operands.

--

[Issue 17720] Wrong code using vector extensions with different types

https://issues.dlang.org/show_bug.cgi?id=17720

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org
   Assignee|nob...@puremagic.com|ibuc...@gdcproject.org

--

[Issue 17720] New: Wrong code using vector extensions with different types

https://issues.dlang.org/show_bug.cgi?id=17720

  Issue ID: 17720
   Summary: Wrong code using vector extensions with different
types
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

This is code is accepted by the compiler, but should be rejected, to be
consistent with static and dynamic array ops.

---
float4 v1;
int4 v2 = [1,2,3,4];
int4 v3 = [5,6,7,8];

v1 = v2 + v3;

// Prints: [8.40779e-45, 1.12104e-44, 1.4013e-44, 1.68156e-44]
writeln(v1.array);
---

--

Re: Fix gtkD api display

2017-08-04 Thread Gerald via Digitalmars-d-learn


On Friday, 4 August 2017 at 21:54:26 UTC, Johnson Jones wrote:

On Friday, 4 August 2017 at 15:24:51 UTC, Gerald wrote:

On Friday, 4 August 2017 at 15:08:27 UTC, Mike Wey wrote:

[...]


Mike I had contributed the makeddox.sh script awhile ago, it 
generates much nicer documentation then candydocs in my IHMO 
and includes a nice search box. If there is something lacking 
in it that needs to be improved before it can be used let me 
know and I'll do the work.


The only issue with it that I am aware of is you need to 
manually copy the public ddox css into the generated folder. I 
didn't see an easy way to determine it's location 
automatically.


Is there any online demo of it working?


Unfortunately there is not, I just run it locally on my laptop.

Re: Fix gtkD api display

2017-08-04 Thread Adam D. Ruppe via Digitalmars-d-learn


On Friday, 4 August 2017 at 21:53:14 UTC, Johnson Jones wrote:
When I click on gtk on the link you gave it gives basically an 
empty page(a single module).


Yeah, there is no overview page in the source code... but I can 
make it create one automatically.




http://dpldocs.info/experimental-docs/gtk.HButtonBox.HButtonBox.html

Does not list any members to the left.


That's intentional, actually. For the left nav, I show parents 
and siblings, not children (that's in the main content on the 
right). I sometimes miss children there too, but siblings are 
actually usually more useful to me.


Easier to see the value in Phobos since it is flatter:
http://dpldocs.info/experimental-docs/std.algorithm.sorting.isSorted.html

you can see the bolded isSorted showing where you are now, and 
then its other siblings to navigate the module over there.



gtkd has really shallow modules with just one class per module, 
so this appears less useful... but in general I find it really 
easily to navigate. Maybe I could detect the one class per module 
pattern and collapse it though.


When one scrolls down to view a long page one doesn't want to 
have to scroll all the way back up to view the members list 
again.


See, this is why I DON'T use a tree over there. There's just way 
too much scrolling in a tree, both vertical and horizontal. By 
just showing parents and siblings, it presents the most useful 
info without needing scrolling... it just doesn't work well for 
one class per module.



Since many programs spend a significant portion of their life 
searching through docs online, I think it's important to 
optimize that routine.


That's why I forked the docs... everyone else was just doing the 
same boring crap so I went something fairly different.


I'm not sure what Geralds docs look like but it might solve 
many of the problems already and you don't have to waste your 
time if you don't want to.


It sounds like ddox which is one option I evaluated and rejected 
when I did my fork... so it might be ok but I doubt it is better.


The official gtk docs are the competition and I don't actually 
like them either...


I don't know how time consuming it would be to rerun it on all 
the docs you've generated... hopefully you've automated that 
too ;).


Simple case of running ./doc /path/to/gtk and waiting like 5 mins 
for it. So it is slow but automatic so I can just do it in the 
background.


I just hate running big disk operations on my computer... so I 
need to optimize this since I run so many docs now.

ASCII-ART mandelbrot running under newCTFE

2017-08-04 Thread Steven Schveighoffer via Digitalmars-d-learn


Hey Guys,
I just trans-compiled a brainfuck mandelbrot into ctfeable D.
newCTFE is able to execute it correctly (although it takes 3.5 
minutes to do so).


The code is here
https://gist.github.com/UplinkCoder/d4e4426e6adf9434e34529e8e1f8cb47

The gist it evaluates the function at runtime since the newCTFE 
version capable of running this, is not yet available as a 
preview release.


If you want a laugh you can compile the code with ldc and -Oz 
flag set.
LLVM will detect that the function is pure and will try to 
constant-fold it.
I do not know how long this takes though since my patience is 
limited.


Cheers,
Stefan

Re: Fix gtkD api display

2017-08-04 Thread Johnson Jones via Digitalmars-d-learn


On Friday, 4 August 2017 at 15:24:51 UTC, Gerald wrote:

On Friday, 4 August 2017 at 15:08:27 UTC, Mike Wey wrote:
Improving the documentation is something i want to do but 
there are always some more important things to do. Like the 
Questions/Issues you posted earlier.


So unless somebody volunteers it won't happen anytime soon.


Mike I had contributed the makeddox.sh script awhile ago, it 
generates much nicer documentation then candydocs in my IHMO 
and includes a nice search box. If there is something lacking 
in it that needs to be improved before it can be used let me 
know and I'll do the work.


The only issue with it that I am aware of is you need to 
manually copy the public ddox css into the generated folder. I 
didn't see an easy way to determine it's location automatically.


Is there any online demo of it working?

Thanks.

Re: Fix gtkD api display

2017-08-04 Thread Johnson Jones via Digitalmars-d-learn

On Friday, 4 August 2017 at 13:59:11 UTC, Adam D. Ruppe wrote:

On Friday, 4 August 2017 at 02:08:31 UTC, Johnson Jones wrote:

https://api.gtkd.org/gtkd/gtk/ApplicationWindow.html

So I ran gtkd through my doc generator too

http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html

and I didn't make a top-level package file either... but doing
that wouldn't be hard. However, I noticed it is basically the
same as the official C documents:
https://developer.gnome.org/gtk3/stable/GtkApplicationWindow.html so idk if it is worth spending a lot of time on it.

Looks nicer in some ways and in others I prefer the original.

I particularly like the members list. The use of the different
font sizes, colors, and boxes/lines help contrast elements well.

When I click on gtk on the link you gave it gives basically an
empty page(a single module). If I click on ApplicationWindow it
takes me to a page that lists all the members on the left, which
is nice. Probably minor bugs or issues.

e.g.,

http://dpldocs.info/experimental-docs/gtk.HButtonBox.HButtonBox.html

Does not list any members to the left.

The left list should be an independent panel. When one scrolls
down to view a long page one doesn't want to have to scroll all
the way back up to view the members list again. It results in a
slower process. Seems that is how many of the D docs are but it's
wrong/unnecessary as it slows searching down. e.g., the original
gtkD docs have a scrollable panel like I'm talking about, but
they just list one module at a time, which makes it difficult:

https://api.gtkd.org/gtkd/gtk/AboutDialog.html

and

https://developer.gnome.org/gtk3/stable/GtkApplicationWindow.html

has no side panel.

So, with a little tightening up, I'd definitely prefer your docs
over the other two versions. (It's always good to have multiple
versions though)

I think any type of documentation should aim at two goals: As
much information as possible and to quickly access any point in
that information from any other point with information points
that are closer being more quickly accessed(A metric). The way
the info is organized is, of course, going then to be dependent
on the above.

Since many programs spend a significant portion of their life
searching through docs online, I think it's important to optimize
that routine. Would be nice if programmers learned to optimize
not only programs but the art of programming itself... we'd all
get much more done. After all, many of the same principles apply.
But things are way better than they used to be, so that's a good
sign ;)

I'm not sure what Geralds docs look like but it might solve many
of the problems already and you don't have to waste your time if
you don't want to. OTH, since you are using an automated utility,
it might be worth while to optimize it a little more since it
will effect everything it's used on(although, I don't know how
time consuming it would be to rerun it on all the docs you've
generated... hopefully you've automated that too ;).

Thanks.

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread Walter Bright via Digitalmars-d


On 8/4/2017 2:26 AM, Maksim Fomin wrote:
So, you agree that @safe cannot solve the problem because of C function 
interfaces and 'lack of machine checkable memory safety in C'. In this case, why 
does @safe relies on static analysis in CT and type inference when memory safety 
is determined by the 'C memory sate' at RT? Either @safe is wrongly presented 
(it is not memory safety tool, but something else) or (if the intention was to 
provide memory safety tool) it is a flawed feature.


Every memory safe language that talks to C code (Rust, Java, etc.) has this 
issue. Once you step outside the language, guarantees cannot be made. It's not 
reasonable to assume otherwise.



It appears, that scope has its own loopholes too [1].
[1] https://issues.dlang.org/show_bug.cgi?id=17718


All languages have bugs in their implementations. What do you suggest we do 
about that?

Re: Jetbrains announce support for rust plugin, show them we want one too!

2017-08-04 Thread SCev via Digitalmars-d


On Friday, 4 August 2017 at 19:42:43 UTC, Ali wrote:

On Friday, 4 August 2017 at 19:27:13 UTC, SCev wrote:

[...]


Well, according to the blog entry, the Rust plugin was a side 
project for an intern


While this is official support, it seems they are not really 
adding a lot more manpower behind it, it will mostly remain the 
work for this intern


They dont have plans for a standalone rust ide, like clion for 
c++


In other words, it really didnt cost them much to support this 
plugin


And I see very little commercial incentive for them to support D

I think a community support for the Dlang intellij plugin is 
our best hope
we can start a kickstarter project and donate money to them .. 
might work


I would donate to them if they also include a refactoring tool


this is because of the way you think that D doesn't have that 
missing traction...


people on this forum need to change.. i'm disapointed

Re: Size of D bool vs size of C++ bool


On 8/4/17 4:16 PM, Jeremy DeHaan wrote:
I'm trying to do some binding code, and I know that C++ bool isn't 
defined to be a specific size like D's bool. That said, can I assume 
that the two are the same size on the most platforms?


I shudder to think that D may work with a platform that doesn't consider 
it to be 1 byte :)


The only platforms I'm really interested in are Windows, Linux, OSX, 
iOS, FreeBSD, Android. The only thing that might throw me off is if 
there are some things that Linux or FreeBSD target where this is not the 
case, but these machines are probably out of the scope of my project.


I would say any platform that D currently supports, C++ bool is defined 
to be 1 byte.


The ldc/gdc guys would know better.

-Steve

Size of D bool vs size of C++ bool

2017-08-04 Thread Jeremy DeHaan via Digitalmars-d-learn

I'm trying to do some binding code, and I know that C++ bool 
isn't defined to be a specific size like D's bool. That said, can 
I assume that the two are the same size on the most platforms?


The only platforms I'm really interested in are Windows, Linux, 
OSX, iOS, FreeBSD, Android. The only thing that might throw me 
off is if there are some things that Linux or FreeBSD target 
where this is not the case, but these machines are probably out 
of the scope of my project.

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread deadalnix via Digitalmars-d


On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See - 
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce


A long read. Someone has stolen $31M of Ether.



To give an idea of how bad it is:

https://news.ycombinator.com/item?id=14691212

Anyone writing smart contracts on ETH right now is crazy.

Re: SVD_to_D: Generate over 100k lines of highly-optimized microcontroller mmapped-IO code in the blink of an eye

2017-08-04 Thread Taylor Hillegeist via Digitalmars-d-announce

On Wednesday, 2 August 2017 at 13:31:40 UTC, Steven Schveighoffer 
wrote:

On 8/1/17 8:34 PM, Mike wrote:
On Tuesday, 1 August 2017 at 14:52:51 UTC, Steven 
Schveighoffer wrote:



[...]


I'm not sure my work is worthy of such kind words, but thank 
you.


Sorry, it was awesome. You should own it. I think many people 
were impressed with what you were able to achieve, especially 
those who have dealt with embedded programming.


The PDF screen utility is here: 
https://github.com/JinShil/stm32_datasheet_to_d.  I'm not sure 
if it still compiles and works, but I might need to update it 
someday.


It generates much better code and more complete documentation 
than svd_to_d.  Most silicon vendors don't appear to invest 
much into their SVD files, so the SVD files are often 
incomplete and lacking the documentation that makes "good code 
+ a good IDE = a substitute for the datasheet".

>
If I were creating a professional product, I'd probably prefer 
scraping the PDF over using the SVD files, or maybe some way 
to merge the two.




Yes, if the datasheet is wrong, they probably hear about it 
more, and fix it more readily than some xml files. Much harder 
to fix etch than it is to update some software.


In addition, I bet the software engineers take both into 
account and defer to the spec, meaning the bugs in the SVD may 
not get reported.


I would prefer the more accurate picture if it were me. In 
fact, you may be able to give them a better tool to generate 
the SVD file from the pdf :)


-Steve


I'm not completely sure but I would guess that the documentation 
was generated from the .svd files. If you think about it doing 
the documentation by hand would be another thing that the chip 
manufactures would have to validate against. If the documentation 
is generated from the .svd and the documentation is correct than 
the .svd file is also correct.

Re: Jetbrains announce support for rust plugin, show them we want one too!

2017-08-04 Thread Ali via Digitalmars-d


On Friday, 4 August 2017 at 19:27:13 UTC, SCev wrote:
yes, but would be cool to have official support from jetbrains, 
they know their ide/plugin API better than anyone else, so it'd 
speed up / improve dev of the plugin by a lot!


Don't stay silent, post comment on their page :D


Well, according to the blog entry, the Rust plugin was a side 
project for an intern


While this is official support, it seems they are not really 
adding a lot more manpower behind it, it will mostly remain the 
work for this intern


They dont have plans for a standalone rust ide, like clion for c++

In other words, it really didnt cost them much to support this 
plugin


And I see very little commercial incentive for them to support D

I think a community support for the Dlang intellij plugin is our 
best hope
we can start a kickstarter project and donate money to them .. 
might work


I would donate to them if they also include a refactoring tool

Re: Who maintains the D website?

On Friday, 4 August 2017 at 00:47:30 UTC, Steven Schveighoffer 
wrote:

[...]
Note, NNTP supports deleting your posts, I've done it before 
(on this site). It would be nice if the forum software detected 
that as well (maybe it does?).


-Steve


What might also be nice is a forum section that mirrors questions 
tagged with "d" or "dlang" on stackoverflow.


https://isocpp.org/ has something like this on their page under 
("Selected Recent C++ Questions"). The title seems to suggest 
human intervention, but I imagine such a thing could be automated.

Re: Jetbrains announce support for rust plugin, show them we want one too!

2017-08-04 Thread SCev via Digitalmars-d


On Friday, 4 August 2017 at 18:36:56 UTC, Ali wrote:

On Friday, 4 August 2017 at 18:15:47 UTC, SCev wrote:
Just today, jetbrains announced their official support for the 
rust plugin


I'm sure they'll do something for D if we ask them, don't stay 
silent!! show them you want something


Leave a comment in their blog for a D support!  too!

We can do it!

https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/


there is already a pluggin for D,
https://github.com/intellij-dlanguage/intellij-dlanguage

not officially supported by Jetbrains
seems to be under active development


yes, but would be cool to have official support from jetbrains, 
they know their ide/plugin API better than anyone else, so it'd 
speed up / improve dev of the plugin by a lot!


Don't stay silent, post comment on their page :D

Re: dlang symbolic algebra library?

2017-08-04 Thread bachmeier via Digitalmars-d


On Friday, 4 August 2017 at 16:51:12 UTC, Schrom, Brian T wrote:
On Fri, Aug 04, 2017 at 09:31:16AM +, olzhas via 
Digitalmars-d wrote:

Hi everyone,
Can anyone advise a symbolic algebra library written in dlang?


I've been looking for something akin to https://www.ginac.de/ 
as well.


I wonder how difficult it would be to create bindings to ginac. 
Supposedly D is good at interoperating with C++ now.


Some time ago I did use ginac from D, but a little differently. 
There is little advantage to using D for the symbolic algebra 
part. I wrote up a C++ library with functions to do the 
calculations, created a .so, and called it from D. Then I decided 
I didn't want to mess with C++ at all, so I wrote a D function 
that would take the symbolic algebra part as a string, compile a 
C++ library, and I used that from D. I suppose that is a bit of a 
hack, but it only took a few minutes to add that functionality to 
D. Writing a quality symbolic algebra library would take many 
years and wouldn't provide much benefit.

Re: Jetbrains announce support for rust plugin, show them we want one too!

2017-08-04 Thread Ali via Digitalmars-d


On Friday, 4 August 2017 at 18:15:47 UTC, SCev wrote:
Just today, jetbrains announced their official support for the 
rust plugin


I'm sure they'll do something for D if we ask them, don't stay 
silent!! show them you want something


Leave a comment in their blog for a D support!  too!

We can do it!

https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/


there is already a pluggin for D,
https://github.com/intellij-dlanguage/intellij-dlanguage

not officially supported by Jetbrains
seems to be under active development

Re: delegate confusion


On Friday, 4 August 2017 at 17:36:05 UTC, Moritz Maxeiner wrote:
[...]


[1] https://dlang.org/spec/function.html#closures
[2] https://dlang.org/spec/garbage.html#op_involving_gc


Thanks for the references - I guess this was a mistake on my part 
by googling "lambda" instead of "closure".

Re: delegate confusion


On Friday, 4 August 2017 at 17:27:52 UTC, Timon Gehr wrote:

On 04.08.2017 18:57, bitwise wrote:

[...]

3) heap allocate a chunk of space for each captured scope (as 
in lisp and C#).


The way to go is 3). 1) is bad, because it completely prevents 
closures from being escaped, 2) is bad because it does not 
allow sharing of closure memory.


Makes sense.

When I look at the output I get from the code above though, it 
seems like neither of these things were done, and that someone 
has gone way out of their way to implement some very strange 
behavior.

...


Absolutely not. The current behavior was quite straightforward 
to implement, but it is wrong. Bugs often lead to strange 
behavior. This does not imply that such bugs are intentional.


In hindsight, I would have to agree that the current approach may 
be a little _too_ straight forward ;)


[...]


You can work around the bug like this:

foreach(i;0..5)(){
int j=i;
funs~=(){ writeln(j); };
}()


Thanks for this - most workarounds I came across this morning 
were pretty bloated.

Re: dlang-requetst: openssl 1.1 compatible release

2017-08-04 Thread ikod via Digitalmars-d-announce


On Friday, 4 August 2017 at 17:06:16 UTC, Jack Applegame wrote:

On Thursday, 3 August 2017 at 06:33:38 UTC, ikod wrote:

Hello,

Since version 0.5.0 dlang-requests has become compatible with 
both 1.0.x and 1.1.x versions of openssl library.


Please try and report any issues on github.
Thanks!

dlang-requests is HTTP/FTP client library, inspired by 
python-requests with goals:


small memory footprint
performance
simple, high level API
native D implementation

https://code.dlang.org/packages/requests
https://github.com/ikod/dlang-requests


Does dlang-requests support binding interface for outgoing 
connection, like curl --interface option?


No, but this can be done. It would be nice if you post issue on 
github.


Thanks!

Re: delegate confusion

On Friday, 4 August 2017 at 17:18:41 UTC, Steven Schveighoffer 
wrote:

On 8/4/17 12:57 PM, bitwise wrote:

[...]


Because the stack frame of foo or bar or baz is stored on the 
heap BEFORE the function is entered. The compiler determines 
that the stack frame will need to be captured, so it captures 
it on function entry, not when the delegate is taken. Then the 
variable location is reused for the loop, and all delegates 
point at the same stack frame.


This is necessary for cases where the delegate may affect the 
frame data during the function call. For instance:


void foo()
{
   int i;
   auto dg = { ++i;};
   dg();
   dg();
   assert(i == 2);
}

What is needed is to allocate one frame per scope, and have the 
delegate point at the right ones.


Note, the C++ behavior uses dangling stack pointers, and not 
something we want to support in D.


-Steve


Thanks for clearing this up. Looking over my examples again, this 
makes sense now. I suppose while this behavior is not ideal, it 
does mean that I can safely throw lambdas that capture things 
into a queue to be executed later, which was my main concern.


I wish this forum was a little more advanced so I could change 
the post title I fudged and make this information more visible =/

Jetbrains announce support for rust plugin, show them we want one too!

2017-08-04 Thread SCev via Digitalmars-d

Just today, jetbrains announced their official support for the 
rust plugin


I'm sure they'll do something for D if we ask them, don't stay 
silent!! show them you want something


Leave a comment in their blog for a D support!  too!

We can do it!

https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/

Re: dlang symbolic algebra library?

2017-08-04 Thread Schrom, Brian T via Digitalmars-d

On Fri, Aug 04, 2017 at 09:31:16AM +, olzhas via Digitalmars-d wrote:
> Hi everyone,
> Can anyone advise a symbolic algebra library written in dlang?

I've been looking for something akin to https://www.ginac.de/ as
well.

Re: delegate confusion

2017-08-04 Thread Moritz Maxeiner via Digitalmars-d


On Friday, 4 August 2017 at 17:47:01 UTC, Moritz Maxeiner wrote:

On Friday, 4 August 2017 at 17:44:23 UTC, Timon Gehr wrote:

On 04.08.2017 19:36, Moritz Maxeiner wrote:


[...]


I was (explicitly) arguing that it's in keeping with the 
current spec.
That the spec is unsound and should be updated is another 
matter (on which I agree with you).


s/arguing/explaining/

Re: delegate confusion

2017-08-04 Thread Moritz Maxeiner via Digitalmars-d


On Friday, 4 August 2017 at 17:44:23 UTC, Timon Gehr wrote:

On 04.08.2017 19:36, Moritz Maxeiner wrote:


Next I run `bar`. I get the same output of "4 4 4 4 4". While 
this hack works in C#, I suppose it's reasonable to assume 
the D compiler would just reuse stack space for `j`, and that 
the C# compiler has some special logic built in to handle 
this.


Yes, `j` exists once in foo's stack frame, so the same thing 
as in the above happens, because `j`'s value after the loop's 
termination is also 4.


Make `j` 'immutable' to appreciate why this behavior is unsound 
(this is a form of memory corruption).


I was (explicitly) arguing that it's in keeping with the current 
spec.
That the spec is unsound and should be updated is another matter 
(on which I agree with you).

Re: delegate confusion

2017-08-04 Thread Steven Schveighoffer via Digitalmars-d


On Friday, 4 August 2017 at 17:27:52 UTC, Timon Gehr wrote:
In D, the foreach loop variable is a distinct declaration for 
each loop iteration, while in C#, the same loop variable is 
repeatedly reassigned. In C#, the issue is bad language design, 
while in D, the issue is a buggy compiler implementation 
leading to memory corruption.

[ ... ]
It's reasonable to assume that the D compiler uses the same 
memory location for all of the distinct variables. This is a 
dangling pointer bug, if you wish. Both of your examples should 
print "0 1 2 3 4".

[ ... ]

3) heap allocate a chunk of space for each captured scope (as 
in lisp and C#).


The way to go is 3). 1) is bad, because it completely prevents 
closures from being escaped, 2) is bad because it does not 
allow sharing of closure memory.


Thanks for you insight Timon.
Would you mind writing an ER. (enhancment request) for that.
And a small spec-like proto-DIP ?

I'd love to adopt that behavior for newCTFE where it is actually 
the more straightforward way. (in light of the constraints 
newCTFEs architecture has)

Re: delegate confusion

2017-08-04 Thread Timon Gehr via Digitalmars-d


On 04.08.2017 19:36, Moritz Maxeiner wrote:


Next I run `bar`. I get the same output of "4 4 4 4 4". While this 
hack works in C#, I suppose it's reasonable to assume the D compiler 
would just reuse stack space for `j`, and that the C# compiler has 
some special logic built in to handle this.


Yes, `j` exists once in foo's stack frame, so the same thing as in the 
above happens, because `j`'s value after the loop's termination is also 4.


Make `j` 'immutable' to appreciate why this behavior is unsound (this is 
a form of memory corruption).

Re: Who maintains the D website?

2017-08-04 Thread Vladimir Panteleev via Digitalmars-d


On Thursday, 3 August 2017 at 23:28:36 UTC, 12345swordy wrote:
Can we gain the ability to edit our own post? I typically make 
some grammar/spelling mistacks here and there and it would be 
nice for me to fix this.


Yes, I would like to add an optional edit window before forum 
posts are sent off to NNTP/email in the next forum update.

Re: delegate confusion

2017-08-04 Thread Moritz Maxeiner via Digitalmars-d


On Friday, 4 August 2017 at 16:57:37 UTC, bitwise wrote:
I'm confused about how D's lambda capture actually works, and 
can't find any clear specification on the issue. I've read the 
comments on the bug about what's described below, but I'm still 
confused. The conversation there dropped off in 2016, and the 
issue hasn't been fixed, despite high bug priority and plenty 
of votes.


How it works is described here [1] (and the GC involvement also 
listed here [2]), with the key sentences being


Delegates to non-static nested functions contain two pieces of 
data: the pointer to the stack frame of the lexically 
enclosing function (called the frame pointer) and the address 
of the function.


i.e. delegates point to the enclosing function's *stack frame* 
and access of its variables through that single pointer.


and

The stack variables referenced by a nested function are still 
valid even after the function exits (this is different from D 
1.0). This is called a closure.


i.e. when you return a delegate to somewhere where the enclosing 
function's stack frame will have become invalid, D creates a 
(delegate) closure, copying the necessary frame pointed to by the 
delegate's frame pointer to the GC managed heap.




Consider this code:

void foo() {
void delegate()[] funs;

foreach(i; 0..5)
funs ~= (){ writeln(i); };

foreach(fun; funs)
fun();
}

void bar() {
void delegate()[] funs;

foreach(i; 0..5)
{
int j = i;
funs ~= (){ writeln(j); };
}
foreach(fun; funs)
fun();
}


void delegate() baz() {
int i = 1234;
return (){ writeln(i); };
}

void overwrite() {
int i = 5;
writeln(i);
}

int main(string[] argv)
{
foo();
bar();

auto fn = baz();
overwrite();
fn();

return 0;
}

First, I run `foo`. The output is "4 4 4 4 4".
So I guess `i` is captured by reference, and the second loop in 
`foo` works because the stack hasn't unwound, and `i` hasn't 
been overwritten, and `i` contains the last value that was 
assigned to it.


`i` is accessed by each of the four delegates through their 
respective frame pointer, which (for all of them) points to foo's 
stack frame, where the value of `i` is 4 after the loop 
terminates.




Next I run `bar`. I get the same output of "4 4 4 4 4". While 
this hack works in C#, I suppose it's reasonable to assume the 
D compiler would just reuse stack space for `j`, and that the 
C# compiler has some special logic built in to handle this.


Yes, `j` exists once in foo's stack frame, so the same thing as 
in the above happens, because `j`'s value after the loop's 
termination is also 4.




Now, I test my conclusions above, and run `baz`, `overwrite` 
and `fn`. The result? total confusion.
The output is "5" then "1234". So if the lambdas are 
referencing the stack, why wasn't 1234 overwritten?


This works as per spec:
Invoking baz() creates a delegate pointing to baz's stack frame 
and when you return it, that frame is copied to the GC managed 
heap by the runtime (because the delegate would have an invalid 
frame pointer otherwise).
overwrite is a normal function with its own stack frame, which is 
used in its call to writeln.
It does not interfact with baz, or the delegate returned by baz, 
in any way.



[...]


[1] https://dlang.org/spec/function.html#closures
[2] https://dlang.org/spec/garbage.html#op_involving_gc

Re: delegate confusion

2017-08-04 Thread Timon Gehr via Digitalmars-d


On 04.08.2017 18:57, bitwise wrote:
I'm confused about how D's lambda capture actually works, and can't find 
any clear specification on the issue. I've read the comments on the bug 
about what's described below, but I'm still confused. The conversation 
there dropped off in 2016, and the issue hasn't been fixed, despite high 
bug priority and plenty of votes.


Consider this code:

void foo() {
 void delegate()[] funs;

 foreach(i; 0..5)
 funs ~= (){ writeln(i); };

 foreach(fun; funs)
 fun();
}

void bar() {
 void delegate()[] funs;

 foreach(i; 0..5)
 {
 int j = i;
 funs ~= (){ writeln(j); };
 }
 foreach(fun; funs)
 fun();
}


void delegate() baz() {
 int i = 1234;
 return (){ writeln(i); };
}

void overwrite() {
 int i = 5;
 writeln(i);
}

int main(string[] argv)
{
 foo();
 bar();

 auto fn = baz();
 overwrite();
 fn();

 return 0;
}

First, I run `foo`. The output is "4 4 4 4 4".
So I guess `i` is captured by reference, and the second loop in `foo` 
works because the stack hasn't unwound, and `i` hasn't been overwritten, 
and `i` contains the last value that was assigned to it.


Next I run `bar`. I get the same output of "4 4 4 4 4". While this hack 
works in C#,


It's very important to understand that the C# is different, even though 
it looks similar. In D, the foreach loop variable is a distinct 
declaration for each loop iteration, while in C#, the same loop variable 
is repeatedly reassigned. In C#, the issue is bad language design, while 
in D, the issue is a buggy compiler implementation leading to memory 
corruption.


I suppose it's reasonable to assume the D compiler would 
just reuse stack space for `j


It's reasonable to assume that the D compiler uses the same memory 
location for all of the distinct variables. This is a dangling pointer 
bug, if you wish. Both of your examples should print "0 1 2 3 4".


and that the C# compiler has some 
special logic built in to handle this.

...


The C# compiler just uses the correct rules for creating closures. (It 
is hard for the compiler to screw this up, because the underlying 
platform aims to prevents memory corruption.)


Now, I test my conclusions above, and run `baz`, `overwrite` and `fn`. 
The result? total confusion.
The output is "5" then "1234". So if the lambdas are referencing the 
stack, why wasn't 1234 overwritten?

...


The lambdas are referencing the heap, but all of them reference 
identical heap locations. This should not happen. Distinct variables 
shouldn't share the same memory.



Take a simple C++ program for example:

int* foo() {
 int i = 1234;
 return 
}

void overwrite() {
 int i = 5;
 printf("%d\n", i);
}

int main()
{
 auto a = foo();
 overwrite();
 printf("%d\n", *a);
 return 0;
}

This outputs "5" and "5" which is exactly what I expect, because I'm 
overwriting the stack space where the first `i` was stored with "5".

 > So now, I'm thinking D must be storing these captures on the heap
then..right? So why would I get "4 4 4 4 4" instead of "0 1 2 3 4" for 
`foo` and `bar`?


This makes absolutely no sense at all.

It seems like there are two straight forward approaches available here:

1) capture everything by reference, in which case the `overwrite` 
example would work just like the C++ version. Then, it would be up to 
the programmer to heap allocate anything living beyond the current scope.

...


Capturing by reference is not the same as creating stack references. The 
language semantics don't even need to be implemented using a stack.


2) heap allocate a chunk of space for each lambda's captures, and copy 
everything captured into that space when the lambda is constructed. This 
of course, would mean that `foo` and `bar` would both output "0 1 2 3 4".

...


3) heap allocate a chunk of space for each captured scope (as in lisp 
and C#).


The way to go is 3). 1) is bad, because it completely prevents closures 
from being escaped, 2) is bad because it does not allow sharing of 
closure memory.


When I look at the output I get from the code above though, it seems 
like neither of these things were done, and that someone has gone way 
out of their way to implement some very strange behavior.

...


Absolutely not. The current behavior was quite straightforward to 
implement, but it is wrong. Bugs often lead to strange behavior. This 
does not imply that such bugs are intentional.


What I would prefer, would be a mixture of reference and value capture 
like C++, where I could explicitly state whether I wanted (1) or (2). I 
would settle for (2) though.

...


"Like C++" does not work: in C++, each lambda has its own unique type.

While I'm sure there is _some_ reason that things currently work the way 
they do, the current behavior is very unintuitive, and gives no control 
over how things are captured.




You can work around the bug like this:

Re: OT: What causes the Segfault in the following?

2017-08-04 Thread Kagamin via Digitalmars-d-learn


On Friday, 4 August 2017 at 02:38:10 UTC, Andrew Edwards wrote:
OK, I was is indeed the problem. I was thinking for some reason 
that s gets initialized inside nk_color_hex_rgb()


Usually C functions don't allocate memory. And when they do, they 
do it in unique ways, which is a PITA, that's why the caller is 
usually responsible for memory management.

Re: delegate confusion


On 8/4/17 12:57 PM, bitwise wrote:
I'm confused about how D's lambda capture actually works, and can't find 
any clear specification on the issue. I've read the comments on the bug 
about what's described below, but I'm still confused. The conversation 
there dropped off in 2016, and the issue hasn't been fixed, despite high 
bug priority and plenty of votes.


Consider this code:

void foo() {
 void delegate()[] funs;

 foreach(i; 0..5)
 funs ~= (){ writeln(i); };

 foreach(fun; funs)
 fun();
}

void bar() {
 void delegate()[] funs;

 foreach(i; 0..5)
 {
 int j = i;
 funs ~= (){ writeln(j); };
 }
 foreach(fun; funs)
 fun();
}


void delegate() baz() {
 int i = 1234;
 return (){ writeln(i); };
}

void overwrite() {
 int i = 5;
 writeln(i);
}

int main(string[] argv)
{
 foo();
 bar();

 auto fn = baz();
 overwrite();
 fn();

 return 0;
}

First, I run `foo`. The output is "4 4 4 4 4".
So I guess `i` is captured by reference, and the second loop in `foo` 
works because the stack hasn't unwound, and `i` hasn't been overwritten, 
and `i` contains the last value that was assigned to it.


Next I run `bar`. I get the same output of "4 4 4 4 4". While this hack 
works in C#, I suppose it's reasonable to assume the D compiler would 
just reuse stack space for `j`, and that the C# compiler has some 
special logic built in to handle this.


Now, I test my conclusions above, and run `baz`, `overwrite` and `fn`. 
The result? total confusion.
The output is "5" then "1234". So if the lambdas are referencing the 
stack, why wasn't 1234 overwritten?


Take a simple C++ program for example:

int* foo() {
 int i = 1234;
 return 
}

void overwrite() {
 int i = 5;
 printf("%d\n", i);
}

int main()
{
 auto a = foo();
 overwrite();
 printf("%d\n", *a);
 return 0;
}

This outputs "5" and "5" which is exactly what I expect, because I'm 
overwriting the stack space where the first `i` was stored with "5".


So now, I'm thinking D must be storing these captures on the heap 
then..right? So why would I get "4 4 4 4 4" instead of "0 1 2 3 4" for 
`foo` and `bar`?


This makes absolutely no sense at all.


Because the stack frame of foo or bar or baz is stored on the heap 
BEFORE the function is entered. The compiler determines that the stack 
frame will need to be captured, so it captures it on function entry, not 
when the delegate is taken. Then the variable location is reused for the 
loop, and all delegates point at the same stack frame.


This is necessary for cases where the delegate may affect the frame data 
during the function call. For instance:


void foo()
{
   int i;
   auto dg = { ++i;};
   dg();
   dg();
   assert(i == 2);
}

What is needed is to allocate one frame per scope, and have the delegate 
point at the right ones.


Note, the C++ behavior uses dangling stack pointers, and not something 
we want to support in D.


-Steve

Re: dlang-requetst: openssl 1.1 compatible release

2017-08-04 Thread Jack Applegame via Digitalmars-d-announce


On Thursday, 3 August 2017 at 06:33:38 UTC, ikod wrote:

Hello,

Since version 0.5.0 dlang-requests has become compatible with 
both 1.0.x and 1.1.x versions of openssl library.


Please try and report any issues on github.
Thanks!

dlang-requests is HTTP/FTP client library, inspired by 
python-requests with goals:


small memory footprint
performance
simple, high level API
native D implementation

https://code.dlang.org/packages/requests
https://github.com/ikod/dlang-requests


Does dlang-requests support binding interface for outgoing 
connection, like curl --interface option?

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:54:44 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:36:22 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

[...]


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.
I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.


Alex


enforcing a standard on the top-level only does not really 
enforce anything.
(I really wish this would be a proper fourm, so I can bold 
things)
Call it a poor mans enforcer if you wish, that the decision 
that I decided to make.


That is not possible in D.
And I doubt it's possible with meta-classes but I might be wrong 
since I have only skimmed the paper.


To answer the question you posted a while back:
Is it to much to ask for d developers to provide a way to 
enforce custom

coding standards in a similar fashion that @nogc and @safe does?


The answer is yes. It's too much to ask of us. Since for the time 
being we lack in quality menpower.


Here is what would be needed to provide that:

1. specify a programatically accessible version of the whole AST.
2. specify a programatically accessible way to transform that AST.
3. Used the transformed ast.

Which is a lot of work it done correctly.
On top of being a feature which is highly prone to dubious uses.
And that clashes with safety guarantees D tries to provide.

delegate confusion

I'm confused about how D's lambda capture actually works, and 
can't find any clear specification on the issue. I've read the 
comments on the bug about what's described below, but I'm still 
confused. The conversation there dropped off in 2016, and the 
issue hasn't been fixed, despite high bug priority and plenty of 
votes.


Consider this code:

void foo() {
void delegate()[] funs;

foreach(i; 0..5)
funs ~= (){ writeln(i); };

foreach(fun; funs)
fun();
}

void bar() {
void delegate()[] funs;

foreach(i; 0..5)
{
int j = i;
funs ~= (){ writeln(j); };
}
foreach(fun; funs)
fun();
}


void delegate() baz() {
int i = 1234;
return (){ writeln(i); };
}

void overwrite() {
int i = 5;
writeln(i);
}

int main(string[] argv)
{
foo();
bar();

auto fn = baz();
overwrite();
fn();

return 0;
}

First, I run `foo`. The output is "4 4 4 4 4".
So I guess `i` is captured by reference, and the second loop in 
`foo` works because the stack hasn't unwound, and `i` hasn't been 
overwritten, and `i` contains the last value that was assigned to 
it.


Next I run `bar`. I get the same output of "4 4 4 4 4". While 
this hack works in C#, I suppose it's reasonable to assume the D 
compiler would just reuse stack space for `j`, and that the C# 
compiler has some special logic built in to handle this.


Now, I test my conclusions above, and run `baz`, `overwrite` and 
`fn`. The result? total confusion.
The output is "5" then "1234". So if the lambdas are referencing 
the stack, why wasn't 1234 overwritten?


Take a simple C++ program for example:

int* foo() {
int i = 1234;
return 
}

void overwrite() {
int i = 5;
printf("%d\n", i);
}

int main()
{
auto a = foo();
overwrite();
printf("%d\n", *a);
return 0;
}

This outputs "5" and "5" which is exactly what I expect, because 
I'm overwriting the stack space where the first `i` was stored 
with "5".


So now, I'm thinking D must be storing these captures on the 
heap then..right? So why would I get "4 4 4 4 4" instead of "0 1 
2 3 4" for `foo` and `bar`?


This makes absolutely no sense at all.

It seems like there are two straight forward approaches available 
here:


1) capture everything by reference, in which case the `overwrite` 
example would work just like the C++ version. Then, it would be 
up to the programmer to heap allocate anything living beyond the 
current scope.


2) heap allocate a chunk of space for each lambda's captures, and 
copy everything captured into that space when the lambda is 
constructed. This of course, would mean that `foo` and `bar` 
would both output "0 1 2 3 4".


When I look at the output I get from the code above though, it 
seems like neither of these things were done, and that someone 
has gone way out of their way to implement some very strange 
behavior.


What I would prefer, would be a mixture of reference and value 
capture like C++, where I could explicitly state whether I wanted 
(1) or (2). I would settle for (2) though.


While I'm sure there is _some_ reason that things currently work 
the way they do, the current behavior is very unintuitive, and 
gives no control over how things are captured.

Re: delegate confusion


*lambda confusion

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:36:22 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

[...]


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.
I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.


Alex


enforcing a standard on the top-level only does not really 
enforce anything.

(I really wish this would be a proper fourm, so I can bold things)
Call it a poor mans enforcer if you wish, that the decision that 
I decided to make.

Re: BigInt foreach loop

2017-08-04 Thread Stefan Koch via Digitalmars-d-learn

On Friday, 4 August 2017 at 13:09:55 UTC, Steven Schveighoffer 
wrote:



Any foreach range statement like this:

foreach(var; A .. B)

is treated as if you wrote:

for(auto var = A; var < B; ++var)

So it's pretty much exactly like what you wrote, just the 
initializer is different but the result is the same.


> as incrementing is a costly operation?

Here is increment in bigint:
https://github.com/dlang/phobos/blob/master/std/bigint.d#L563

And addOrSubInt:
https://github.com/dlang/phobos/blob/master/std/internal/math/biguintcore.d#L508

I think there is room for improvement, as incrementing or 
decrementing by 1 is probably something that can be optimized.


-Steve


Not quite,
foreach(x;A .. B)
it's lowerd to
auto limit = B;
auto key = A;
for(auto x = key;key < limit;++key)
{
 // use x
}

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:
On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy 
wrote:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper 
that I am?


It works only on declarations, like D.


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.
I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.


Alex


enforcing a standard on the top-level only does not really 
enforce anything.

Which is why Timon asked how you'd write the code.
Because you have to try doing it to see that it is indeed not 
possible to the level that is needed for those constructs.

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:32:27 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:
On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy 
wrote:

[...]


It works only on declarations, like D.


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.
I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.


Alex
I was thinking along the lines of "this and only this function 
body that you have to check"

Re: How do I do this?

2017-08-04 Thread Kagamin via Digitalmars-d

dmd has a feature that a file passed directly to the compiler 
overrides file system for module search.

reallogger/impl/pluglogger.di
---
module mylogger.logger;
public import reallogger.impl.logger;
---

main.d
---
import mylogger.logger;
...stuff
---

dmd main.d - imports mylogger/logger.d
dmd main.d reallogger/impl/pluglogger.di - uses reallogger

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:27:47 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper 
that I am?


It works only on declarations, like D.


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.
I wasn't thinking about recursive checking when I was talking 
about enforcing code standards.


Alex

Re: Who maintains the D website?


On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote:
i see you didn't hold your horses... not sure if i should reply 
again to such an angry rant. i will stay calm and focused 
though.




[...]


so i give you that. unfortunately, your long rant offers no 
other argument. however, the editing part is not a biggy. don't 
be ashamed of the little typo. everything else: i see this NG 
as some sort of public conversation. be nice, and if you got 
something wrong then heck, that's life, ppl are wrong all the 
time. own it - or are you that insecure? however, if you travel 
back in time and edit your post, you potentially break the rest 
of the conversation and ppl reading the thread later will not 
understand what the other participants responded to your post.



That why we have edit history.

Alex

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper 
that I am?


It works only on declarations, like D.


I know that, what is your point?


It means it can't be done.
Do do recursive flow-sensitive checks, (like those needed to 
enforce 'pure' or indeed '@nogc'), you'd have to write a 
self-modifying meta-program.

Which you cannot do.

Re: [OT] Generative C++

2017-08-04 Thread Kagamin via Digitalmars-d


On Friday, 4 August 2017 at 16:11:11 UTC, 12345swordy wrote:

I know that, what is your point?


this: 
https://forum.dlang.org/post/ikavudrxltlbuceea...@forum.dlang.org

Re: [OT] Generative C++


On Friday, 4 August 2017 at 16:07:51 UTC, Kagamin wrote:

On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper that 
I am?


It works only on declarations, like D.


I know that, what is your point?

Re: [OT] Generative C++

2017-08-04 Thread Steven Schveighoffer via Digitalmars-d


On Friday, 4 August 2017 at 12:47:49 UTC, Stefan Koch wrote:

On Friday, 4 August 2017 at 12:34:21 UTC, 12345swordy wrote:

[ ... ]


I can understand that you don't want to be trolled.
Many other people feel the same way.
Therefore I'd ask you to reflect on what it means to be 
trolling.


Why? I decided not to respond to him anymore, as I have stated 
before I am not interested in arguing on whatever I said or not. 
Even more so when this forum doesn't allow editing posts for 
clarification.

Re: [OT] Generative C++

2017-08-04 Thread Kagamin via Digitalmars-d


On Thursday, 3 August 2017 at 18:32:25 UTC, 12345swordy wrote:

"Enable writing
compiler-enforced
patterns for any purpose:
coding standards
(e.g., many
Core Guidelines
“enforce” rules)
"

Yes, it does, right there. Are you reading the same paper that 
I am?


It works only on declarations, like D.

Re: Fix gtkD api display

2017-08-04 Thread Gerald via Digitalmars-d-learn


On Friday, 4 August 2017 at 15:08:27 UTC, Mike Wey wrote:
Improving the documentation is something i want to do but there 
are always some more important things to do. Like the 
Questions/Issues you posted earlier.


So unless somebody volunteers it won't happen anytime soon.


Mike I had contributed the makeddox.sh script awhile ago, it 
generates much nicer documentation then candydocs in my IHMO and 
includes a nice search box. If there is something lacking in it 
that needs to be improved before it can be used let me know and 
I'll do the work.


The only issue with it that I am aware of is you need to manually 
copy the public ddox css into the generated folder. I didn't see 
an easy way to determine it's location automatically.

Re: Fix gtkD api display

2017-08-04 Thread Mike Wey via Digitalmars-d-learn


On 04-08-17 03:51, Johnson Jones wrote:

https://api.gtkd.org

It is difficult to navigate.

1. clicking the documentation on the main site takes it to the 
gtk.AboutDialog api. That is all it shows, I was confused at first, as 
I'm sure most people would be.


2. The packages list lists all the packages, but all the sub elements 
are expanded, making it time consuming to hunt down anything specific. 
Initially collapsing them and adding a search box would be nice.


3. When clicking on any packages it reloads the page and shows only the 
package in the first tab. This requires one to then go back to packages 
and hunt for something else again. Because the position of the scroll is 
not saved, one has to scroll down through the entire list.


It would be better, I think, if it was one single tab all in a single 
hierarchy that never reloaded the page so that it is easier to navigate 
quickly.


e.g.,

instead of

Package
atk
   atk.ActionIF
   atk.Action
   ...

we have

atk
   atk.ActionIF
  GetActionStruct
  GetStruct
  ...
   atk.Action
  ...
...


and so effectually combining both tabs. It should solve the issues that 
the current way has without really causing any problems. Everything 
should be collapsed by default and since no reloading of the page should 
occur(which might require having the api descriptions in a separate 
frame that is loaded separately on package changes to avoid reloading 
the tree view which will recollapse everything).


It will make navigating the gtkD api much more fun ;)


Improving the documentation is something i want to do but there are 
always some more important things to do. Like the Questions/Issues you 
posted earlier.


So unless somebody volunteers it won't happen anytime soon.

--
Mike Wey

Re: Issue with template constraints in numeric types

2017-08-04 Thread jmh530 via Digitalmars-d-learn


On Thursday, 3 August 2017 at 12:49:48 UTC, data pulverizer wrote:


Hmm ... it looks as the specialization `:` operator is working 
like the constraint `:` operator and doing convertible at least 
for the floating point case. Is that right?


They're both doing the same thing as far as I know.

Re: Fix gtkD api display

2017-08-04 Thread Adam D. Ruppe via Digitalmars-d-learn


On Friday, 4 August 2017 at 02:08:31 UTC, Johnson Jones wrote:

https://api.gtkd.org/gtkd/gtk/ApplicationWindow.html


So I ran gtkd through my doc generator too

http://dpldocs.info/experimental-docs/gtk.ApplicationWindow.ApplicationWindow.html

and I didn't make a top-level package file either... but doing 
that wouldn't be hard. However, I noticed it is basically the 
same as the official C documents: 
https://developer.gnome.org/gtk3/stable/GtkApplicationWindow.html 
so idk if it is worth spending a lot of time on it.

Re: Who maintains the D website?


On 8/4/17 6:39 AM, Johnson Jones wrote:

On Friday, 4 August 2017 at 09:13:33 UTC, Mike Parker wrote:

On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote:
i see you didn't hold your horses... not sure if i should reply again 
to such an angry rant. i will stay calm and focused though.


This guy has a history of insulting nearly everyone who responds to 
him, even those who help him, as he has just shown again in his last 
response to you. You can find more of his posts under the handles Mike 
B. Johnson and FoxyBrown. My advice to you is, if you'd like to help 
him, that's fine, but don't expect any sort of reasoned debate from 
him. Long posts in response to anything he says are a waste of your 
time. He just doesn't respond well to reason.


Way to go Mr. Professional.  You have a long way to go to grow up. You 
think your you can veil your attitude but it's clear you are not a 
professional. A real professional would simply ignore the situation...


Calm down, dude. Walk it off and come back when you are feeling more 
chipper. This is a place for fruitful discussion, not insults.


-Steve

Re: [OT] Generative C++

2017-08-04 Thread Timon Gehr via Digitalmars-d


https://www.xkcd.com/1028/
https://www.xkcd.com/1860/

Re: BigInt foreach loop

2017-08-04 Thread Steven Schveighoffer via Digitalmars-d-learn


On 8/4/17 8:49 AM, Q. Schroll wrote:

One can do
   BigInt n = returnsBigInt();
   foreach (i; BigInt(0) .. n)
   { .. }
How is this implemented? The code for BigInt is very large and I didn't 
find it.

And is it more efficient than
   for (BigInt i = 0; i < n; ++i)
   { .. }


Any foreach range statement like this:

foreach(var; A .. B)

is treated as if you wrote:

for(auto var = A; var < B; ++var)

So it's pretty much exactly like what you wrote, just the initializer is 
different but the result is the same.


> as incrementing is a costly operation?

Here is increment in bigint:
https://github.com/dlang/phobos/blob/master/std/bigint.d#L563

And addOrSubInt:
https://github.com/dlang/phobos/blob/master/std/internal/math/biguintcore.d#L508

I think there is room for improvement, as incrementing or decrementing 
by 1 is probably something that can be optimized.


-Steve

Re: BigInt foreach loop

2017-08-04 Thread Stefan Koch via Digitalmars-d-learn


On Friday, 4 August 2017 at 12:49:30 UTC, Q. Schroll wrote:

One can do
  BigInt n = returnsBigInt();
  foreach (i; BigInt(0) .. n)
  { .. }
How is this implemented? The code for BigInt is very large and 
I didn't find it.

And is it more efficient than
  for (BigInt i = 0; i < n; ++i)
  { .. }
as incrementing is a costly operation?


you can see what the code is lowerd to with -vcg-ast
The hand-written for is as effective as foreach usually.

Re: [OT] Generative C++


On Friday, 4 August 2017 at 12:34:21 UTC, 12345swordy wrote:

[ ... ]


I can understand that you don't want to be trolled.
Many other people feel the same way.
Therefore I'd ask you to reflect on what it means to be trolling.

BigInt foreach loop

2017-08-04 Thread Q. Schroll via Digitalmars-d-learn


One can do
  BigInt n = returnsBigInt();
  foreach (i; BigInt(0) .. n)
  { .. }
How is this implemented? The code for BigInt is very large and I 
didn't find it.

And is it more efficient than
  for (BigInt i = 0; i < n; ++i)
  { .. }
as incrementing is a costly operation?

Re: [OT] Generative C++


On Friday, 4 August 2017 at 00:49:05 UTC, Timon Gehr wrote:

This is in reference to your earlier:
And I have said "I am not interested in arguing about what I said 
or I didn't said" which you are literately doing right now. If 
trying to make yourself feel better by deliberating 
misrepresenting my post in order to justify your misunderstanding 
then be my guess. I am not interested having a conversation with 
you as it clear to me that you just doing this just to troll me. 
You not the first person who pull a stun like this and it 
certainly won't be the last.



Alex

Re: Who maintains the D website?


On Friday, 4 August 2017 at 09:13:33 UTC, Mike Parker wrote:

On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote:
i see you didn't hold your horses... not sure if i should 
reply again to such an angry rant. i will stay calm and 
focused though.


This guy has a history of insulting nearly everyone who 
responds to him, even those who help him, as he has just shown 
again in his last response to you. You can find more of his 
posts under the handles Mike B. Johnson and FoxyBrown. My 
advice to you is, if you'd like to help him, that's fine, but 
don't expect any sort of reasoned debate from him. Long posts 
in response to anything he says are a waste of your time. He 
just doesn't respond well to reason.


Way to go Mr. Professional.  You have a long way to go to grow 
up. You think your you can veil your attitude but it's clear you 
are not a professional. A real professional would simply ignore 
the situation...


And if you note, I only have a problems with a few people here. 
Mainly you and a one or two others... people that think they can 
write the shittiest software and how it effects others is of no 
importance. Instead of giving 100%, it's ok to give 25% and reap 
the benefits while others suffer the consequences. That attitude 
is BS and as long as you have it I will offend the fuck out of 
you all I want. If you don't like it simply ignore me, ban me(if 
you can), or do whatever you want. Until you grow up and stop 
acting like you are god I won't.


You wanna preach but you don't wanna be preached to. I can take 
your BS but you can't take mine. It's a two way street... and 
until you can captain retard get that I won't play nice.


There are plenty of people on here I respect. I'll give the top 
two: Adam Ruppe and H S Teoh. I've not seen any unprofessional 
nor condescending behavior from these guys. They don't pretend to 
know it all and don't preach their BS to others. They help the 
best they can and that is all they do... altruistic people. The 
kinda of human behavior that the world needs, not the kind that 
is destroying humanity(Which, you might not be at the bottom of 
the barrel, but your attitude is the same type that politicians, 
lawyers, and others have).


I'm sorry if you can't grow up and act like those guys... maybe 
you should take notes from them and see how they act. Maybe you 
will stop being such an ass when you don't realize it because you 
think your such an intelligent person, authority, or simply too 
much ego... whatever it is, I'll make a point of pissing you off 
every time I get until you stop behaving that way.


Your actions have consequences. The code you write has 
consequences. The "help" you give has consequences. When you stop 
dictating to other people how you *think* things should be and 
realize that it is just your opinion then we will get a long much 
better.


Until then, later asshole.

Re: How a class can know the current reference of itself?

2017-08-04 Thread Pippo via Digitalmars-d-learn


On Friday, 4 August 2017 at 09:58:34 UTC, Mike Parker wrote:


Your first error is actually this line:

callToMyFunction(ref this);

You can't use ref in a function call, only in function 
declarations. But once that's fixed, you've got other errors in 
the code you've posted -- you've declared main to return int, 
but you return nothing; you're using writefln without importing 
it.


Also, class references are *already* references, so you don't 
need to declare the function parameters as ref. Finally, 
although this is not an error, @property has no effect on 
member variables. It only applies to member functions. Also, 
you never assign a value to myProperty, so even when the errors 
are fixed nothing is printed.


Perfect. I've missed some details (return from main and import 
std.stdio for example) to expose my problem :D


My mistake was the inappropriate use of "ref".

Thank you! :)

Re: How a class can know the current reference of itself?

2017-08-04 Thread Mike Parker via Digitalmars-d-learn


On Friday, 4 August 2017 at 09:58:34 UTC, Mike Parker wrote:

Also, class references are *already* references, so you don't 
need to declare the function parameters as ref. Finally, 
although this is not an error, @property has no effect on 
member variables. It only applies to member functions. Also, 
you never assign a value to myProperty, so even when the errors 
are fixed nothing is printed.




Actually, in case I gave the wrong impression, @property can be 
applied to any function, not just member functions.

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See -
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce

But can a digital wallets/crypto currency ever be secure ?

Nope... as long as humans continue to build house of cards on
quicksand this sort of stuff will always happen. You do realize
it's all fake nonsense? If the only sort of currency that existed
was what you could immediately do with your own body, then it
would be impossible to ever steal anything(except for slavery,
which is essentially still fake).

Basically this is how the story goes: Someone comes up with some
scheme to gather resources from others. The scheme is complex and
designed in such a way that only those that have created the
scheme or invested enough time to understand the scheme benefit
from all those that don't but were to stupid not to buy in to the
scheme.

Eventually those at the top win. It's called a pyramid scheme and
it exists in all forms of currency, employment, governments, even
in most relationships, etc.

Only when all participants equally share complete responsibility
can the scheme be fair... but that never happens, too much to
gain when it becomes unbalanced... and the more unbalanced it
becomes the more those that unbalance it get.

I wouldn't doubt that most of these people who create these
currencies are the ones that ultimately are behind these thefts.
After all, they are the ones that know most about it and why else
would they spend their time developing it? For the benefit of
human kind? Yeah right! What a joke!

Re: How a class can know the current reference of itself?

2017-08-04 Thread Mike Parker via Digitalmars-d-learn


On Friday, 4 August 2017 at 09:38:59 UTC, Pippo wrote:

I'm trying to do something like this:


module mylib.classA;

class A
{
  @property string myproperty;
  void function(ref A a) callToMyFunction;

  void myfunction()
  {
callToMyFunction(ref this);
  }
}


module myapp;

import mylib.classA;

int main()
{
  A a = new A();

  a.callToMyFunction = 

  a.myfunction();
}

void myFunction(ref A a)
{
  writefln(a.myproperty);
}



but (clearly) cannot compile. How can I get the same result?

Thank you in advance.


Your first error is actually this line:

callToMyFunction(ref this);

You can't use ref in a function call, only in function 
declarations. But once that's fixed, you've got other errors in 
the code you've posted -- you've declared main to return int, but 
you return nothing; you're using writefln without importing it.


Also, class references are *already* references, so you don't 
need to declare the function parameters as ref. Finally, although 
this is not an error, @property has no effect on member 
variables. It only applies to member functions. Also, you never 
assign a value to myProperty, so even when the errors are fixed 
nothing is printed.


Here's code that compiles and works as you expect:

class A
{
  string myproperty;
  void function(A a) callToMyFunction;

  void myfunction()
  {
callToMyFunction(this);
  }
}

void main()
{
  A a = new A();

  a.callToMyFunction = 

  a.myproperty = "Hello";
  a.myfunction();
}

void myFunction(A a)
{
  import std.stdio : writefln;
  writefln(a.myproperty);
}

Although you might change it to this:

class A
{
  private string _myproperty;
  private void function(A a) callToMyFunction;

  this(string prop) { _myproperty = prop; }
  @property string myproperty() { return _myproperty; }

  void myfunction()
  {
callToMyFunction(this);
  }
}

void main()
{
  A a = new A("Hello");

  a.callToMyFunction = 

  a.myfunction();
}

void myFunction(A a)
{
  import std.stdio : writefln;
  writefln(a.myproperty);
}

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread Rene Zwanenburg via Digitalmars-d


On Friday, 4 August 2017 at 08:33:42 UTC, RazvanN wrote:

On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See - 
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce


[...]


I don't think the problem was with the blockchain here. It is 
usually a bad idea to have turing-complete scripts over 
blockchains. From what I've seen the bug was that there was 
issued a library call based on a user-provided string. That 
could have never happened if they would have used D with @safe



D's OpDispatch is very similar to what caused this bug ;)

struct Library
{
  void doSomethingUseful(){}
  void doSomethingNice(){}
  void resetSecurity(){}
}

struct BuggyContract
{
  private void customizedBehaviour(){}

  void opDispatch(string f)()
  {
if(f == "doSomethingUseful")
{
  customizedBehaviour();
}
else
{
  mixin("Library.init." ~ f ~ "();";
}
  }
}

How a class can know the current reference of itself?

2017-08-04 Thread Pippo via Digitalmars-d-learn


I'm trying to do something like this:


module mylib.classA;

class A
{
  @property string myproperty;
  void function(ref A a) callToMyFunction;

  void myfunction()
  {
callToMyFunction(ref this);
  }
}


module myapp;

import mylib.classA;

int main()
{
  A a = new A();

  a.callToMyFunction = 

  a.myfunction();
}

void myFunction(ref A a)
{
  writefln(a.myproperty);
}



but (clearly) cannot compile. How can I get the same result?

Thank you in advance.

dlang symbolic algebra library?

2017-08-04 Thread olzhas via Digitalmars-d


Hi everyone,
Can anyone advise a symbolic algebra library written in dlang?

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread Maksim Fomin via Digitalmars-d


On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote:

On 8/4/2017 1:33 AM, RazvanN wrote:
That could have never happened if they would have used D with 
@safe


That's mostly true, but not absolutely true.

1. There can be bugs in D's @safe checking and inference.

2. Function interfaces (such as in C interface files) are 
labeled @safe or not, and the D compiler has no way to check. 
Hence, functions can (and have been) mislabeled.


On the other hand, @safe does greatly reduce the attack 
surface. And as I've prognosticated before, the utter lack of 
machine checkable memory safety in C will herald the end of its 
use in anything connected to the internet.


So, you agree that @safe cannot solve the problem because of C 
function interfaces and 'lack of machine checkable memory safety 
in C'. In this case, why does @safe relies on static analysis in 
CT and type inference when memory safety is determined by the 'C 
memory sate' at RT? Either @safe is wrongly presented (it is not 
memory safety tool, but something else) or (if the intention was 
to provide memory safety tool) it is a flawed feature.


Of course, memory safety is impossible in C. In my opinion, D's 
@safe is wrongly marketed as a fully safety tool (look at a user 
above). This is dangerous, because leads to unfounded assumptions 
and later disappointment.


By the way, I see that DIP 100 followed the same way - impose 
static type restrictions in CT to prevent memory errors. I 
believe, due to growing language complexity any combination of 
resctrictions can have loopholes. Back in 2013 I was collecting 
type system holes and posted them in Bugzilla after your request. 
It appears, that scope has its own loopholes too [1].


[1] https://issues.dlang.org/show_bug.cgi?id=17718

Re: Who maintains the D website?

2017-08-04 Thread Mike Parker via Digitalmars-d


On Friday, 4 August 2017 at 06:08:04 UTC, captaindet wrote:
i see you didn't hold your horses... not sure if i should reply 
again to such an angry rant. i will stay calm and focused 
though.


This guy has a history of insulting nearly everyone who responds 
to him, even those who help him, as he has just shown again in 
his last response to you. You can find more of his posts under 
the handles Mike B. Johnson and FoxyBrown. My advice to you is, 
if you'd like to help him, that's fine, but don't expect any sort 
of reasoned debate from him. Long posts in response to anything 
he says are a waste of your time. He just doesn't respond well to 
reason.

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread Walter Bright via Digitalmars-d


On 8/4/2017 1:33 AM, RazvanN wrote:

That could have never happened if they would have used D with @safe


That's mostly true, but not absolutely true.

1. There can be bugs in D's @safe checking and inference.

2. Function interfaces (such as in C interface files) are labeled @safe or not, 
and the D compiler has no way to check. Hence, functions can (and have been) 
mislabeled.


On the other hand, @safe does greatly reduce the attack surface. And as I've 
prognosticated before, the utter lack of machine checkable memory safety in C 
will herald the end of its use in anything connected to the internet.

Re: [OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum

2017-08-04 Thread RazvanN via Digitalmars-d


On Friday, 4 August 2017 at 05:57:00 UTC, Nick B wrote:
See - 
https://medium.freecodecamp.org/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce


[...]


I don't think the problem was with the blockchain here. It is 
usually a bad idea to have turing-complete scripts over 
blockchains. From what I've seen the bug was that there was 
issued a library call based on a user-provided string. That could 
have never happened if they would have used D with @safe

Re: gtkD load images

2017-08-04 Thread Johnson Jones via Digitalmars-d-learn


On Friday, 4 August 2017 at 06:58:00 UTC, Antonio Corbi wrote:

On Thursday, 3 August 2017 at 21:06:36 UTC, Johnson Jones wrote:

[...]


Hi!

I load images using Gtk like this (I use gtk under gnu/linux):

[...]


Thanks! I'm sure it will if it works ;)

Re: Who maintains the D website?