Re: COMPO
On Wednesday, 26 February 2014 at 00:43:58 UTC, John Colvin wrote: On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve John, I'm sorry. Trying to do too many things at the same time. libusps4cb is a binary provided by the US Postal Service for creating postal bar codes. They don't publish the source. I had the .a file for COMPO1, and that still seems to work OK, but they don't do static libraries any more, so for a 64 bit build you'll need to use libusps4cb.so. They are both in compo/lib on GitHub. The .a file is 32 bit, and the .so file 64 bit. Steve I will get the 32 bit .so file and regularize the situation However I go about building this, I get linker errors about libusps4cb.a Where can I find the source for this library? Or at the very least can you upload a x86_64 version?
Re: COMPO
Steve, Does compo2 allow you to add effects to layers? On Wed, Feb 26, 2014 at 10:26 AM, Steve Teale steve.te...@britseyeview.comwrote: On Wednesday, 26 February 2014 at 00:43:58 UTC, John Colvin wrote: On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve John, I'm sorry. Trying to do too many things at the same time. libusps4cb is a binary provided by the US Postal Service for creating postal bar codes. They don't publish the source. I had the .a file for COMPO1, and that still seems to work OK, but they don't do static libraries any more, so for a 64 bit build you'll need to use libusps4cb.so. They are both in compo/lib on GitHub. The .a file is 32 bit, and the .so file 64 bit. Steve I will get the 32 bit .so file and regularize the situation However I go about building this, I get linker errors about libusps4cb.a Where can I find the source for this library? Or at the very least can you upload a x86_64 version?
Re: COMPO
On Wednesday, 26 February 2014 at 08:41:29 UTC, Rory McGuire wrote: Steve, Does compo2 allow you to add effects to layers? A composition is: Container - Layer 1 - Layer 2 - Layer 3 ... The layers can be of any kind, including effects, though if they are not in a sensible order, opaque layers will hide layers underneath. A file can be: Composition 1 Composition 2 Layer 4 Layer 5 ... In any order. Layers in a composition may use other compositions or stand-alone layers (e.g. Layer 4) as fill, so in that sense, yes, you can add effects to a layer as long as the layer is a closed and fillable figure. All but one of the closed figure types are fillable. Steve
Re: COMPO
I've just had a hack at the structure of the GitHub repo. It is now, as suggested by Iain Bucklaw, less flat. The source is in a separate directory, and I've added a package.json file at the top level so COMPO can be built with DUB. I also updated the README file to talk about library dependencies, put both makefiles (32 and 64) in a makefiles directory, and added libusps4cb.so (see the README). I hope it is gradually getting more civilized. Steve
Re: COMPO
On Monday, 24 February 2014 at 16:30:43 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve However I go about building this, I get linker errors about libusps4cb.a Where can I find the source for this library? Or at the very least can you upload a x86_64 version?
Re: COMPO
On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve
Re: COMPO
Hi Steve, I would like to look just crazy busy at the moment. Are you just wanting feed back on the code or testing the app and criting the code? On 24 Feb 2014 18:35, Steve Teale steve.te...@britseyeview.com wrote: On Monday, 17 February 2014 at 17:56:08 UTC, Steve Teale wrote: On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation You must forgive me for harping on about this, but I am going to be persistent. Between COMPO 1 and COMPO 2, there's the best part, or more, of a man-year's work. So I won't let go lightly. Today I have posted two new .deb files (i386/amd64) on the COMPO web site - http://britseyeview.com/compo/. There's decent online documentation at the same place. The stage of operations is now QA, and since I am the author, you know that at this point, I need help ;=) The source code is also up-to-date on https://github.com/britseye/compo. Come on guys, give me an hour of your precious time. Steve
Re: COMPO
On Monday, 24 February 2014 at 18:08:34 UTC, Rory McGuire wrote: Hi Steve, I would like to look just crazy busy at the moment. Are you just wanting feed back on the code or testing the app and criting the code? What I need most is comment on the usability and scope of the application - am I wasting my time if I continue to work on it? If you think it's OK, then testing. It's always difficult to critically test your own application. You know how it works and what it's supposed to do, and that knowledge channels you. I mostly know where the code is a mess, and can fix that over time. At the moment I'm sticking to the old adage - if it ain't broken, don't mend it. Thanks Steve
Re: COMPO
On Monday, 17 February 2014 at 06:57:55 UTC, Steve Teale wrote: I would love to get some feedback on both the application and the documentation Have now done a dual-boot install of Ubuntu 12.04 64 bit, and built COMPO using that. Seems to pass limited sanity testing. Will make a .deb file tomorrow.
Re: COMPO
On Saturday, 8 February 2014 at 06:03:18 UTC, Steve Teale wrote: I have to take a break from developing it, and write some documentation now. OK, I have made some reasonably complete documentation, and that now replaces the COMPO stuff I had on the web at http://britseyeview.com/compo/. The binary that is available there is still just i386. My next job is to install Ubuntu 12.04 64 bit as dual boot on my machine, and attempt to build an amd64 version. The binary matches what is currently on GitHub. I would love to get some feedback on both the application and the documentation
Re: COMPO
:) ah right, you did say module. On Mon, Feb 10, 2014 at 9:11 AM, Iain Buclaw ibuc...@gdcproject.org wrote: 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'
Re: COMPO
On Monday, 10 February 2014 at 07:11:17 UTC, Iain Buclaw wrote: 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' Iain, I live in fear of fracturing CodeBlocks fragile project structure. But it's a good suggestion. I am frantically trying to get COMPO to a state of some usability, and built for Windows, with documentation, before I die. When I am calmer I will take up your point. It would probably help me in getting collaborators, and would suit DUB.
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: 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'
Re: COMPO
On Saturday, 8 February 2014 at 06:03:18 UTC, Steve Teale 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. I think it's a nice piece of work
Re: COMPO
On Sat, 2014-02-08 at 06:03 +, Steve Teale 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. I downloaded the deb file and put into my local deb repository. On update, the package appears to aptitude, but as an i386, 32-bit package. Although I am running a multiarch 64-bit Debian Unstable, compo was going to drag in 62 new i386 packages, which I'm afraid felt a bit to much to continue with. Can I suggest: 1. use the Debian package naming rules so that the version number and architecture are more standardly part of the name. 2. build a 64-bit amd64 package as well as a 32-bit i386 package. Thanks. -- 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
Trying to build from source, I run into missing 'mainwin.d' file. From the git history it seems like some time ago main.d was renamed to mainwin.d, but no mainwin.d seems to be present in the repository.
Re: COMPO
On Sunday, 9 February 2014 at 00:17:01 UTC, angel wrote: Trying to build from source, I run into missing 'mainwin.d' file. From the git history it seems like some time ago main.d was renamed to mainwin.d, but no mainwin.d seems to be present in the repository. I'll fix it.
Re: COMPO
On Sunday, 9 February 2014 at 05:48:06 UTC, Steve Teale wrote: On Sunday, 9 February 2014 at 00:17:01 UTC, angel wrote: Trying to build from source, I run into missing 'mainwin.d' file. From the git history it seems like some time ago main.d was renamed to mainwin.d, but no mainwin.d seems to be present in the repository. I'll fix it. Fixed now I hope. I had to change the name of main.d so I could write the stub compo.d file required by DUB. If I imported main into that, it clashed with main(). A bunch of changes were added at the same time, so what's there now should be the same as what created the current deb file.
Re: COMPO
On Saturday, 8 February 2014 at 17:32:05 UTC, Russel Winder wrote: 1. use the Debian package naming rules so that the version number and architecture are more standardly part of the name. 2. build a 64-bit amd64 package as well as a 32-bit i386 package. 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. a) How do I tell if my GCC version is multilib, b) Can I build a static 64 bit library - gtkd2 - on my 32 bit system. Thanks Steve
Re: COMPO - 2.064
On Wednesday, 29 January 2014 at 14:36:29 UTC, bearophile wrote: Steve Teale: I pushed changes to GitHub (https://github.com/britseye/compo) today that allow a clean build with warnings and deprecations on using DMD2.064. In similar projects I suggest to pull out some generally useful modules (like some geometry ones), making them independent, and making them available (with DUB or on GitHub). This allows other projects to re-use those modules and reduce their size. Bye, bearophile I'm 72 in April. I'd like to get what I started finished - including documentation - before I die. The source code is there, so if there are bits that are generally useful, people can cherry pick! Also, if I come across bits that I think are generally useful, like approximating a circle with Bezier curves, or using meshes, I try to write an article on my web page that separates it out. BTW, thank you for your consistent and continuing contributions to the development of D ;=)
Re: COMPO - 2.064
Steve Teale: I pushed changes to GitHub (https://github.com/britseye/compo) today that allow a clean build with warnings and deprecations on using DMD2.064. In similar projects I suggest to pull out some generally useful modules (like some geometry ones), making them independent, and making them available (with DUB or on GitHub). This allows other projects to re-use those modules and reduce their size. Bye, bearophile
