Re: Why is sformat and formattedWrite (appender) allocating GC mem here?

[Mike Parker via Digitalmars-d-learn]

On Saturday, 31 August 2019 at 12:07:56 UTC, cc wrote:

And what, if anything, can I do to avoid it?


import core.stdc.stdio : printf;

There are no @nogc versions of the Phobos write* and format 
functions.

Why is sformat and formattedWrite (appender) allocating GC mem here?

[cc via Digitalmars-d-learn]

And what, if anything, can I do to avoid it?

string[] arr = ["abcd", "efgh", "ijkl"];
char[4096] buf;
char[] res;
writeln(GC.stats);
res = sformat(buf, "%s", arr);
assert(res.ptr == buf.ptr);
writeln(res);
writeln(GC.stats);
res = sformat(buf, "%s", arr);
assert(res.ptr == buf.ptr);
writeln(res);
writeln(GC.stats);

// Results:
Stats(64, 1048512, 80)
["abcd", "efgh", "ijkl"]
Stats(272, 1048304, 272)
["abcd", "efgh", "ijkl"]
Stats(464, 1048112, 464)

I get similar behavior trying to use formattedWrite with an 
appender:


string[] arr = ["abcd", "efgh", "ijkl"];
auto formatBuffer = appender!(char[])();
formatBuffer.reserve(4096);
formatBuffer.clear();
writeln(GC.stats);
formatBuffer.formattedWrite!"%s"(arr);
writeln(formatBuffer.data);
writeln(GC.stats);
formatBuffer.clear();
formatBuffer.formattedWrite!"%s"(arr);
writeln(formatBuffer.data);
writeln(GC.stats);

// Results:
Stats(12288, 5230592, 4208)
["abcd", "efgh", "ijkl"]
Stats(12432, 5230448, 4352)
["abcd", "efgh", "ijkl"]
Stats(12576, 5230304, 4496)

Same thing if I use a format string like "%(%s,%)" rather than 
just "%s".  I'm guessing it's allocating a string first to write 
the contents of the array and then inserting that string into the 
buffer I supplied.  Is there no way to have it skip this step and 
just write each element (plus the joining punctuation, etc) 
directly into the buffer?

Re: Java to D

[Patrick via Digitalmars-d-learn]

On Wednesday, 28 August 2019 at 10:33:33 UTC, GreatSam4sure wrote:
On Wednesday, 28 August 2019 at 09:35:55 UTC, Jacob Carlborg 
wrote:

On 2019-08-28 10:14, GreatSam4sure wrote:

[...]


DWT is ported manually from Java. Here's a very short guide 
[1]. That guide is probably written for D1.



[...]


I'm working on a tool do be able to automatically convert Java 
code to D code [2]. It's been a while since I did any actual 
work on that project. As far as I can remember, it can do a 
syntactic translation of most Java code. What's remaining is 
the semantic translation.


[1] http://dsource.org/projects/dwt/wiki/Porting
[2] https://github.com/d-widget-toolkit/jport/tree/dev



Thanks i will check it up


Take a look at JavacTo  https://sourceforge.net/projects/javacto/

This is a java tool that uses the javac compiler to translate 
java to another language.  And includes a java to D code set.


It is a very visual tool and has great animation during 
translation and works well while using the java debugger. I 
include “How to get started with Eclipse”.


You can find more translations statistics at this post: 
https://forum.dlang.org/thread/yuamvgsdfshgrbesm...@forum.dlang.org#post-yuamvgsdfshgrbesmjlt:40forum.dlang.org


Hope this helps

Patrick

Re: Java to D

[Ernesto Castellotti via Digitalmars-d-learn]

On Wednesday, 28 August 2019 at 08:14:25 UTC, GreatSam4sure wrote:

Good day everyone.

DWT is a library for creating cross-platform GUI applications. 
It's a port of the SWT Java library from Eclipse. Currently 
supported platforms are Windows, using Win32 and Linux, using 
GTK.


[...]


Perhaps this tool could be useful 
https://github.com/jtransc/jtransc

Re: Why is sformat and formattedWrite (appender) allocating GC mem here?

[Nicholas Wilson via Digitalmars-d-learn]

On Saturday, 31 August 2019 at 21:12:32 UTC, ag0aep6g wrote:

I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163


Merged.

Re: Why is sformat and formattedWrite (appender) allocating GC mem here?

[ag0aep6g via Digitalmars-d-learn]

On 31.08.19 14:07, cc wrote:
I'm guessing it's allocating a string first to write the contents 
of the array and then inserting that string into the buffer I supplied.  
Is there no way to have it skip this step and just write each element 
(plus the joining punctuation, etc) directly into the buffer?


`formatElement` does something like that. It writes the string into a 
temporary buffer while looking for invalid Unicode. When it finds some, 
the temporary is discarded and the whole string is formatted 
differently. When the string is a-ok, the data is copied over to the 
actual destination.


I'm not sure if that's the best approach, though. The temporary buffer 
and the string copy are costly.


There is also a closure being allocated for no reason in `sformat` 
itself. The compiler isn't smart enough to see that it's not really needed.


I've made a pull request to get rid of those allocations:
https://github.com/dlang/phobos/pull/7163