Re: dmd 2.063 released with 260 bugfixes and enhancements
On Sat, 2013-06-01 at 09:36 -0700, Ellery Newcomer wrote: On 06/01/2013 02:31 AM, Russel Winder wrote: On Fri, 2013-05-31 at 13:50 -0700, Ellery Newcomer wrote: […] just tried it on ubuntu 12.10, and it does the same. are you using -defaultlib=libphobos2.so I suspect I may be doing different things from you as I never use an option of that sort. Perhaps we should agree a code and command to make the tests. the way I build is detailed in the makefile here: https://bitbucket.org/ariovistus/pyd/src/296ef002750411331ec9a3bcb14aed345b65d8d5/examples/misc/dmd_sharedlibs?at=default I cloned PyD – I have been intending to do this for ages to try D for Python extensions – and ran make in the directory you mentioned: | make gcc -c -fPIC so_ctor.c -o so_ctor.o dmd -unittest -fPIC -defaultlib=libphobos2.so -shared test1.d boilerplate.d so_ctor.o -oflibtest1.so #dmd -c -unittest -fPIC test1.d boilerplate.d -oftemp.o #dmd -shared -defaultlib=phobos2so temp.o so_ctor.o -oflibtest1.so gcc test1.c `pwd`/libtest1.so -o test1.x ./test1.x initing yawn. stretch. lets test this donut. foo(2)=6 dniting yawn. z -- 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: [Somewhat OT] Textadept 6.6 released
Looks good. Definitely will try.
Re: dmd 2.063 released with 260 bugfixes and enhancements
Am Sun, 2 Jun 2013 07:40:27 +0200 schrieb Marco Leise marco.le...@gmx.de: For some reason I still cannot build dmd 2.063 from the zip release. I mentioned it before the release on the beta and internals mailing lists and maybe I'm just overlooking something trivial, but when I run make I get: make: *** Keine Regel vorhanden, um das Target »irstate.h«, benötigt von »irstate.o«, zu erstellen. Schluss. irstate.c is there, but irstate.h is missing. Is that like last time when VERSION was missing? Ok, a pull request about that got merged. Let's see if it ends up in the .zip ;) -- Marco
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On 2013-06-02 00:49, Adam Wilson wrote: Indeed, but since I was comparing to vanilla C# 4.0 and .NET I figured it was only fair to compare to DMD 2.062 and Phobos. Once you start comparing and contrasting third party libraries the scope of the topic quickly balloons in size. The biggest problem I had in putting this talk together was deciding what to cut. I ended up leaving about 60% of my originally planned content on the cutting room floor... I really wanted to give you guys more! Yes, sure, for the talk. But if you are actually going to port C# code to D I assume, and hope, you would take a practically approach. That is, using third party libraries if needed and not saying something like If it's not in Phobos we cannot use it. -- /Jacob Carlborg
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On 2013-06-01 23:11, Jonathan M Davis wrote: There are quite a few things that Phobos is still missing, but this isn't one of them. We have std.datetime.StopWatch (which will probably end up in std.benchmark when that's finally complete). I haven't looked in std.datetime lately but I though I heard in the talk it was missing. If not, my mistake. -- /Jacob Carlborg
Re: dmd 2.063 released with 260 bugfixes and enhancements
On Sun, 2013-06-02 at 11:23 -0700, Ellery Newcomer wrote: […] who packages your dmd? Normally I would use the one from APT-D, but as this not at 2.063 as yet I used the deb downloaded from the D download page. This necessitates removing all packages from APT-D since they depend on exactly a given DMD version. I have this installed GtkD from master/HEAD and not got Vibe.d just at the minute. -- 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
simpledisplay.d now works on as 64 bit on X
I know someone here was asking about my simpledisplay.d on 64 bit
a while ago.. I don't remember who so here's a general
announcement.
I got it working for at least the parts I tried (display image,
get keyboard input) compiled with -m64:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d
Quite a hassle, my xlib binding was apparently almost completely
wrong, and it worked on 32 bit just by sheer luck. Many of the
structs were the wrong sizes even there! General tip to C
porters: do a static assert(S.sizeof) and make sure it matches
what your C program gives. I got snagged in part here because
unsigned long in X is apparently 64 bit. I thought it was the
same as D's uint in all cases.
The file it also depends on color.d from the same repo. Another
minor change is the key event used to take a delegate (int
key){}. Now it takes (int key, bool pressed) instead. There's a
static assert with a reminder message too, so just compile and if
you need it, it will tell you. The (dchar){} event remains the
same as before.
Been a few random bug fixes in the last few months too, timer
events now work right on windows and linux is the big one that
comes to mind.
Re: dmd 2.063 released with 260 bugfixes and enhancements
On 06/02/2013 11:48 AM, Russel Winder wrote: On Sun, 2013-06-02 at 11:23 -0700, Ellery Newcomer wrote: […] who packages your dmd? Normally I would use the one from APT-D, but as this not at 2.063 as yet I used the deb downloaded from the D download page. This necessitates removing all packages from APT-D since they depend on exactly a given DMD version. I have this installed GtkD from master/HEAD and not got Vibe.d just at the minute. so we are using the same package. ?? oh. dpkg -L just doesn't list it. but it's definitely missing from the rpm.
Re: dmd 2.063 released with 260 bugfixes and enhancements
On Sun, 2013-06-02 at 12:48 -0700, Ellery Newcomer wrote: […] so we are using the same package. ?? oh. dpkg -L just doesn't list it. Symbolic links aren't in the deb, they are created by the post install script once the shared library is installed. but it's definitely missing from the rpm. Perhaps RPMs should have a post install script? -- 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: dmd 2.063 released with 260 bugfixes and enhancements
On 06/02/2013 12:56 PM, Russel Winder wrote: On Sun, 2013-06-02 at 12:48 -0700, Ellery Newcomer wrote: […] so we are using the same package. ?? oh. dpkg -L just doesn't list it. Symbolic links aren't in the deb, they are created by the post install script once the shared library is installed. but it's definitely missing from the rpm. Perhaps RPMs should have a post install script? you can package relative links in rpm. https://bitbucket.org/ariovistus/rpm-buildscripts/src/21921c736116a51f60db4ab9cb5852fc0ae0b63c/dmd-git2rpm?at=default#cl-293
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On Sun, 02 Jun 2013 02:34:39 -0700, Jacob Carlborg d...@me.com wrote: On 2013-06-02 00:49, Adam Wilson wrote: Indeed, but since I was comparing to vanilla C# 4.0 and .NET I figured it was only fair to compare to DMD 2.062 and Phobos. Once you start comparing and contrasting third party libraries the scope of the topic quickly balloons in size. The biggest problem I had in putting this talk together was deciding what to cut. I ended up leaving about 60% of my originally planned content on the cutting room floor... I really wanted to give you guys more! Yes, sure, for the talk. But if you are actually going to port C# code to D I assume, and hope, you would take a practically approach. That is, using third party libraries if needed and not saying something like If it's not in Phobos we cannot use it. In real life I would absolutely use third party libraries where available. I would definitely recommend people do the same. In retrospect I probably should've said something to that effect in the closing of my talk ... So many things I would say differently! -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: DConf 2013 Day 2 Talk 3: C# to D by Adam Wilson
On Sun, 02 Jun 2013 02:35:37 -0700, Jacob Carlborg d...@me.com wrote: On 2013-06-01 23:11, Jonathan M Davis wrote: There are quite a few things that Phobos is still missing, but this isn't one of them. We have std.datetime.StopWatch (which will probably end up in std.benchmark when that's finally complete). I haven't looked in std.datetime lately but I though I heard in the talk it was missing. If not, my mistake. Most of System.Timers is missing from Phobos. There is a LOT more than just a stopwatch in it. -- Adam Wilson IRC: LightBender Project Coordinator The Horizon Project http://www.thehorizonproject.org/
Re: simpledisplay.d now works on as 64 bit on X
I'm sorry to hear that you ran into the unsigned long problem. I noticed it in time and asked about it on the NG and was told that the difference is between Windows and Posix. One takes long as int32, the other as the native machine word size on 64-bit. We do the same stupid mistakes over and over. :p Also eventually we should generate X bindings for all platforms (including Windows) from the XML definitions like XCB does. That means a small core written in D that enables RPC to the X Server and a generator tool that creates functions, structs and DDoc from what is the XML files. (See /usr/share/xcb.) -- Marco
Re: simpledisplay.d now works on as 64 bit on X
On 6/2/13, Marco Leise marco.le...@gmx.de wrote: I'm sorry to hear that you ran into the unsigned long problem. This is why we have core.std.config: import core.stdc.config : c_long, c_ulong;
Re: D at University of Minnesota
This is awesome! I'm sure I speak on behalf of the entire community that we'd be happy to help with anything you need. There is, perhaps, a need for a short technical document bringing TDPL up to date, i.e. consistent with the currently accepted view of the definition of D (wherever that resides). No doubt this is not necessary and the course will go fine without it, but it would be useful, as well as being encouraging to those students who exercise some initiative.
Re: D at University of Minnesota
On Monday, June 03, 2013 00:29:09 Carl Sturtivant wrote: This is awesome! I'm sure I speak on behalf of the entire community that we'd be happy to help with anything you need. There is, perhaps, a need for a short technical document bringing TDPL up to date, i.e. consistent with the currently accepted view of the definition of D (wherever that resides). No doubt this is not necessary and the course will go fine without it, but it would be useful, as well as being encouraging to those students who exercise some initiative. And what about TDPL is so out of date? Its description of pure is that of strongly pure and thus is not fully correct, but from what I recall, almost everything in it that's not correct (aside from actually errors in the original text - which are covered by the errata) simply hasn't been implemented yet (e.g. multiple alias thises) and was not any more correct when TDPL was released than it is now. So, AFAIK, very little in TDPL is incorrect or actually needs to be updated, and almost all of what's incorrect is supposed to be corrected by the feature in question actually being implemented. - Jonathan M Davis
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 2 June 2013 at 22:16:57 UTC, Andrej Mitrovic wrote: This is why we have core.std.config: import core.stdc.config : c_long, c_ulong; I would never have thought to look in config for types! Well, hopefully I'll remember for next time.
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote: Also eventually we should generate X bindings for all platforms (including Windows) from the XML definitions like XCB does. hmm I don't see an xml file for Xlib.h on my system, do you know if there is supposed to be one? Though I'm pretty sure I have most of it correct now, so I guess it isn't really necessary. I know everybody says Xlib is dying but I still use it. It is simple enough and gets the job done without having to learn a whole thing library...
Re: simpledisplay.d now works on as 64 bit on X
Andrej Mitrovic: This is why we have core.std.config: import core.stdc.config : c_long, c_ulong; Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html I'd like to open a little documentation enhancement request for that. Bye, bearophile
Re: simpledisplay.d now works on as 64 bit on X
On 6/2/13 7:10 PM, bearophile wrote: Andrej Mitrovic: This is why we have core.std.config: import core.stdc.config : c_long, c_ulong; Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html I'd like to open a little documentation enhancement request for that. Bye, bearophile And while you are at it, please also contribute the corresponding pull request. Time to inaugurate bearophile's additions! Andrei
Re: simpledisplay.d now works on as 64 bit on X
Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html It seems it lacks some of them, this gives an import error: import core.stdc.config: c_ulonglong, c_longlong; Bye, bearophile
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 2 June 2013 at 23:19:18 UTC, bearophile wrote: It seems it lacks some of them, this gives an import error: It only defines c_long and c_ulong. I guess this is ok because the other types don't vary, though I kinda think it should do them all just so you can be consistent. Not long ago I thought int on 64 bit was 64 bit too, because int on 16 bit is 16 bit so I figured it just did that the whole way up. But no, C's int is always D's int. A nice c_int alias would make that mindless too, even though it isn't strictly necessary.
Re: simpledisplay.d now works on as 64 bit on X
Andrei Alexandrescu: And while you are at it, please also contribute the corresponding pull request. Time to inaugurate bearophile's additions! As my friend, please understand, I can't afford to get addicted to that :-) Hugs, bearophile
Re: simpledisplay.d now works on as 64 bit on X
On 6/3/13, bearophile bearophileh...@lycos.com wrote: Why isn't that linked in this page? http://dlang.org/phobos/std_stdint.html Because it's on this page: http://dlang.org/interfaceToC.html It seems it lacks some of them, this gives an import error: import core.stdc.config: c_ulonglong, c_longlong; Again see http://dlang.org/interfaceToC.html
Re: simpledisplay.d now works on as 64 bit on X
On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote: http://dlang.org/interfaceToC.html ah then what is this page doing there? http://dlang.org/htomodule.html The documentation could def use a lil cleanup.
Re: simpledisplay.d now works on as 64 bit on X
Andrej Mitrovic: Because it's on this page: http://dlang.org/interfaceToC.html It seems it lacks some of them, this gives an import error: import core.stdc.config: c_ulonglong, c_longlong; Again see http://dlang.org/interfaceToC.html Good, thank you. I missed that. Bye, bearophile
Re: simpledisplay.d now works on as 64 bit on X
On 6/3/13, Adam D. Ruppe destructiona...@gmail.com wrote: On Sunday, 2 June 2013 at 23:35:28 UTC, Andrej Mitrovic wrote: http://dlang.org/interfaceToC.html ah then what is this page doing there? http://dlang.org/htomodule.html The documentation could def use a lil cleanup. There's a bug report for everything: http://d.puremagic.com/issues/show_bug.cgi?id=7346 I'm like a handy little bugzilla bot. :p
Re: simpledisplay.d now works on as 64 bit on X
Am Mon, 03 Jun 2013 01:02:12 +0200 schrieb Adam D. Ruppe destructiona...@gmail.com: On Sunday, 2 June 2013 at 21:53:56 UTC, Marco Leise wrote: Also eventually we should generate X bindings for all platforms (including Windows) from the XML definitions like XCB does. hmm I don't see an xml file for Xlib.h on my system, do you know if there is supposed to be one? Though I'm pretty sure I have most of it correct now, so I guess it isn't really necessary. XCB is generated from these XML files. They have nothing to do with Xlib. You can find the XML files here: http://cgit.freedesktop.org/xcb/proto/tree/src A generator tool for the target language (C in this case) parses them and creates include files from them that define all the remote procedure calls to the X Server. Internally those calls rely on a small generic set of functions that serializes the requests for transmission. What is needed are those generic functions written in D to establish the connection to the server and handling serialization, probably relying on std.socket. And then an XML parser that would write out .d files for the different modules of the X Server, like xrandr, xkb and so on, which are all available as separate XML files. This is what a RPC from glx.xml looks like: request name=GenTextures opcode=145 field type=CONTEXT_TAG name=context_tag / field type=INT32 name=n / reply pad bytes=1 / pad bytes=24 / list type=CARD32 name=data fieldreflength/fieldref /list /reply /request In general they also include documentation tags which can be made available through DDoc automatically and displayed in IDEs like Mono-D already does. I know everybody says Xlib is dying but I still use it. It is simple enough and gets the job done without having to learn a whole thing library... The big deal about it is asynchronous RCP especially over internet connections to X Servers, since with Xlib you have to way for each response before the next request. -- Marco
Re: D at University of Minnesota
Maybe stuff added to the language? User-defined attributes, for instance. LMB On Sun, Jun 2, 2013 at 7:45 PM, Jonathan M Davis jmdavisp...@gmx.com wrote: On Monday, June 03, 2013 00:29:09 Carl Sturtivant wrote: This is awesome! I'm sure I speak on behalf of the entire community that we'd be happy to help with anything you need. There is, perhaps, a need for a short technical document bringing TDPL up to date, i.e. consistent with the currently accepted view of the definition of D (wherever that resides). No doubt this is not necessary and the course will go fine without it, but it would be useful, as well as being encouraging to those students who exercise some initiative. And what about TDPL is so out of date? Its description of pure is that of strongly pure and thus is not fully correct, but from what I recall, almost everything in it that's not correct (aside from actually errors in the original text - which are covered by the errata) simply hasn't been implemented yet (e.g. multiple alias thises) and was not any more correct when TDPL was released than it is now. So, AFAIK, very little in TDPL is incorrect or actually needs to be updated, and almost all of what's incorrect is supposed to be corrected by the feature in question actually being implemented. - Jonathan M Davis
Re: D at University of Minnesota
On Sunday, June 02, 2013 21:56:30 Leandro Motta Barros wrote: Maybe stuff added to the language? User-defined attributes, for instance. Sure, there's stuff that TDPL doesn't describe, but TDPL never described everything (for instance, it doesn't go into a detailed explanation of the various types of is expressions). But that's different from it being incorrect due to language changes, which seems to be what Carl is saying is happening. I'm sure that we'll get another edition of TDPL at some point, but as far as I can tell, aside from the errata (which indicates errors in the original text as opposed to anything that's changed in the language since), there are very few things in there that are wrong at this point, and almost all of them relate to features that have never been fully implemented and thus were as incorrect when TDPL was published as they are now (but hopefully won't be incorrect in the future). And even that list isn't very long. The only two that I can come up with off the top of my head is having multiple aliases thises and having synchronized classes instead of synchronized functions. - Jonathan M Davis
Re: simpledisplay.d now works on as 64 bit on X
On Monday, 3 June 2013 at 00:15:20 UTC, Marco Leise wrote: all the remote procedure calls to the X Server. Internally those calls rely on a small generic set of functions that serializes the requests for transmission. I see. I just skimmed an xcb tutorial and it isn't all that different than xlib so maybe I'll spend a weekend on it at some point and make it work in D. There's a few things we can do to make the async stuff pretty too, thanks to delegates and the sort. And perhaps I can add a concept of a sprite to simplediplay. This represents an XPixmap - distinct from an XImage in that it is on the server - or on Windows, we can probably just us an HBITMAP. These wouldn't offer direct pixel manipulation like simplediplay's current Image (which is an XImage and HBITMAP in implementation) but would be able to avoid transferring a lot of data to the X server. And lastly (optionally, like with terminal.d) tie it into my generic eventloop.d. Then we'll really be cooking with gas! It'll have to wait a while though, hacking on this stuff doesn't make my house payments :(
