Re: How to create meson.build with external libs?
On Sunday, 12 January 2020 at 22:20:16 UTC, p.shkadzko wrote: Why do you think 1 is the better way? Well, I suppose I might be a bit biased being a distro packager, but not using dub ensures your package builds properly with what your distro uses (e.g. pkg-config). It _is_ more effort up front though, yes. Also, I feel like using a more standardized way of packaging via meson with pkg-config is better (and as a distro packager I would refrain from packaging something which uses a dub dependency instead of a (shared) pkg-config one). I feel like it is a lot of manual work for just one dependency. Also, it is not a good idea to pollute your /usr/local with non-distro packages. Well, the only purpose of /usr/local is for you to put your non-distro stuff there, /usr is the package manager's territory :)
Re: How to create meson.build with external libs?
On Sunday, 12 January 2020 at 22:12:14 UTC, Rasmus Thomsen wrote: On Sunday, 12 January 2020 at 22:00:33 UTC, p.shkadzko wrote: [...] In difference to dub, meson will _not_ auto-download required software for you. You have to ways to go forward with this: [...] Thanks! I shall try it out.
Re: How to create meson.build with external libs?
On Sunday, 12 January 2020 at 22:12:14 UTC, Rasmus Thomsen wrote: On Sunday, 12 January 2020 at 22:00:33 UTC, p.shkadzko wrote: What do I need to do in order to build the project with "lubeck" dependency in meson? In difference to dub, meson will _not_ auto-download required software for you. You have to ways to go forward with this: 1 (IMHO the better way, especially if you ever want a distro to package your thing): Install lubeck ala `git clone https://github.com/kaleidicassociates/lubeck && cd lubeck && meson build && ninja -C build install`. This will install lubeck to your system (by default into `/usr/local`, you can set a different by passing `--prefix` to meson). This will generate a so called pkg-config (`.pc`) file: https://github.com/kaleidicassociates/lubeck/blob/master/meson.build#L49 which meson will discover. 2 (The probably easier way in the short term): Install lubeck via meson, then discover the dependency like specified here: https://mesonbuild.com/Dependencies.html#dependency-method Why do you think 1 is the better way? I feel like it is a lot of manual work for just one dependency. Also, it is not a good idea to pollute your /usr/local with non-distro packages.
Re: How to create meson.build with external libs?
On Sunday, 12 January 2020 at 22:00:33 UTC, p.shkadzko wrote: What do I need to do in order to build the project with "lubeck" dependency in meson? In difference to dub, meson will _not_ auto-download required software for you. You have to ways to go forward with this: 1 (IMHO the better way, especially if you ever want a distro to package your thing): Install lubeck ala `git clone https://github.com/kaleidicassociates/lubeck && cd lubeck && meson build && ninja -C build install`. This will install lubeck to your system (by default into `/usr/local`, you can set a different by passing `--prefix` to meson). This will generate a so called pkg-config (`.pc`) file: https://github.com/kaleidicassociates/lubeck/blob/master/meson.build#L49 which meson will discover. 2 (The probably easier way in the short term): Install lubeck via meson, then discover the dependency like specified here: https://mesonbuild.com/Dependencies.html#dependency-method
How to create meson.build with external libs?
Ok, I am trying to meson and is struggling with meson.build file.
I looked up the examples page:
https://github.com/mesonbuild/meson/tree/master/test%20cases/d
which has a lot of examples but not the one that shows you how to
build your project with some external dependency :)
Let's say we have a simple dir "myproj" with "meson.build" in it
and some source files like "app.d" and "helper_functions.d".
~/myproj
app.d
helper_functions.d
meson.build
"helper_functions.d" uses let's say lubeck library which
according to
https://forum.dlang.org/thread/nghoprwkihazjikyh...@forum.dlang.org is supported by meson.
Here is my meson.build:
---
project('demo', 'd',
version : '0.1',
default_options : ['warning_level=3']
)
lubeck = dependency('lubeck', version: '>=1.1.7')
ed = executable('mir_quickstart', 'app.d', dependencies: lubeck,
install : true)
However, when I try to build it I get the following error:
-
$ meson build
The Meson build system
Version: 0.52.1
Source dir: /home/user/dev/github/demo
Build dir: /home/user/dev/github/demo/build
Build type: native build
Project name: demo
Project version: 0.1
D compiler for the host machine: ldc2 (llvm 1.18.0 "LDC - the
LLVM D compiler (1.18.0):")
D linker for the host machine: GNU ld.gold 2.33.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (1.6.3)
Found CMake: /usr/bin/cmake (3.16.2)
Run-time dependency lubeck found: NO (tried pkgconfig and cmake)
meson.build:8:0: ERROR: Dependency "lubeck" not found, tried
pkgconfig and cmake
A full log can be found at
/home/user/dev/github/demo/build/meson-l
-
What do I need to do in order to build the project with "lubeck"
dependency in meson?
Re: Invalid memory operation during allocation with `new`
On Sunday, 12 January 2020 at 15:21:05 UTC, Per Nordlöw wrote: - in the short run, Qualifying all user-defined class destructors with `@nogc`? - in the long run, Making DMD forbid GC-allocations transitively inside class destructors? The class doesn't necessarily know what its destructor is going to be used for, nor does as struct. So such static checks would end problematic; limiting to some legit cases and not catching some problem cases (because destructors are called with child classes to). The most recent release added a runtime function you can test though: https://dlang.org/phobos/core_memory.html#.GC.inFinalizer so if that is true, avoid doing the call. Of course that doesn't help the case when you don't know the rule and don't even think to call it...
Re: Invalid memory operation during allocation with `new`
On Sunday, 12 January 2020 at 15:21:05 UTC, Per Nordlöw wrote: Thanks. So what about, - in the short run, Qualifying all user-defined class destructors with `@nogc`? - in the long run, Making DMD forbid GC-allocations transitively inside class destructors? AFAICT, these rules should in most cases hold also for struct destructors as those might be called inside class destructors, transitively.
Re: Invalid memory operation during allocation with `new`
On Sunday, 12 January 2020 at 13:58:25 UTC, Adam D. Ruppe wrote: Check all the classes created by those unittests. If any of them have destructors that allocate memory in any way - including calling like `writeln(this)` cuz that can call toString, change that. Thanks. So what about, - in the short run, Qualifying all user-defined class destructors with `@nogc`? - in the long run, Making DMD forbid GC-allocations transitively inside class destructors?
Re: Invalid memory operation during allocation with `new`
On Sunday, 12 January 2020 at 13:39:42 UTC, Per Nordlöw wrote: core.exception.InvalidMemoryOperationError@src/core/exception.d(647): Invalid memory operation That means a destructor tried to perform a GC operation while the GC was running. The crash happens only if the `unittests` are run prior to `main`. Check all the classes created by those unittests. If any of them have destructors that allocate memory in any way - including calling like `writeln(this)` cuz that can call toString, change that.
Get memory used by current process at specific point in time
Is there a druntime/phobos function for getting the amount of memory (both, stack, malloc, and GC) being used by the current process?
Invalid memory operation during allocation with `new`
My application has suddendly started crashing as core.exception.InvalidMemoryOperationError@src/core/exception.d(647): Invalid memory operation during a plain allocation with `new` during execution of `main`. The crash happens only if the `unittests` are run prior to `main`. The crash goes away when I disable at least on the `unittest`s run before `main`. I'm compiling with DMD version 2.090. How do I check the amount of memory currently being used in a process? If the amount of memory used is not the problem, how can I find the reason for this?
Re: Compilation error: undefined reference to 'cblas_dgemv' / 'cblas_dger' / 'cblas_dgemm'
On Saturday, 11 January 2020 at 16:45:22 UTC, p.shkadzko wrote: I am trying to run example code from https://tour.dlang.org/tour/en/dub/lubeck ... This is Linux Manjaro with openblas package installed. The Lubeck library depends on CBLAS, but the openblas package in the Arch repository is compiled without CBLAS. You can see that here (note the NO_CBLAS=1 parameter): https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/openblas Try installing the cblas package: https://www.archlinux.org/packages/extra/x86_64/cblas/
Re: Win32 Api: How create Open/"Save as" Dialog?
On Saturday, 11 January 2020 at 14:21:25 UTC, Adam D. Ruppe wrote:
On Saturday, 11 January 2020 at 12:22:25 UTC, Marcone wrote:
wchar[1024] szFileName = 0;
ofn.lpstrFile = cast(LPWSTR) szFileName;
You shouldn't cast there, just use `szFileName.ptr` instead.
ofn.nMaxFile = MAX_PATH;
and this should be the length of the array. It may require a
case
nMaxFile = cast(DWORD) szFileName.length;
Changed! New code with changes working very well:
import std;
import core.sys.windows.windows;
pragma(lib, "comdlg32");
// Function askopenfilename()
string askopenfilename(const(wchar)* filter = "All Files
(*.*)\0*.*\0"){
OPENFILENAME ofn;
wchar[1024] szFileName = 0;
ofn.lpstrFile = szFileName.ptr;
ofn.lpstrFilter = filter;
ofn.nMaxFile = cast(DWORD) szFileName.length;
ofn.Flags = OFN_EXPLORER | OFN_FILEMUSTEXIST |
OFN_HIDEREADONLY;
if (GetOpenFileNameW()){
return to!string(szFileName[0..szFileName.indexOf('\0')]);
} else {
return "";
}
}
void main(){
writeln(askopenfilename()); // Call without filter.
writeln(askopenfilename("Text Files (*.txt)\0*.txt\0All Files
(*.*)\0*.*\0")); // Cal using filter.
}
