Re: PyD - accessing D class fields in Python
On Monday, 18 March 2019 at 22:25:10 UTC, clothlen wrote:
Howdy;
I'm trying to extend my Python program with D, but I'm having
trouble accessing a D class's
field/attribute/property/something.
My D file looks like this:
```
module simpletest;
import pyd.pyd;
import std.stdio;
class ExampleTest{
int _a = 3;
int a(){
return _a;
}
void a(int a){
this._a = a;
}
int b = 4;
}
extern(C) void PydMain() {
module_init();
wrap_class!(
ExampleTest,
Property!(ExampleTest.a),
Property!(ExampleTest.b)
// Member!("b")
Maybe you need `Member!(“b”, “rw”)`?
);
}
If that doesn’t work, maybe you find help by filing an issue on
PyD.
Re: Compile-time associative array
On 3/19/19 7:22 PM, Bastiaan Veelo wrote: Beware that a CT AA stores its elements in a different order than a RT AA, which you would notice in a foreach, for example. Yes, this is the issue -- the runtime AA depends on druntime, which is not available to the compiler. The compiler has its own AA implementation that it uses for CTFE. The internals will not be the same, which is why you can't construct one at compile-time and use it at runtime (the enum just recreates it at runtime when used). -Steve
Re: Compile-time associative array
On Tuesday, 19 March 2019 at 08:50:15 UTC, boolangery wrote:
Hi,
I want to use a constant associative array in a ctfe-able
function.
Example:
string ctfeableFunction()
{
return Foo["foo"];
}
Then I force ctfe with:
enum res = ctfeableFunction();
When I use an enum like:
enum Foo = ["foo" : "bar"];
It works fine.
D-Scanner keep saying to me: This enum may lead to unnecessary
allocation at run-time. Use 'static immutable [...] instead'
But it lead to: Error: static variable Foo cannot be read at
compile time.
So is the only way to make ctfe-able associative array is to
use enum instead of static immutable ?
Yes, I think so. If you would use the enum AA multiple times, it
would allocate a new AA each time, that is wat D-Scanner warns
against. I am not sure how the CTFE interpreter is implemented,
it could be that a new AA is allocated each time you call
ctfeableFunction, at compile time. But unless you also call it at
runtime, there should be no extra run time allocations.
If you need the AA at run time as well, I would create a static
immutable version for that, initialised with the enum.
Beware that a CT AA stores its elements in a different order than
a RT AA, which you would notice in a foreach, for example.
Re: Emulating DLL
On Tuesday, 19 March 2019 at 09:18:56 UTC, Kagamin wrote: There was this old project: http://dsource.org/projects/ddl/ Seems it is too heavily dependent on mago and has a lot of depreciated content. Probably not worth trying to update. Probably much easier just to hack dmd to export a simpler dll format or use dll's directly.
Re: build 32-bit library on 64-bit OS
On Tuesday, 19 March 2019 at 20:56:47 UTC, DFTW wrote: What package did you mean? that libphobos2 on the error messages from the ld? I'm using dmd/dub on Ubuntu 18. libphobos2-ldc-shared.so is definitely from LDC. I'll give a try to ldc, does it still is binary compatible with C? It's better suited for C(++) interop than DMD (ABI issues).
Re: build 32-bit library on 64-bit OS
On Tuesday, 19 March 2019 at 20:31:46 UTC, kinke wrote: On Tuesday, 19 March 2019 at 17:23:21 UTC, DFTW wrote: /usr/bin/ld: skiping //usr/lib/x86_64-linux-gnu/libphobos2-ldc-shared.so incompatible to -lphobos2-ldc-shared /usr/bin/ld: couldn't find -lphobos2-ldc-shared If possible, use an official package (https://github.com/ldc-developers/ldc/releases). What distro are you using? The packager apparently didn't create a multilib package. What package did you mean? that libphobos2 on the error messages from the ld? I'm using dmd/dub on Ubuntu 18. I'll give a try to ldc, does it still is binary compatible with C?
Re: build 32-bit library on 64-bit OS
On Tuesday, 19 March 2019 at 17:23:21 UTC, DFTW wrote: /usr/bin/ld: skiping //usr/lib/x86_64-linux-gnu/libphobos2-ldc-shared.so incompatible to -lphobos2-ldc-shared /usr/bin/ld: couldn't find -lphobos2-ldc-shared If possible, use an official package (https://github.com/ldc-developers/ldc/releases). What distro are you using? The packager apparently didn't create a multilib package.
Re: gtkD: How to paint to screen for animation
On Tuesday, 19 March 2019 at 19:03:37 UTC, Mike Wey wrote: On 19-03-2019 01:54, Michelle Long wrote: I've added a function to addOnDraw for a DrawingArea and it paints using the code I have when I resize. I added a queueDraw in threadsAddIdle and it seems to draws the screen immediately but it does not seem to be called again. If I put queueDraw inside the addOnDraw routine then the animation works but it is quite slow, about 1 fps and cpu usage is 100% without it, it is 0%. You will probably want to use glib.Timeout to make the time between redraws consistent. The callBack for treadsAddIdle or glib.Idle is only called when the mainloop has nothing else to do. The cairo clock demo is a good example: https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d If performance is an issue one option would be to save your context in a cairo surface and only redraw the parts that have changed. I will try the clock code and see if threading it will help though. Just not sure if it's limited by cario or the thread. It seems that blitting the image is not the slow down because I removed the code and it still is slow, so it seems like it is a thread. setSourcePixbuf(buf, 0,0); paint(); Thanks.
Re: Emulating DLL
On Monday, 18 March 2019 at 22:59:12 UTC, Ethan Watson wrote: On Monday, 18 March 2019 at 22:50:57 UTC, Craig wrote: Is it possible to create a D module that has functions in it, and then use those functions dynamically at run time emulating DLL like functionality? On Monday, 18 March 2019 at 22:50:57 UTC, Craig wrote: Is it possible to create a D module that has functions in it, and then use those functions dynamically at run time emulating DLL like functionality? I've talked extensively on this topic at DConf over the last few years. http://dconf.org/2016/talks/watson.html http://dconf.org/2017/talks/watson.html http://dconf.org/2018/talks/watson.html https://github.com/GooberMan/binderoo It's not a simple thing by any means, there's plenty of little implementation details that you'll need to be aware of. But yes, it's quite possible. This seems overly complex for what I want and not exactly what I need. I'm looking for simply that simply lets me call functions that exist in an external dynamically accessible file. In my host code I will use a function like "foo" but that foo will be a function pointer that can point to the external code. I don't need a bunch of bells and whistles or complex ways to accomplish this. 1. Load up external code, 2. Fixup whatever needs fixing up to make the code work properly 3. Point function pointer to code. 4. Call. For simple functions such as pure functions step 2 can be skipped and hence it is essentially just loading the code in to memory and calling it. I do get that in general it is more complex but other than relocatable code, initialization, and the GC, it shouldn't require much more work. For example, with windows I could simply compile to a dll then extract the code, or just use LoadLibrary and it effectively does all the work(steps 1 & 2 & 3). LoadLibrary is not portable though and seems excessive to do something that should be rather simple unless there is something I'm missing that has to be done that is complex. Relocation is easy if one has the appropriate locations to fix up which are generally included in the binary somewhere. The GC and rt can be initialized easily.
Re: Emulating DLL
On Tuesday, 19 March 2019 at 09:18:56 UTC, Kagamin wrote: There was this old project: http://dsource.org/projects/ddl/ Thanks, looks pretty similar to what I was thinking. I'll have to mess with it a bit but maybe I can tweak any issues to suit my agenda.
Re: gtkD: How to paint to screen for animation
On 19-03-2019 01:54, Michelle Long wrote: I've added a function to addOnDraw for a DrawingArea and it paints using the code I have when I resize. I added a queueDraw in threadsAddIdle and it seems to draws the screen immediately but it does not seem to be called again. If I put queueDraw inside the addOnDraw routine then the animation works but it is quite slow, about 1 fps and cpu usage is 100% without it, it is 0%. You will probably want to use glib.Timeout to make the time between redraws consistent. The callBack for treadsAddIdle or glib.Idle is only called when the mainloop has nothing else to do. The cairo clock demo is a good example: https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d If performance is an issue one option would be to save your context in a cairo surface and only redraw the parts that have changed. -- Mike Wey
build 32-bit library on 64-bit OS
So I need to build a 32-bit version of a library on 64-bit system. I got some errors, which I get rid of after installing the gcc 32-bit tools (and gcc -m32 ran fine) but I still get errors about libraries not compatible. the command: dub --arch=x86 yield erros such: /usr/bin/ld: skiping //usr/lib/x86_64-linux-gnu/libphobos2-ldc-shared.so incompatible to -lphobos2-ldc-shared /usr/bin/ld: couldn't find -lphobos2-ldc-shared // collect2: error: ld returned 1 exit status Error: /usr/bin/gcc failed with status: 1 /usr/bin/ldc2 failed with exit code 1. How do I fix this?
Re: gtkD: How to paint to screen for animation
On Tuesday, 19 March 2019 at 00:54:34 UTC, Michelle Long wrote: I've added a function to addOnDraw for a DrawingArea and it paints using the code I have when I resize. I added a queueDraw in threadsAddIdle and it seems to draws the screen immediately but it does not seem to be called again. If I put queueDraw inside the addOnDraw routine then the animation works but it is quite slow, about 1 fps and cpu usage is 100% without it, it is 0%. I haven't dug into this stuff yet for my blog, but I have sourced some references. Here's one that may help: https://www.cairographics.org/threaded_animation_with_cairo/
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:25:27 UTC, Denis Feklushkin wrote: On Tuesday, 19 March 2019 at 13:20:37 UTC, Vladimir Panteleev wrote: On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: /+ dub.sdl: name "hello_world" +/ This doesn't seem necessary :) I add it ~everywhere for faster reproducing of cases. Not sure what you mean by this, because 1) it's not even doing anything if there are no dependencies on Dub packages, and 2) test cases should be self-contained and not have external dependencies anyway. If the test case can only be reproduced with some compiler switches, a shebang using rdmd (with --shebang for multiple switches) can be used to illustrate it.
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:20:37 UTC, Vladimir Panteleev wrote: On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: /+ dub.sdl: name "hello_world" +/ This doesn't seem necessary :) I add it ~everywhere for faster reproducing of cases. static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter), byte)); static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter()), byte)); typeof(stdout.lockingBinaryWriter) is a function type. You need the (). Ooops! Thanks! :-) /thread
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: /+ dub.sdl: name "hello_world" +/ This doesn't seem necessary :) static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter), byte)); static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter()), byte)); typeof(stdout.lockingBinaryWriter) is a function type. You need the ().
Re: File.lockingBinaryWriter is not output range?
On Tuesday, 19 March 2019 at 13:14:52 UTC, Denis Feklushkin wrote: stdout.lockingBinaryWriter.put(cast(byte) 123); // works // But this assert is false: static assert(isOutputRange!(typeof(stdout.lockingBinaryWriter), byte)); } Looks like isOutputRange is not checks "put" method properly?
File.lockingBinaryWriter is not output range?
/+ dub.sdl:
name "hello_world"
+/
import std.algorithm, std.range, std.stdio;
void main()
{
// lockingBinaryWriter: Returns an output range that locks
the file and allows fast writing to it.
//
https://dlang.org/library/std/stdio/file.locking_binary_writer.html
stdout.lockingBinaryWriter.put(cast(byte) 123); // works
// But this assert is false:
static
assert(isOutputRange!(typeof(stdout.lockingBinaryWriter), byte));
}
This blocks to user File as Stream for msgpack-d.
Re: Another Tuesday (Friday?), Another GtkDcoding Blog Post
Tuesday again. This blog post is about invisible Entry widgets and the FontButton. Really stimulating stuff and you'll find it at: http://gtkdcoding.com/2019/03/19/0019-disappearing-text-entry.html
Re: Emulating DLL
There was this old project: http://dsource.org/projects/ddl/
Re: Any easy way to extract files to memory buffer?
On Monday, 18 March 2019 at 23:40:02 UTC, Michelle Long wrote: On Monday, 18 March 2019 at 23:01:27 UTC, H. S. Teoh wrote: On Mon, Mar 18, 2019 at 10:38:17PM +, Michelle Long via Digitalmars-d-learn wrote: On Monday, 18 March 2019 at 21:14:05 UTC, Vladimir Panteleev wrote: > On Monday, 18 March 2019 at 21:09:55 UTC, Michelle Long > wrote: > > Trying to speed up extracting some files that I first > > have to extract using the command line to files then read > > those in... > > > > Not sure what is taking so long. I imagine windows caches > > the extraction so maybe it is pointless? [...] Why not just use std.mmfile to memory-map the file into memory directly? Let the OS take care of actually paging in the file data. T The files are on disk and there is an external program that read them and converts them and then writes the converted files to disk then my program reads. Ideally the conversion program would take memory instead of disk files but it doesn't. the file that was written by the first program will be in the file cache. mmap() (and the Windows equivalent of that) syscalls are at the core only giving access to the OS file cache. This means that std.mmfile is the way to go. There will be no reloading from disk if the file sizes are within reason.
Compile-time associative array
Hi,
I want to use a constant associative array in a ctfe-able
function.
Example:
string ctfeableFunction()
{
return Foo["foo"];
}
Then I force ctfe with:
enum res = ctfeableFunction();
When I use an enum like:
enum Foo = ["foo" : "bar"];
It works fine.
D-Scanner keep saying to me: This enum may lead to unnecessary
allocation at run-time. Use 'static immutable [...] instead'
But it lead to: Error: static variable Foo cannot be read at
compile time.
So is the only way to make ctfe-able associative array is to use
enum instead of static immutable ?
Re: dub getting stuck
On Monday, 18 March 2019 at 20:25:14 UTC, Joel wrote: On Sunday, 17 March 2019 at 09:04:37 UTC, Eugene Wissner wrote: On Sunday, 17 March 2019 at 07:20:47 UTC, Joel wrote: macOS 10.13.6 dmd 2.085.0 dub 1.3.0 [snip] dub 1.3.0 is something old. Is it reproducable with a newer version? Can one safely update dub by it's self (Home Brew), when it comes with DMD (Home Brew also)? Well, I went ahead and updated dub. Looks like it's working now. Yay! Otherwise can be related: https://github.com/dlang/dub/issues/1345 https://github.com/dlang/dub/issues/1001
Re: is collectException working for every exceptions ?
On 03/19/2019 12:00 AM, Roman Sztergbaum wrote: On Tuesday, 19 March 2019 at 00:07:44 UTC, Ali Çehreli wrote: On 03/18/2019 11:54 AM, Roman Sztergbaum wrote: > [...] with the > [...] Andre Pany has already explained. Otherwise, I was going to say "collectException can collect Exceptions, not exceptions." ;) [...] Hello, What happen if the contract is not respected in this case ? since you dont have any assert inside the contract ? Thank's a lot ! You didn't quote that part but I think you're referring to the expression-based contracts. Actually, the asserts are still there but the syntax is cleaner. That syntax was introduced in 2.081.0: https://dlang.org/changelog/2.081.0.html#expression-based_contract_syntax I have a section about them as well: http://ddili.org/ders/d.en/contracts.html#ix_contracts.expression-based%20contracts Ali
Re: is collectException working for every exceptions ?
On Tuesday, 19 March 2019 at 00:07:44 UTC, Ali Çehreli wrote: On 03/18/2019 11:54 AM, Roman Sztergbaum wrote: > [...] with the > [...] Andre Pany has already explained. Otherwise, I was going to say "collectException can collect Exceptions, not exceptions." ;) [...] Hello, What happen if the contract is not respected in this case ? since you dont have any assert inside the contract ? Thank's a lot !
