Is there any writeln like functions without GC?
Hi: why writeln need GC?
Re: Gtkd and libgtksourceview
On Wednesday, 30 October 2019 at 22:26:41 UTC, Mike Wey wrote: On 30-10-2019 20:17, Ron Tarrant wrote: [...] Thanks. [...] The installer could use an update, Sourceview 4 is available for windows. [...] For windows there isn't an easy command to regenerate the source, but running this command should work (Its been a while since i tried it on windows): --- girtod -i src --use-runtime-linker --use-bind-dir --- Thanks a lot Mike and Ron for your help. Have a nice day
Re: Gtkd and libgtksourceview
On 30-10-2019 20:17, Ron Tarrant wrote: On Wednesday, 30 October 2019 at 18:00:24 UTC, Mike Wey wrote: GtkSourceview was updated to 4.x in GtkD version 3.9.0, so any older version should work with GtkSourceview 3. Welcome back, Mike... Thanks. The latest Windows runtime available on the GtkD downloads page installs libgtksourceview-3.0-1.dll, not the 4.0 version, so I suspect the Linux libraries may be out of step, too. The installer could use an update, Sourceview 4 is available for windows. If you need Sourceview 3 in the newer version of GtkD you could replace `file: GtkSource-4.gir` with `file: GtkSource-3.0.gir` in `src/APILookupSourceView.txt` and then run `make generate` (requires girtod) and you should have a up to date binding for Sourceview 3. Just for the record, this doesn't work on Windows. I made the change in APILookupSourceView.txt and re-ran Build.d, but sourceview/gsv/c/functions.d still shows: version (Windows) static immutable LIBRARY_GSV = ["libgtksourceview-4-0.dll"]; else version (OSX) static immutable LIBRARY_GSV = ["libgtksourceview-4.0.dylib"]; else static immutable LIBRARY_GSV = ["libgtksourceview-4.so.0"]; For windows there isn't an easy command to regenerate the source, but running this command should work (Its been a while since i tried it on windows): --- girtod -i src --use-runtime-linker --use-bind-dir --- -- Mike Wey
Re: Bug or Feature: `this` necessary to call function with template this parameter
On Wednesday, 30 October 2019 at 20:22:25 UTC, Q. Schroll wrote:
struct Example
{
private void helper(int i, this X)() { }
void funcTempl(T, this X)(T value)
{
this.helper!0();
// ^ Why do I need this?
}
}
void main()
{
auto ex = Example();
ex.funcTempl(1);
}
The question is in the comment in the code. Is that intentional
or a bug?
It's a bug - filed as
https://issues.dlang.org/show_bug.cgi?id=20341.
However, note that typeof(this) inside funcTempl() is different
from X, so that inside helper(), X will not be the same as in
funcTempl(). To fix this, you will need to pass X on to helper as
helper!(0, X). When you do this, you no longer need 'this.' in
front of the instantiation.
--
Simen
Re: Running unittests of a module with -betterC
On Wednesday, 30 October 2019 at 18:45:50 UTC, Jacob Carlborg wrote: On 2019-10-30 16:09, jmh530 wrote: I feel like this should be added into the compiler so that it just works. This will only run the unit tests in the current modules. The standard way of running the unit tests will run the unit tests in all modules. That's a fair point, but the broader point I was trying to make was that anything that makes unittests easier to use betterC code is a good thing. It seems as if there are three underlying issues here that need to be addressed to improve the usefulness of unittests in betterC code: 1) a way to gather the unittests from all modules (your point), 2) fixing -main for betterC, 3) a way to ensure that said unittests are called. The first suggests to me that it would not be such a bad thing to generate ModuleInfo when -unittest is called with -betterC or at least just the ModuleInfo needed to aggregate the unittests from different modules. This functionality might need to be opt-in. The second is pretty obvious. dmd -main -betterC is inserting a D main function instead of a C one. I submitted a bug request https://issues.dlang.org/show_bug.cgi?id=20340 as this should be pretty easy to fix. The final point depends on the two above being resolved. If dmd -unittest -main -betterC is called, then the compiler would be creating the main function so it can insert any code needed to run the unittests (assuming issue 1 above is resolved). By contrast, if just dmd -unittest -betterC is called and the user has created their own main, then it would be like having to run a shared module constructor, which is disabled in betterC. Again, I would assume that the benefits would outweigh the costs in allowing something like this on an opt-in basis, but the available options would be to either a) use -main or b) create a mixin that generates the needed unittest code so that people can insert it at the top of their main function on their own.
Bug or Feature: `this` necessary to call function with template this parameter
struct Example
{
private void helper(int i, this X)() { }
void funcTempl(T, this X)(T value)
{
this.helper!0();
// ^ Why do I need this?
}
}
void main()
{
auto ex = Example();
ex.funcTempl(1);
}
The question is in the comment in the code. Is that intentional
or a bug?
Array Vararg Template Paremeters
For a function, one can have a vararg parameter at the end like
this:
int sum(int[] ar ...) { /* code */ }
But for templates, such a declaration is an error. Is there a
specific reason why?
I know I can do it and ensure all the template parameters are
values and are convertible to the desired type. However, it's
easier to just use an array.
Re: Good way let low-skill people edit CSV files with predefined row names?
On Friday, 25 October 2019 at 21:58:27 UTC, Laeeth Isharc wrote: Another Symmetry project allows reading Excel files and a third is wrapper and bindings around a C library to write Excel files. We use them in production daily though there may be rough edges for features we don't use. I should think you can use a Javascript library and call it from D. See trading views repo by Sebastian Koppe for an example of this. Bindings are manual currently but he will work on generating them from the Typescript bindings in time. Sorry for late reply. I was told that I can do this by writing the key field only as a comment (so changing it will do no harm - the real key would be dictated either by an ID number or simply row index). In the case they want me to do it without writing my own GUI, I'm going to consider the DUB solutions first but look at what you said if I still miss something. Thank you.
Re: Gtkd and libgtksourceview
On Wednesday, 30 October 2019 at 18:00:24 UTC, Mike Wey wrote: GtkSourceview was updated to 4.x in GtkD version 3.9.0, so any older version should work with GtkSourceview 3. Welcome back, Mike... The latest Windows runtime available on the GtkD downloads page installs libgtksourceview-3.0-1.dll, not the 4.0 version, so I suspect the Linux libraries may be out of step, too. If you need Sourceview 3 in the newer version of GtkD you could replace `file: GtkSource-4.gir` with `file: GtkSource-3.0.gir` in `src/APILookupSourceView.txt` and then run `make generate` (requires girtod) and you should have a up to date binding for Sourceview 3. Just for the record, this doesn't work on Windows. I made the change in APILookupSourceView.txt and re-ran Build.d, but sourceview/gsv/c/functions.d still shows: version (Windows) static immutable LIBRARY_GSV = ["libgtksourceview-4-0.dll"]; else version (OSX) static immutable LIBRARY_GSV = ["libgtksourceview-4.0.dylib"]; else static immutable LIBRARY_GSV = ["libgtksourceview-4.so.0"];
Re: Help playing sounds using arsd.simpleaudio
On Saturday, 26 October 2019 at 19:48:33 UTC, Murilo wrote: I play a sound the program never ends, the terminal continues to run the program and I have to end it manually. Any ideas what could be causing this? I am using it just as you had instructed. That happens if you don't call .stop() and .join() in order at the right time. Did you use the scope(exit) like I said?
Stream-based on-the-fly-download-and-decompress parsing of files
Has anybody put together a File-compatible web-download API? Mu goal is to do have it do 1. stream-based download (via http or https), 2. compress (with gzip or bzip2) and 3. textual parse of resources available either on the web or locally cached. An extra bonus would be if the API provided a `std.stdio.File` based API so that I can make use of my very speedy D-module zio at https://github.com/nordlow/phobos-next/blob/331235b048de273a12e711321548782b33d1fb74/src/zio.d
Re: Running unittests of a module with -betterC
On 2019-10-30 16:09, jmh530 wrote: I feel like this should be added into the compiler so that it just works. This will only run the unit tests in the current modules. The standard way of running the unit tests will run the unit tests in all modules. -- /Jacob Carlborg
Re: Gtkd and libgtksourceview
On 30-10-2019 15:48, bioinfornatics wrote: Dear, I tried the latest gtkd release and it try to open dynamically libgtksourceview-4.so.0 however I have only libgtksourceview-3.so.1 so which version should I used to be compatible with libgtksourceview-3 (I use centos 7) GtkSourceview was updated to 4.x in GtkD version 3.9.0, so any older version should work with GtkSourceview 3. If you need Sourceview 3 in the newer version of GtkD you could replace `file: GtkSource-4.gir` with `file: GtkSource-3.0.gir` in `src/APILookupSourceView.txt` and then run `make generate` (requires girtod) and you should have a up to date binding for Sourceview 3. -- Mike Wey
Re: Gtkd and libgtksourceview
On Wednesday, 30 October 2019 at 14:48:23 UTC, bioinfornatics wrote: so which version should I used to be compatible with libgtksourceview-3 (I use centos 7) When Mike Wey gets back in town (any day now) he should be able to provide a solution that's less of a kludge.
Re: Gtkd and libgtksourceview
On Wednesday, 30 October 2019 at 14:48:23 UTC, bioinfornatics wrote: I tried the latest gtkd release and it try to open dynamically libgtksourceview-4.so.0 however I have only libgtksourceview-3.so.1 On Windows, I had to change a line in C:\D\dmd2\src\sourceview\gsv\c\functions.d from: static immutable LIBRARY_GSV = ["libgtksourceview-4.0.dll"]; to: static immutable LIBRARY_GSV = ["libgtksourceview-3.0-1.dll"]; Assuming the sourceview/gsv/c/functions.d exists on Linux as well, a similar change should help. However, you will also, very likely, have to look for a folder in generated/ called: "sourceview" and copy it and its contents to: dmd2/src/ And I have no idea where you'll find the dmd2/src/ folder on Linux. But, assuming you can find it, this may get you up and running. Let me know how it goes.
Re: Running unittests of a module with -betterC
On Wednesday, 30 October 2019 at 15:09:40 UTC, jmh530 wrote: [snip] I feel like this should be added into the compiler so that it just works. Hmm, maybe only when compiled with -main, but I don't think there's a version for that.
Re: Accuracy of floating point calculations
On Wed, Oct 30, 2019 at 09:03:49AM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > On 2019-10-29 17:43:47 +, H. S. Teoh said: > > > On Tue, Oct 29, 2019 at 04:54:23PM +, ixid via Digitalmars-d-learn > > wrote: > > > On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote: > > > > On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak wrote: > > > > > > > > AFAIK dmd use real for floating point operations instead of > > > > double > > > > > > Given x87 is deprecated and has been recommended against since > > > 2003 at the latest it's hard to understand why this could be seen > > > as a good idea. > > > > Walter talked about this recently as one of the "misses" in D (one > > of the things he predicted wrongly when he designed it). > > Why should the real type be a wrong decision? Maybe the code > generation should be optimized if all terms are double to avoid x87 > but overall more precision is better for some use-cases. It wasn't a wrong *decision* per se, but a wrong *prediction* of where the industry would be headed. Walter was expecting that people would move towards higher precision, but what with SSE2 and other such trends, and the general neglect of x87 in hardware developments, it appears that people have been moving towards 64-bit doubles rather than 80-bit extended. Though TBH, my opinion is that it's not so much neglecting higher precision, but a general sentiment of the recent years towards standardization, i.e., to be IEEE-compliant (64-bit floating point) rather than work with a non-standard format (80-bit x87 reals). I also would prefer to have higher precision, but it would be nicer if that higher precision was a standard format with guaranteed semantics that isn't dependent upon a single vendor or implementation. > I'm very happpy it exists, and x87 too because our app really needs > this extended precision. I'm not sure what we would do if we only had > doubles. > > I'm not aware of any 128 bit real implementations done using SIMD > instructions which get good speed. Anyone? [...] Do you mean *simulated* 128-bit reals (e.g. with a pair of 64-bit doubles), or do you mean actual IEEE 128-bit reals? 'cos the two are different, semantically. I'm still longing for 128-bit reals (i.e., actual IEEE 128-bit format) to show up in x86, but I'm not holding my breath. In the meantime, I've been looking into arbitrary-precision float libraries like libgmp instead. It's software-simulated, and therefore slower, but for certain applications where I want very high precision, it's the currently the only option. T -- If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell
Re: Running unittests of a module with -betterC
On Tuesday, 29 October 2019 at 08:45:15 UTC, mipri wrote:
[snip]
-unittest sets the 'unittest' version identifier. So this works:
unittest {
assert(0);
}
version(unittest) {
extern(C) void main() {
static foreach(u; __traits(getUnitTests,
__traits(parent, main)))
u();
}
}
dmd -betterC -unittest -run module.d
I feel like this should be added into the compiler so that it
just works.
Gtkd and libgtksourceview
Dear, I tried the latest gtkd release and it try to open dynamically libgtksourceview-4.so.0 however I have only libgtksourceview-3.so.1 so which version should I used to be compatible with libgtksourceview-3 (I use centos 7) Code: $ ldc2 container_014_10_notebook_basic.d -I=$LDC2_ROOT/include/d/gtkd-3 -L=-lgtk-3 -L=-latk-1.0 -L=-lgtkd-3 -L=-lgtkdgl-3 -L=-lgtkdsv-3 -of container $ ./container object.Exception@generated/gtkd/gtkd/Loader.d(125): Library load failed (libgtksourceview-4.so.0): libgtksourceview-4.so.0: cannot open shared object file: No such file or directory Illegal instruction (core dumped)
PyD: Hello World program do not compile.
Hi, for those who do not know this is the github repository for the PyD I am using: https://github.com/ariovistus/pyd I just stared with PyD and I am trying to make it work. I have downloaded the latest release version and unzipped it in my working directory. Also I copied the two files from the documentation (the kind of "hello world" program). I am using windows 10 and python 2.7.12 so I run the command python .\setup.py pydexe but I get the following error: travis_fold:end:pyd_compile-dcaf5080-fb16-11e9-84a3-f859714c6a61 Traceback (most recent call last): File ".\setup.py", line 10, in build_deimos=True, d_lump=True File "C:\Users\PapaniGe\Desktop\learning\project earth\pydtest\pyd\support.py", line 230, in setup base_setup(*args, **kwargs) File "C:\Users\PapaniGe\AppData\Local\Continuum\Anaconda2\lib\distutils\core.py", line 151, in setup dist.run_commands() File "C:\Users\PapaniGe\AppData\Local\Continuum\Anaconda2\lib\distutils\dist.py", line 953, in run_commands self.run_command(cmd) File "C:\Users\PapaniGe\AppData\Local\Continuum\Anaconda2\lib\distutils\dist.py", line 972, in run_command cmd_obj.run() File "C:\Users\PapaniGe\Desktop\learning\project earth\pydtest\pyd\support.py", line 128, in run self.per_ext(ext) File "C:\Users\PapaniGe\Desktop\learning\project earth\pydtest\pyd\support.py", line 169, in per_ext target_lang=language) File "C:\Users\PapaniGe\AppData\Local\Continuum\Anaconda2\lib\distutils\ccompiler.py", line 700, in link_executable debug, extra_preargs, extra_postargs, None, target_lang) File "C:\Users\PapaniGe\Desktop\learning\project earth\pydtest\pyd\dcompiler.py", line 750, in link return DCompiler.link(self, *args, **kwargs) File "C:\Users\PapaniGe\Desktop\learning\project earth\pydtest\pyd\dcompiler.py", line 520, in link library_dirs = list(set(_build_ext_library_dirs() + library_dirs)) TypeError: unsupported operand type(s) for +: 'NoneType' and 'list' It appears that it tries to add two lists but the one is empty, so it breaks. Any thoughts?
Re: Read Once then reset/init value?
On Wednesday, 30 October 2019 at 11:53:42 UTC, Jacob Carlborg
wrote:
On 2019-10-30 00:28, Simen Kjærås wrote:
Something like this?
T readOnce(T)(ref T value) {
auto tmp = value;
value = T.init;
return tmp;
} unittest {
int i = 3;
assert(i.readOnce == 3);
assert(i == 0);
}
Perhaps better to encapsulate it in a struct to avoid someone
accessing the value directly.
Quite possibly, but the post was somewhat low on details, and
encapsulating it like that does put certain limits on how it can
be used, so it's not necessarily the best idea.
FWIW, here's one possible way to do it with a struct:
struct Readonce(T, T defaultValue = T.init) {
private T value;
alias get this;
T get() {
auto tmp = value;
value = defaultValue;
return tmp;
}
void get(T newValue) {
value = newValue;
}
this(T newValue) {
value = newValue;
}
}
unittest {
Readonce!(int, -1) a = 3;
assert(a == 3);
assert(a == -1);
a = 3;
assert(a == 3);
assert(a == -1);
}
--
Simen
Re: Read Once then reset/init value?
On 2019-10-30 00:28, Simen Kjærås wrote:
Something like this?
T readOnce(T)(ref T value) {
auto tmp = value;
value = T.init;
return tmp;
} unittest {
int i = 3;
assert(i.readOnce == 3);
assert(i == 0);
}
Perhaps better to encapsulate it in a struct to avoid someone accessing
the value directly.
--
/Jacob Carlborg
Re: Accuracy of floating point calculations
On Tuesday, 29 October 2019 at 20:15:13 UTC, kinke wrote: Note that there's at least one bugzilla for these float/double math overloads already. For a start, one could simply wrap the corresponding C functions. I guess, that this issue: https://issues.dlang.org/show_bug.cgi?id=20206 boils down to the same problem. I allready found out, that it's high likely that the bug is not to be found inside std.complex but probably the log function.
Re: Accuracy of floating point calculations
On 2019-10-29 17:43:47 +, H. S. Teoh said: On Tue, Oct 29, 2019 at 04:54:23PM +, ixid via Digitalmars-d-learn wrote: On Tuesday, 29 October 2019 at 16:11:45 UTC, Daniel Kozak wrote: On Tue, Oct 29, 2019 at 5:09 PM Daniel Kozak wrote: AFAIK dmd use real for floating point operations instead of double Given x87 is deprecated and has been recommended against since 2003 at the latest it's hard to understand why this could be seen as a good idea. Walter talked about this recently as one of the "misses" in D (one of the things he predicted wrongly when he designed it). Why should the real type be a wrong decision? Maybe the code generation should be optimized if all terms are double to avoid x87 but overall more precision is better for some use-cases. I'm very happpy it exists, and x87 too because our app really needs this extended precision. I'm not sure what we would do if we only had doubles. I'm not aware of any 128 bit real implementations done using SIMD instructions which get good speed. Anyone? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
