Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 09:43:13 UTC, Dukc wrote: On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote: Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please? Why? The C standard library not a true and intrinsic dependency of D, and is outside of D's charter. There are druntime implementations that leverage the C standard library, but I believe that was largely done for expediency. If one wants to leverage the C standard library for a certain druntime implementation, that's fine, but it should be privately imported. D is a much more capable programming language than C, and whatever functionality is being imported from the C standard library can be better implemented in D with compile-time optimizations via templates, memory safety, and other benefits. Mike
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 5 August 2018 at 20:01:22 UTC, Nikos wrote: Thank you very much for your feedback. Unfortunately, none of the above worked. By the way, the reason I'm trying all this is to create a Jupyter notebook. I've already made a simple version of it some time ago (https://github.com/nikoskaragiannakis/d-jupyter-kernel). Since you are also working on a D kernel, maybe we could work together? Sure https://github.com/thewilsonator/jupyterd There are 5 main objects: Channel, an abstraction over raw ZMQ sockets. Interpreter, abstracted for debugging and also other kernels (I work for Laeeth and they have an internal language they wan't to use from this.) Kernel, does the higher level network logic and calls the interpreter. Message and Wire message are high and low level representation of the packet layout. I'm currently trying to figure out why the message signing is bjorked (I swear it did use to work!), the IOPub channel fails intermittently (the worst kind) and the Shell/Control fails all of the time. Any effort pointing out where I done something stupid is much appreciated (and I do mean something stupid, the last major hurdle was trying to figure out why the packets were going nowhere: turns out I was missing the routing prefix). Are you on slack?
Re: Dpp on run.dlang.io
On Sunday, 5 August 2018 at 22:43:42 UTC, Laeeth Isharc wrote: One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) with just screenshot for: Excel (via autowrap excel / excel-d) C# via Binderoo Jupyter via pydmagic and just link for web assembly. Obviously a lot of work, but if you think a good idea we could work away at over time. "Here's something I prepared earlier." https://github.com/thewilsonator/interop This is currently to house [1] to try to show Walter why https://github.com/dlang/dmd/pull/8120 is a good idea. Unfortunately he remains unconvinced so I think I'm going to have to do it as a DIP [3]. [1]: https://github.com/thewilsonator/interop/blob/master/c%2B%2B/dslice.h [2]: https://github.com/dlang/dmd/pull/8120 [3]: https://github.com/thewilsonator/DIPs/blob/extern(C++)-array/DIPs/DIP1xxx.md
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 13:15:24 UTC, Seb wrote: On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th It now also supports multiple files (and compiling C files) with the Har format [1]: https://run.dlang.io/is/WwpvhT This should hopefully make it even more useful. [1] https://github.com/marler8997/har Thanks v much for this. One benefit of D is as a better glue language that integrates well with other languages and ecosystems. Many people who know a bit about D have no idea that interop can work so easily or well. So it might be worth mentioning this benefit as one link from main page and then linking from that to new page that mentions and has runnable examples (using HAR) for: Python (via autowrap:python and pyd) C (via dpp) C++ (extern(C++) for now) R (via embedr) Julia (via C interface, including julia.h via dpp) Lua (if LuaD stable enough) with just screenshot for: Excel (via autowrap excel / excel-d) C# via Binderoo Jupyter via pydmagic and just link for web assembly. Obviously a lot of work, but if you think a good idea we could work away at over time.
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Sunday, 5 August 2018 at 20:01:22 UTC, Nikos wrote:
On Tuesday, 31 July 2018 at 09:09:11 UTC, Nicholas Wilson wrote:
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state
across.
Also I'm working on a D kernel for Jupyter notebook which
should be done soon.
Thank you very much for your feedback. Unfortunately, none of
the above worked.
By the way, the reason I'm trying all this is to create a
Jupyter notebook. I've already made a simple version of it some
time ago
(https://github.com/nikoskaragiannakis/d-jupyter-kernel). Since
you are also working on a D kernel, maybe we could work
together?
Working example of Python calling D Repl is here.
https://github.com/kaleidicassociates/pydrepl
Re: autowrap v0.0.1 - Automatically wrap existing D code for use in Python and Excel
On Tuesday, 31 July 2018 at 09:09:11 UTC, Nicholas Wilson wrote:
On Sunday, 29 July 2018 at 18:14:31 UTC, Nikos wrote:
But when I try to export the whole dmdEngine
export:
auto engine(char[] txt) {
return interpreter(dmdEngine());
}
Can you export an instance of `interpreter(dmdEngine())`?
e.g.
__gshared auto dmdi = interpreter(dmdEngine());
export ref dmd()
{
return dmdi;
}
or if that doesn't work, proxy it
__gshared auto dmdi = interpreter(dmdEngine());
struct Dmd
{
mixin Proxy!dmdi;
}
export auto dmd()
{
Dmd d;
return d;
}
That is pretty much required if you want to maintain state
across.
Also I'm working on a D kernel for Jupyter notebook which
should be done soon.
Thank you very much for your feedback. Unfortunately, none of the
above worked.
By the way, the reason I'm trying all this is to create a Jupyter
notebook. I've already made a simple version of it some time ago
(https://github.com/nikoskaragiannakis/d-jupyter-kernel). Since
you are also working on a D kernel, maybe we could work together?
Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 08:01:47 UTC, Ecstatic Coder wrote:
Btw I *had* ("And I'd be glad to mentor you on this :)", here
on July 24th).
Thanks for remembering me why I now better enjoy the Crystal
community...
Sorry, I seem to have missed that. But to quote from the SAoC
page [1]:
"If you are interested in becoming a mentor, please submit an
email to soc...@dlang.org and let us know which project, or what
kinds of projects, you would be willing to mentor, as well as the
number of hours per week you can make yourself available to your
code during the event. The event organizers may ask for more
information, such as examples of your level of experience with D,
before deciding to accept your offer."
I appreciate anyone volunteering as a mentor, but if it isn't
sent to me at that address (or my personal one), I can't
guarantee I'll see it.
[1] https://dlang.org/blog/symmetry-autumn-of-code/
Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 05:22:44 UTC, Mike Franklin wrote: On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote: Hi, I’m interested in working on this project and just wanted to touch base. Is there any word on who will be mentoring this project? I’m entering college this fall but I’ve been programming since a very young age and enjoy systems programming. The project is mostly about creating high-performance, resource-efficient 2D software rasterizer, something like this (http://nothings.org/gamedev/rasterize/) or (https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445) If that isn't enough work for the event you can build on it by creating path objects with clipping and offsetting (http://angusj.com/delphi/clipper.php), rasterizing TrueType or OpenType fonts, creating drawing primitives, and even potentially creating 2D widgets (buttons, text labels, etc.) I think it's up to you how much of it you want to take on. I proposed the idea, but I don't think I'd be a very good mentor for the project because I've never created a 2D rasterizer myself. However, I'd be happy to help anyone working on the project in an unofficial capacity, and can probably articulate the intended use case for it. Mike I was 14 and a half when I implemented my first depth buffer based rasterizer, in 6502 assembly on a C64, for a hi-res mode 3D renderer. The algorithm, despite being "naive", is actually still an efficient one even now. I stored an array of x/depth ranges (one per raster line), and updated them while drawing the wireframe points of the 3 clipped edges, while updating the y range of the triangle. Then I simply iterated on the triangle y range and drew the inner points (between minimum_x+1 and maximum_x-1), using the filling color and interpolating depth. Clearly not realtime as my character-based wireframe renderer, I admit it. But this more than fast enough to quickly render a hi-res 3d scene in memory in *filled* mode. So this "dumb" algorithm may still be worth being investigated in your case, as this C64 implementation was meant to run on a rather similar hardware (very limited memory and CPU, only fixed point operations, etc). Just add antialiasing on the wireframe edges and you're done...
Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 05:16:50 UTC, Mike Parker wrote:
On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote:
[...]
Hi, I’m interested in working on this project and just wanted
to touch base. Is there any word on who will be mentoring this
project? I’m entering college this fall but I’ve been
programming since a very young age and enjoy systems
programming.
No one has volunteered to mentor this project yet, but if you'd
like to write a proposal for it we can find a mentor if you are
selected.
Btw I *had* ("And I'd be glad to mentor you on this :)", here on
July 24th).
Thanks for remembering me why I now better enjoy the Crystal
community...
