Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) -- Dmitry Olshansky
D goes business! Bindings for SAP NetWeaver RFC SDK
Hi all! My latest project is D bindings for the SAP NetWeaver RFC SDK. The first code is available at https://github.com/redstar/sapnwrfc-d. It is currently only a port of the main header file but I plan to add a high-level API, too. See the README for current limitations and ideas. I create a tag for the DUB registry as soon as I got the first working example. Regards, Kai
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Can someone stick this interview link on reddit? I think others would find it interesting.
FancyPars
Small announcement. I uploaded my parser-generator onto github. It is work in progress and unfinished! I cannot continue working on it anymore. Because it is quite idiomatic D-code. I hope that it will be suitable to beginners. Unfortunately I will not be available to take any questions. Repo-Location : https://github.com/UplinkCoder/fancypars-lite
Re: D extensions to python, inline in an ipython/jupyter notebook
On Thursday, 2 July 2015 at 19:51:19 UTC, Laeeth Isharc wrote: What is the benefit from using distutils for working with D in a notebook? There are two standards - the Python one, and the D one. The advantage of using dub is that it becomes wonderfully easy to pull in D projects from code.dlang.org and to compile your own work developed under dub. (And dub itself continues to improve). Linking to a D project of decent complexity via distutils is not my idea of fun. This was my train of thought too. I do agree that for pyd itself it would be nice to retain the option of distutils (although I would love to see dub added also), pyd does have rudimentary dub support, but it's only for embedding python in D, not the other way around. Extension support is on my TODO list, it's not complicated. One should look at this as an alpha, extremely promising project. It is not any rough edges that are important at this stage, but that it has been done at all (in a form that is already very valuable). The set of people that want to use computers to explore larger data sets than lately considered comfortable in an iterative manner is not small, even confining It just to finance. It's of real value to be able to hook in to a proper back end that manages market and static data, with also any data processing and analytics also in D, and then to have a pretty and friendly front end that can just talk to this code on the back with minimal messing around to get there. It's also very nice to have both Jupyter and an Excel spreadsheet at windows onto the data on your local machine or in the enterprise cloud. The frictions to starting to play with D in a notebook are much lower than going via the command line, so I really am not sure if we should be worried about making it marketable at this stage rather than useful for doing real work. It's potentially a nice debugging tool where you are trying to make sense of things that don't tidily fit in a debugging window, and where there is just too much stuff to do it via writefln or logging without putting lots of effort into the infrastructure to find events first. I do like the simpler syntax (than PyD). One question is whether you need to wrap every member of a struct. @pdefRecursive!() or @pdef!(Recursive.yes) or @pdef!(Recursive) ? It's totally doable. But it's a very useful start as it stands. As an addendum: not many people prefer to do non system type things in C than a higher level language when time is money. So the mindset is you build a C extension to address the worst bits where Python's true colours shine through (ie when you are in a tight loop within Python interpreter and not spending most of the time in its C libraries. Or writing C glue to connect Python to another library. In my view, D is different. I would rather write in D than Python, and to me it's much better Tor doing serious work. Even for parsing a CSV I prefer it (although one could debate the point). In any case D is not especially slower to write in than Python (particularly when you include time spent getting the bugs out), and in a decent number of cases it may be more productive. So why bother with Python at all ? Better ecosystem for charting and exploring data, and an interpreter is better suited generally for certain kinds of tasks. Also in some areas more libraries, which can be helpful to get a quick result, so that one can go back and do it properly later. Libraries, libraries, libraries. In a perfect world we can reimplement everything in D and it'll be awesome, but in the getting shit done world that normal people inhabit they need it to work, today. Bridges to other languages gives us that. E.g. I have a 3D plotting library in D (still in stealth mode on that one) that uses matplotlib via pyd to generate tick labels using either the builtin TeX parser renderer (OK, fast) or actually calling out to latex (perfect, slow). Could I have done that all myself in D? Sure. Would I? No, i would still have terribly rendered tick labels with no TeX support. I don't have time to write a TeX implementation, even one as rudimentary and limited as matplotlib's. In short, you're right. It would be v helpful to have a Datetime conversion from D. Looks like there is a macro for converting from ymd in datetime.h, so I guess one could just write some code against this API in C, D, or Cython and link it in with D so one can transfer data structures over more easily. I know just enough about that topic to be very scared.
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
Very interesting interview ! On the question about love/hate of D, there's this sentence: ' for, works with any range or something that can be sliced to get a range.'. Didn't you mean foreach ? 2015-06-29 5:46 GMT+02:00 Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: http://arsdnet.net/this-week-in-d/jun-28.html
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Monday, 29 June 2015 at 03:46:55 UTC, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html Adam. At least on safari you can't scroll down the archive panel. The first 20 editions are visible, but not the rest.
Repost of Chuck Allison's dconf 2015 talk
It looks like they re-edited Chuck's talk and reposted it (so the old link is invalid): https://www.youtube.com/watch?v=iTJnkF0H6S8 - Jonathan M Davis
3 more dconf 2015 talks (Andy, Jonathan, and Mark)
It looks like the UVU folks posted some more. Andy Smith -- Title: Hedge Fund Development Case Study dconf link: http://dconf.org/2015/talks/smith.html video link: https://www.youtube.com/watch?v=0KBhb0iWsWQ Jonathan M Davis Title: Introduction to Ranges dconf link: http://dconf.org/2015/talks/davis.html video link: https://www.youtube.com/watch?v=A8Btr8TPJ8c Mark Isaacson - Title: Leveraging D to mitigate dependency-induced code smell dconf link: http://dconf.org/2015/talks/isaacson.html video link: https://www.youtube.com/watch?v=HHHhi4_9sGo You can find all of the talks that have been posted here: https://www.youtube.com/playlist?list=PL12FA104E02ABE730
Re: D extensions to python, inline in an ipython/jupyter notebook
It would be v helpful to have a Datetime conversion from D.
Looks like there is a macro for converting from ymd in
datetime.h, so I guess one could just write some code against
this API in C, D, or Cython and link it in with D so one can
transfer data structures over more easily.
I know just enough about that topic to be very scared.
I should be able to call these from D without changing PyD, I
think, for D to Python. Not sure about Python to D, but maybe.
https://github.com/ariovistus/pyd/blob/master/infrastructure/python/python.d
From D to Python datetime.datetime
===
PyObject *PyDate_FromDate()(int year, int month, int day) {
return PyDateTimeAPI.Date_FromDate(year, month, day,
PyDateTimeAPI.DateType);
}
PyObject *PyDateTime_FromDateAndTime()(int year, int month, int
day, int hour, int min, int sec, int usec) {
return PyDateTimeAPI.DateTime_FromDateAndTime(year, month, day,
hour,
min, sec, usec, Py_None, PyDateTimeAPI.DateTimeType);
}
From Python datetime.datetime to D
===
// D translations of C macros:
int PyDateTime_GET_YEAR()(PyObject *o) {
PyDateTime_Date *ot = cast(PyDateTime_Date *) o;
return (ot.data[0] 8) | ot.data[1];
}
int PyDateTime_GET_MONTH()(PyObject *o) {
PyDateTime_Date *ot = cast(PyDateTime_Date *) o;
return ot.data[2];
}
int PyDateTime_GET_DAY()(PyObject *o) {
PyDateTime_Date *ot = cast(PyDateTime_Date *) o;
return ot.data[3];
}
int PyDateTime_DATE_GET_HOUR()(PyObject *o) {
PyDateTime_DateTime *ot = cast(PyDateTime_DateTime *) o;
return ot.data[4];
}
int PyDateTime_DATE_GET_MINUTE()(PyObject *o) {
PyDateTime_DateTime *ot = cast(PyDateTime_DateTime *) o;
return ot.data[5];
}
int PyDateTime_DATE_GET_SECOND()(PyObject *o) {
PyDateTime_DateTime *ot = cast(PyDateTime_DateTime *) o;
return ot.data[6];
}
int PyDateTime_DATE_GET_MICROSECOND()(PyObject *o) {
PyDateTime_DateTime *ot = cast(PyDateTime_DateTime *) o;
return (ot.data[7] 16) | (ot.data[8] 8) | ot.data[9];
}
Re: Looking for part-time developer for app back-end and webviews in D
On Thursday, 2 July 2015 at 16:14:55 UTC, David Gill wrote: I'd be looking for an experienced D developer to take over the project and give it its final touches. I've added this to the wiki http://wiki.dlang.org/Jobs If you provide more complete information, I can add it there, or you can do so yourself.
Looking for part-time developer for app back-end and webviews in D
Hello D Programming community. How I'm glad I found you :). We've developed a super simple iOS and Android app, which was originally built with Cake PHP and some other frameworks. In order to increase stability, we completely rebuilt everything from scratch and chose to go with vide.d for our API's and webviews. The project is almost complete, but our lead developer is leaving us. I'd be looking for an experienced D developer to take over the project and give it its final touches. The previous developer would be there to provide guidance to decrease learning curve. No pressure; part time; work from whatever location. If interested, please drop me a line @ davidgil...@me.com. Thanks!
Re: This Week in D #23 - Interview with Dmitry Olshansky, dmd beta, std.experimental.color
On Thursday, 2 July 2015 at 14:16:41 UTC, Joakim wrote: On Thursday, 2 July 2015 at 10:26:36 UTC, Dmitry Olshansky wrote: On 29-Jun-2015 06:46, Adam D. Ruppe wrote: http://arsdnet.net/this-week-in-d/jun-28.html I should have probably said on the day one - AMA. P.S. Thanks to Joakim for editing my stream of consciousness into this tidy text ;) Can someone stick this interview link on reddit? I think others would find it interesting. Might be worthwhile to wait until Monday, as Monday afternoon has the heaviest traffic out of the entire week, I believe.
Re: D extensions to python, inline in an ipython/jupyter notebook
On Tue, 2015-06-30 at 18:20 +, John Colvin via Digitalmars-d -announce […] Ditched distutils in favour of dub. This is easier for me to maintain and fits much better with the rest of the D ecosystem I am not convinced by this, though cleary my feeling carry no weight in decision making :-) For building C, and C++ extension (and indeed Chapel ones) it is assumed distutils will be used, allowing for: python3 setup.py build python3 setup.py install SCons can do this but every one demands distutils. Can dub really replace distutils for installing extensions as well as building them? Will people installing extensions be prepared to switch to a non -standard system? Whilst perhaps they should, they won't. I fear that without a distutils installation, the extension will never be installed outside the development team. It's not the D community that must be convinced, it is the Python one. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: initial port of excel sdk headers to D
On Wednesday, 1 July 2015 at 23:56:51 UTC, Øivind wrote: On Sunday, 28 June 2015 at 23:23:07 UTC, Laeeth Isharc wrote: https://github.com/Laeeth/d_excelsdk probably many rough edges - a couple of functions still to fix Can you provide an example of how to use it? I am interested in this type of functionality :) Try building the DLL and renaming to XLL. Then add to your workbook as an add in. Also see the Microsoft Excel SDK on the web and the official C/C++ API. There is not much more to it than that for now. Laeeth.
Re: D extensions to python, inline in an ipython/jupyter notebook
On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote: On Tue, 2015-06-30 at 18:20 +, John Colvin via Digitalmars-d -announce […] Ditched distutils in favour of dub. This is easier for me to maintain and fits much better with the rest of the D ecosystem I am not convinced by this, though cleary my feeling carry no weight in decision making :-) For building C, and C++ extension (and indeed Chapel ones) it is assumed distutils will be used, allowing for: python3 setup.py build python3 setup.py install SCons can do this but every one demands distutils. Can dub really replace distutils for installing extensions as well as building them? Will people installing extensions be prepared to switch to a non -standard system? Whilst perhaps they should, they won't. I fear that without a distutils installation, the extension will never be installed outside the development team. It's not the D community that must be convinced, it is the Python one. There are 2 seperate points where a build/install system is needed: 1) Installing the extension. It's just one python file, which makes it a good fit for %install_ext but of course I could wrap it in a trivial setup.py to make people feel more comfortable / make it fit in with easy_install/pip or related tools. 2) building the inline D code and sorting out linking to other libraries etc. The basics of this can be done with distutils (it's how pyd traditionally does it), but seeing as it's all D code from this point, dub is a better fit, otherwise people have to have manually install any D libraries they want to use. I originally modelled PydMagic on how the %%cython inline magic works. %%cython uses distutils under the scenes with minor leakage for the compilation options and PydMagic uses dub, with similar levels of leakage. The recently-spun-off-from-PydMagic work of making a nicer API for pyd ( github.com/John-Colvin/ppyd which PydMagic pulls in via dub) is independent of the build system, so you can use pyd's distutils extensions or dub. This is the project you would use if you want to write a proper python extension in D, as opposed to little snippets in a Jupyter notebook.
Re: D extensions to python, inline in an ipython/jupyter notebook
On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote: On Tue, 2015-06-30 at 18:20 +, John Colvin via Digitalmars-d -announce […] Ditched distutils in favour of dub. This is easier for me to maintain and fits much better with the rest of the D ecosystem I am not convinced by this, though cleary my feeling carry no weight in decision making :-) For building C, and C++ extension (and indeed Chapel ones) it is assumed distutils will be used, allowing for: python3 setup.py build python3 setup.py install SCons can do this but every one demands distutils. Can dub really replace distutils for installing extensions as well as building them? Will people installing extensions be prepared to switch to a non -standard system? Whilst perhaps they should, they won't. I fear that without a distutils installation, the extension will never be installed outside the development team. It's not the D community that must be convinced, it is the Python one. What is the benefit from using distutils for working with D in a notebook? There are two standards - the Python one, and the D one. The advantage of using dub is that it becomes wonderfully easy to pull in D projects from code.dlang.org and to compile your own work developed under dub. (And dub itself continues to improve). Linking to a D project of decent complexity via distutils is not my idea of fun. I do agree that for pyd itself it would be nice to retain the option of distutils (although I would love to see dub added also), One should look at this as an alpha, extremely promising project. It is not any rough edges that are important at this stage, but that it has been done at all (in a form that is already very valuable). The set of people that want to use computers to explore larger data sets than lately considered comfortable in an iterative manner is not small, even confining It just to finance. It's of real value to be able to hook in to a proper back end that manages market and static data, with also any data processing and analytics also in D, and then to have a pretty and friendly front end that can just talk to this code on the back with minimal messing around to get there. It's also very nice to have both Jupyter and an Excel spreadsheet at windows onto the data on your local machine or in the enterprise cloud. The frictions to starting to play with D in a notebook are much lower than going via the command line, so I really am not sure if we should be worried about making it marketable at this stage rather than useful for doing real work. It's potentially a nice debugging tool where you are trying to make sense of things that don't tidily fit in a debugging window, and where there is just too much stuff to do it via writefln or logging without putting lots of effort into the infrastructure to find events first. I do like the simpler syntax (than PyD). One question is whether you need to wrap every member of a struct. But it's a very useful start as it stands.
Re: D extensions to python, inline in an ipython/jupyter notebook
On Thursday, 2 July 2015 at 18:28:50 UTC, Russel Winder wrote: On Tue, 2015-06-30 at 18:20 +, John Colvin via Digitalmars-d -announce […] Ditched distutils in favour of dub. This is easier for me to maintain and fits much better with the rest of the D ecosystem I am not convinced by this, though cleary my feeling carry no weight in decision making :-) For building C, and C++ extension (and indeed Chapel ones) it is assumed distutils will be used, allowing for: python3 setup.py build python3 setup.py install SCons can do this but every one demands distutils. Can dub really replace distutils for installing extensions as well as building them? Will people installing extensions be prepared to switch to a non -standard system? Whilst perhaps they should, they won't. I fear that without a distutils installation, the extension will never be installed outside the development team. It's not the D community that must be convinced, it is the Python one. As an addendum: not many people prefer to do non system type things in C than a higher level language when time is money. So the mindset is you build a C extension to address the worst bits where Python's true colours shine through (ie when you are in a tight loop within Python interpreter and not spending most of the time in its C libraries. Or writing C glue to connect Python to another library. In my view, D is different. I would rather write in D than Python, and to me it's much better Tor doing serious work. Even for parsing a CSV I prefer it (although one could debate the point). In any case D is not especially slower to write in than Python (particularly when you include time spent getting the bugs out), and in a decent number of cases it may be more productive. So why bother with Python at all ? Better ecosystem for charting and exploring data, and an interpreter is better suited generally for certain kinds of tasks. Also in some areas more libraries, which can be helpful to get a quick result, so that one can go back and do it properly later. It would be v helpful to have a Datetime conversion from D. Looks like there is a macro for converting from ymd in datetime.h, so I guess one could just write some code against this API in C, D, or Cython and link it in with D so one can transfer data structures over more easily.
