Re: dmd 2.065 beta 3
On Monday, 3 February 2014 at 18:54:49 UTC, evilrat wrote: On Monday, 3 February 2014 at 18:37:20 UTC, Andrew Edwards wrote: Windows users, please give the new installer a try. It has been updated to facilitate proper installation. vc2013/win 8.1/winsdk 8.1 detects visual studio correctly, path to win sdk correctly. has wrong path to mspdb120.dll, current: PATH=%PATH%;%VCINSTALLDIR%\bin\x86_amd64;%VCINSTALLDIR%\..\Common7\IDE should be: PATH=%PATH%;%VCINSTALLDIR%\bin;%VCINSTALLDIR%\..\Common7\IDE has no path to libs dir for sdk 8.1, should be: ; Platform libraries (Windows SDK 8.1) LIB=%LIB%;%WindowsSdkDir%\Lib\winv6.3\um\x64 after these changes all seems to be working. These steps were required for me as well, VS 2013 and Windows 8.1.
Re: COMPO
On Sun, 2014-02-09 at 07:25 +, Steve Teale wrote: […] I have changed the naming to make it clear that it is a 32 bit version. However it's not clear to me whether I can build a 64 bit version on my 32 bit system. Should be possible if you have the 64-bit libraries, it's just a form of cross-compilation. a) How do I tell if my GCC version is multilib, GCC just has flags to determine whether it does 32-bit or 64-bit compilation and linking. The only issue is whether you have the 32-bit libraries to link against. For Debian (and Ubuntu, and some variants of Mint) ensure you have the multiarch-support and binutils-multiarch in place. Probably best to see https://wiki.debian.org/Multiarch b) Can I build a static 64 bit library - gtkd2 - on my 32 bit system. Should be able to, DMD, GDC and LDC can all cross-compile. If you send me a reference to your deb build repository, I'll clone it and give a build a try here, save you the hassle. PS I thought the idea of D application compilation was not to build separate objects for each source and then link (as in your Makefile), but to compile and link all sources in one step (makes the Makefile simpler :-) -- 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
Re: COMPO
Steve, I cloned your Git repository. Instead of editing your Makefile to switch from your file structure to mine, I created a SCons build, using the separate compilation approach for now. with my 64-bit build of your code, I am seeing errors such as: acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int acomp.d(801): Error: cannot implicitly convert expression (p.children.length + 1LU) of type ulong to int acomp.d(857): Error: cannot implicitly convert expression (p.children.length) of type ulong to int so it looks like your code is 32-bit specific. I guess this is the ago-old problem of C, C++, D, etc. that int is the most natural size for the platform, code is inherently not as portable as you think. -- 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
Re: COMPO
Steve, I switched my SCons build to all at once: dmd -I/home/users/russel/lib.Linux.x86_64/GtkD_DMD/include/d/gtkd-2 -ofcompo about.d acomp.d arrow.d avery.d bevel.d brushdabs.d circle.d common.d compo.d config.d constants.d container.d controlsdlg.d controlset.d corner.d crescent.d cross.d csv.d curve.d deserialize.d drawing.d fader.d fancytext.d generic.d graphics.d heart.d interfaces.d keyvals.d lgradient.d line.d lineset.d mainwin.d menus.d merger.d mesh.d moon.d morphdlgs.d morphs.d morphtext.d noise.d partition.d pattern.d pglayout.d pixelimage.d pointset.d polycurve.d polygon.d printing.d random.d rect.d reference.d regpc.d regpoly.d rgradient.d richtext.d rsvgwrap.d separator.d serial.d serialize.d settings.d shapelib.d sheets.d strokeset.d svgimage.d tb2pm.d text.d textsrc.d tilings.d tree.d treeops.d triangle.d tvitem.d types.d uspsib.d acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int acomp.d(801): Error: cannot implicitly convert expression (p.children.length + 1LU) of type ulong to int acomp.d(857): Error: cannot implicitly convert expression (p.children.length) of type ulong to int avery.d(221): Error: cannot implicitly convert expression (this.sheets.length) of type ulong to int avery.d(672): Error: cannot implicitly convert expression (this.sheets.length) of type ulong to int controlset.d(224): Error: cannot implicitly convert expression (this.wia.length - 1LU) of type ulong to int csv.d(129): Error: cannot implicitly convert expression (atemp.length) of type ulong to int deserialize.d(257): Error: cannot implicitly convert expression (lastIndexOf(cast(const(char)[])this.fileName, /, cast(CaseSensitive)1)) of type long to int generic.d(48): Error: cannot implicitly convert expression (this.sheets.length) of type ulong to int generic.d(91): Error: cannot implicitly convert expression (this.sheets.length) of type ulong to int merger.d(728): Error: cannot implicitly convert expression (indexOf(cast(const(char)[])this.md.spec, cast(const(char)[])colSpec, cast(CaseSensitive)1)) of type long to int merger.d(735): Error: cannot implicitly convert expression (cast(ulong)pos + colSpec.length) of type ulong to int pglayout.d(316): Error: cannot implicitly convert expression (this.marked.length) of type ulong to int pixelimage.d(309): Error: cannot implicitly convert expression (lastIndexOf(cast(const(char)[])this.fileName, '/', cast(CaseSensitive)1)) of type long to int pointset.d(136): Error: cannot implicitly convert expression (this.po.oPath.length) of type ulong to int pointset.d(235): Error: cannot implicitly convert expression (this.po.editStack.length) of type ulong to int polycurve.d(75): Error: cannot implicitly convert expression (this.po.pcPath.length) of type ulong to int polycurve.d(184): Error: cannot implicitly convert expression (this.po.pcPath.length) of type ulong to int polycurve.d(328): Error: cannot implicitly convert expression (this.po.editStack.length) of type ulong to int polycurve.d(685): Error: cannot implicitly convert expression (this.pcPath.length - 1LU) of type ulong to int polycurve.d(1040): Error: cannot implicitly convert expression (this.pcPath.length) of type ulong to int scons: *** [compo] Error 1 scons: building terminated because of errors. I guess we should take this off this list and over to the GitHub issues? -- 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
Re: COMPO
On Sunday, 9 February 2014 at 09:36:15 UTC, Russel Winder wrote: Steve, I cloned your Git repository. Instead of editing your Makefile to switch from your file structure to mine, I created a SCons build, using the separate compilation approach for now. with my 64-bit build of your code, I am seeing errors such as: acomp.d(782): Error: cannot implicitly convert expression (parent.children.length + 1LU) of type ulong to int acomp.d(801): Error: cannot implicitly convert expression (p.children.length + 1LU) of type ulong to int acomp.d(857): Error: cannot implicitly convert expression (p.children.length) of type ulong to int so it looks like your code is 32-bit specific. I guess this is the ago-old problem of C, C++, D, etc. that int is the most natural size for the platform, code is inherently not as portable as you think. Thanks Russel. I suspected that would be the case - like you say, old habits die hard. I guess I'll have to install 64 bit Ubuntu on my laptop so I have somewhere to launder the code, and build 64 bit. Steve
Re: Opensourced my web server written in D
It was related to the update of std.process, I was using the 'bad way' just building a string and then executing it. Using the old API I could just get back the stdout and stderr as strings. And when the new API came in the old version got deprecated or something else I don't know exactly, it broke the execution of external code but the original code was bad code anyway. The new API is much cleaner and I now use the spawnShell command, which allows to use pipes. This means the server can read data in nice chunks, and that I could tweak the throughput/chunksize based on the amount accepted by a client. I could look up in the old repository when/where. but in general I dont mind a little breakage because in general bad code breaks.. Gr, Danny Arends http://www.dannyarends.nl On Friday, 7 February 2014 at 17:06:58 UTC, Martin Nowak wrote: On 02/03/2014 11:02 AM, Danny Arends wrote: I wrote a small web server in D to learn the language. It's not done yet (what software ever is) but I wanted to show it off anyway. As always of-course any feedback is welcome See it here: https://github.com/DannyArends/DaNode Gr, Danny Arends http://www.dannyarends.nl Sorry to read that a compiler update broke your code. http://www.reddit.com/r/programming/comments/1x0625/small_opensource_web_server_written_in_d/cf8ftqv It would be interesting to get some more feedback for this. What was the old and the new version? Do you remember what broke? Thanks, Martin
Re: Opensourced my web server written in D
On 02/09/2014 07:18 PM, Danny Arends wrote: It was related to the update of std.process, The new API is much cleaner and I now use the spawnShell command, which allows to use pipes. This means the server can read data in nice chunks, and that I could tweak the throughput/chunksize based on the amount accepted by a client. Interesting. I agree, the new std.process is so much better, that I didn't mind a few rewrites myself.
Re: Visual D 0.3.37 released
On 05.02.2014 22:47, Rainer Schuetze wrote: On 05.02.2014 13:21, Manu wrote: Any chance you can release a beta with that settings bug fixed? I've supervised 2 new VD installs the last couple of days, and they all suffer the problem with the mspdb dll path not being remembered in the exe path settings. I didn't have a lot of time lately, but I am close to recovering from the recent SSD crash and almost have a working system back up now (with a precise GC dmd). I really should have pushed branches more often to github... I have that settings bug fixed (saving to an registry entry but reading back a different one), so I hope I can create the new beta within the next couple of days. The new beta 0.3.38beta3 of Visual D is available here: https://github.com/D-Programming-Language/visuald/releases
Re: COMPO
On 8 February 2014 06:03, Steve Teale steve.te...@britseyeview.com wrote: A deb file of an early version of COMPO2 is now available at http://britseyeview.com/compo/. I'd appreciate some feedback from the Debian based users in the D community. It's not technical stuff, but it's an example of what can be done with D+gtkd2. Also, with a little tutoring, your kids might like it. I have to take a break from developing it, and write some documentation now. Looks like some old British twit has been taking the mushrooms again. This is all quite beyond me! ;-) Having a quick look at the source on github. I would suggest to not have a flat module hierarchy (ie: move them all into 'compo'). Regards Iain
Re: COMPO
On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote: Looks like some old British twit has been taking the mushrooms again. This is all quite beyond me! ;-) Having a quick look at the source on github. I would suggest to not have a flat module hierarchy (ie: move them all into 'compo'). Regards Iain You mean one humungous file?
Re: COMPO
I believe Iain is suggesting you put your source code into a folder called compo/. In Dub you would generally put the sources in Source/ then have project files in the root of the project folder Readme and License for example. On Mon, Feb 10, 2014 at 7:02 AM, Steve Teale steve.te...@britseyeview.comwrote: On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote: Looks like some old British twit has been taking the mushrooms again. This is all quite beyond me! ;-) Having a quick look at the source on github. I would suggest to not have a flat module hierarchy (ie: move them all into 'compo'). Regards Iain You mean one humungous file?
Re: COMPO
On 10 Feb 2014 05:06, Steve Teale steve.te...@britseyeview.com wrote: On Sunday, 9 February 2014 at 22:48:23 UTC, Iain Buclaw wrote: Looks like some old British twit has been taking the mushrooms again. This is all quite beyond me! ;-) Having a quick look at the source on github. I would suggest to not have a flat module hierarchy (ie: move them all into 'compo'). Regards Iain You mean one humungous file? Nope. Create a directory 'compo', move all sources I. The folder and update the module names from 'module text' - 'module compo.text'
