Re: stop to maitain rpm
On Monday, 12 August 2013 at 07:13:11 UTC, bioinfornatics wrote: I had release all rpm https://lists.fedoraproject.org/pipermail/devel/2013-August/187609.html if no one take it they will go out of fedora. I am lazy to explain that is not : - a build system or dub but - a build system and dub Firstly not everyone spent time to search their tool from cpan rvm pypi … Secondly when you want the lib A who need bib B who need … you appreciate to have it in your repo Third FHS rules and other was no create to annoyed dev… If D dev should to install a compiller next a lib A dev a little get another lib … that is easier when that is into repo . That help to brings new users when all is into a repo dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub. As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around.
Re: stop to maitain rpm
On 11/08/13 16:51, bioinfornatics wrote: Too many project is a nightmare to package. Developper do not see that dub is a tool to help user to get some D lib as is done in ruby python or perl. But dub is not for packaging! I am lazy to do this job and D packaging It's very sad hear that you leaves this great work. I'd like to hear you have changed your decision. Let me ask you if your motives are only the exposed up or there are another ones? Regards, -- Jordi Sayol
Re: stop to maitain rpm
On Sunday, 11 August 2013 at 17:15:52 UTC, David Nadlinger wrote: What would be nice, however, is to have these D-specific tools such as DVM, dub, … available in the distro repositories, preconfigured to fit the customs of the given system. This way, users could just do yum install dvm dub (or whatever other tools) to get a fully working D environment. I don't know how it is for other distros, but the newest dmd and ldc version are available in the Archlinux's [community] repository while gdc and dub are available in the AUR, meaning you get a fully working D environment on Archlinux by doing yaourt -S dmd dub or yaourt -S gdc dub or yaourt -S ldc dub (you could use any pacman-wrapper other than yaourt, as well of course) So far there isn't a dvm package (for Arch) that I can see, but if anyone where really interested he could do so, as the AUR anyone who registers an account may create (and maintain) new packages. - Moritz
Re: stop to maitain rpm
On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote: […] dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub. As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around. Anecdotal experience indicates this musn't be an or situation. From the Go experience, where this is furthest down the line in the native code arena (as far as I know): for Go having *both* operating system packaging *and* language specific packaging is the place to be. The same goes for Python as well. Having platform packaging, and individual machine packaging is wonderful. Platform packaging gives automated update, local packaging give the ability to get closer to the bleeding edge or stay behind the current platform packaging. So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc), as well as any other D infrastructure packages need to be packaged for Debian (which gives Ubuntu, Mint,…), Fedora (which gives RHEL, CentOS,… ), MacPorts, HomeBrew, any-others-as-well, and there needs to be a (possibly dub-based) way of having a personal local installation of things. Currently GDC is in Debian, but I have to get DMD from a private Debian repository instead of the official one, and I build LDC myself because the Debian package is too old. This measn having to have three versions of all the libraries and packages because each compiler requires it's own. This sort of situation is well supported via platform packaging and currently seems unsupported completely via D-specific things – but I may be missing something. Surely the issue that is arising here is that there isn't much communication and mutual support from the D community to the platform packaging ones for the various platforms. (Apart from GDC on Debian, which seems to be working fine now.) So shouldn't OPs email be a call to get D and it's packages front and centre for all package-based platforms *as well as* getting a D-specific packaging system that knows how to deal with GitHub, BitBucket and Launchpad (plus others) in place and core to the community. Go's set up works, where is D's? -- 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: stop to maitain rpm
On 12 August 2013 11:38, Russel Winder rus...@winder.org.uk wrote: On Mon, 2013-08-12 at 09:58 +0200, Mike Parker wrote: […] dub suits this purpose just fine. It's a build tool and a package manager. It can be used just like the various Linux package managers (dub install libname), but but it's even better in that you can skip that step entirely. List your project's dependencies in a package.json, and dub will automatically download and install them. Then they become available for every project you build with dub. As a library maintainer, I find this much cleaner than relying on different people to maintain packages for different package managers. dubs configuration integrates with my git repo. The responsibility for registering with the dub registry is on me and I can keep it up to date with a simple config file. Most importantly, it makes it more likely that more users are on the same version and they can easily get the latest bug fixes when I update git without any extra effort on my part. On every platform that dub supports, not just Linuxen. rpms, deb files and whatnot often fall behind in the official package repositories and each one is only available to a certain subset of Linux users. dub is just a better option all around. Anecdotal experience indicates this musn't be an or situation. From the Go experience, where this is furthest down the line in the native code arena (as far as I know): for Go having *both* operating system packaging *and* language specific packaging is the place to be. The same goes for Python as well. Having platform packaging, and individual machine packaging is wonderful. Platform packaging gives automated update, local packaging give the ability to get closer to the bleeding edge or stay behind the current platform packaging. So I think D (dmd, gdc, ldc) and Phobos (for each of dmd, gdc and ldc), as well as any other D infrastructure packages need to be packaged for Debian (which gives Ubuntu, Mint,…), Fedora (which gives RHEL, CentOS,… ), MacPorts, HomeBrew, any-others-as-well, and there needs to be a (possibly dub-based) way of having a personal local installation of things. Currently GDC is in Debian, but I have to get DMD from a private Debian repository instead of the official one, and I build LDC myself because the Debian package is too old. This measn having to have three versions of all the libraries and packages because each compiler requires it's own. This sort of situation is well supported via platform packaging and currently seems unsupported completely via D-specific things – but I may be missing something. You can now get GDC from debian unstable if you want to risk it for a biscuit. Not recommended for Debian stable, and look up apt-pinning for Debian testing releases. Regards Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: stop to maitain rpm
On Mon, 2013-08-12 at 11:41 +0100, Iain Buclaw wrote: […] You can now get GDC from debian unstable if you want to risk it for a biscuit. Not recommended for Debian stable, and look up apt-pinning for Debian testing releases. I am already on Debian Unstable with GDC 4.8.1-8 :-) I am though tending to favour LDC at the moment since I am building master/HEAD as the repository changes. It seems that you have to work with one and only one D compiler — but that sort of makes sense really. -- 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: stop to maitain rpm
On Monday, 12 August 2013 at 10:38:21 UTC, Russel Winder wrote: Anecdotal experience indicates this musn't be an or situation. Perhaps. My response in this thread derived from a brief exchange Jonathan and I had over at github. In packaging Derelict for Fedora, he had been relying on a pull request I accepted from him some time ago that added shared library support to the Derelict build script. I decided to remove it as it has fallen out of sync with the static builds now and again and it was only there for his use. At any rate, as part of my plans to restructure the project, I'm going to drop the build script and rely on dub exclusively. From his post here coming so soon after our exchange, I get the impression that I may not be the only one he's heard that from. As long as packaging the various distros doesn't require any constraints on how I manage my projects, then it doesn't matter too much to me where or how people package it up. However, I do see benefits to promoting dub as the means to build up the D ecosystem. Then it's a central, goto location for D libraries and everybody's on the same page. As long as dmd/gdc/ldc and dub are available via the distro packages, that's all that really matters
Re: stop to maitain rpm
On Monday, 12 August 2013 at 13:06:46 UTC, Mike Parker wrote: As long as packaging the various distros doesn't require any constraints on how I manage my projects, then it doesn't matter too much to me where or how people package it up. However, I do see benefits to promoting dub as the means to build up the D ecosystem. Then it's a central, goto location for D libraries and everybody's on the same page. As long as dmd/gdc/ldc and dub are available via the distro packages, that's all that really matters From the point of view of packager I'd say there are 2 key issues here: 1) Developers tend to forget that tools like `dub` are for taking care of dependencies during development and end users won't have `dub`. Even if it is a library, dynamic linking implies that it will be pulled as a dependency not only by developers. That may result in complications for integrating package into existing package system. Sometimes. 2) `dub` is still quite immature when it comes to target path configuration (unless I have missed some changes) - converting its build output to FHS is not always convenient. In my opinion, though, those are mostly quality of implementation issues, nothing fundamental. Can't say how much troubles does this really cause right now, have not tried to package anything like Derelict yet.
Re: stop to maitain rpm
I don't know how it is for other distros, but the newest dmd and ldc version are available in the Archlinux's [community] repository while gdc and dub are available in the AUR, meaning you get a fully working D environment on Archlinux by doing LDC is in [community] already, and iirc Dicebot is working on getting GDC into [community], too
Re: glad OpenGL loader generator
Am 12.08.2013 07:06, schrieb evilrat: On Monday, 5 August 2013 at 21:42:59 UTC, David wrote: glad - is an OpenGL loader (with experimental gles support, --api=gles2) ... i looked at this on github and see an option to build with gl3n, then i see what it is, and looks like gl3n is a 'must have' for my simple tasks. but for some reason it only builds with -m32 on OS X, i can't see where it puts this flag in makefile and why do the hell it inserts this. can you help explain how to get rid off this? Mh, there is no option to interact with gl3n, gl3n is completly independent from glad/glamour/derelict. Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX.
Re: stop to maitain rpm
On Monday, 12 August 2013 at 13:46:52 UTC, David wrote: LDC is in [community] already, and iirc Dicebot is working on getting GDC into [community], too Actually I am simply waiting until my PGP key gets signed by at least 3 Arch Linux master keys :) Will make announcement about all package changes and yummies once done.
Darwin 32 release broken (in uni.d)
It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead?
Re: stop to maitain rpm
On Monday, 12 August 2013 at 13:38:11 UTC, Dicebot wrote: 1) Developers tend to forget that tools like `dub` are for taking care of dependencies during development and end users won't have `dub`. Even if it is a library, dynamic linking implies that it will be pulled as a dependency not only by developers. That may result in complications for integrating package into existing package system. Sometimes. That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm.
Re: Article: Increasing the D Compiler Speed by Over 75%
Another little observation: Dsymbol::toPrettyChars() potentially calls toChars() twice on each symbol (so it creates 2 copies of the string representation). Some instances of toChars() just return a literal string, but for templates it can do a bunch of work. Doesn't sounds like the most efficient approach? Saying that though, it looks like a lot of the calls to that are to build error strings that are never displayed because errors are gagged, which doesn't sound ideal either?
Re: stop to maitain rpm
On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote: That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm. Yeah, but imagine creating hard dependency on certain library version in sources (with no real need, something like too specific SONAME) - it requires package maintainer not only to keep bundling script, but also to patch project sources before building. Something maintainers are usually not happy to do :) It is not that common but forgetting that user environment will be different from yours is kind of easier with all the convenience `dub` brings you. In general I think keeping packager and developer duties separate is a good/right thing, however, it is much easier when developers think about binary dependencies separately from source ones.
Re: stop to maitain rpm
On Monday, 12 August 2013 at 15:39:59 UTC, Dicebot wrote: On Monday, 12 August 2013 at 14:34:04 UTC, Mike Parker wrote: That's true. But, correct me if I'm wrong, rpms and the like are bundled independently of the original source repository. So a project relying solely on dub doesn't stop a package maintainer from keeping a separate build script to bundle with the rpm. Yeah, but imagine creating hard dependency on certain library version in sources (with no real need, something like too specific SONAME) - it requires package maintainer not only to keep bundling script, but also to patch project sources before building. Something maintainers are usually not happy to do :) It is not that common but forgetting that user environment will be different from yours is kind of easier with all the convenience `dub` brings you. In general I think keeping packager and developer duties separate is a good/right thing, however, it is much easier when developers think about binary dependencies separately from source ones. My view may indeed be heavily tinted by Windows, where this sort of thing just isn't an issue to care about. I suppose I'll have to adjust that a bit.
Re: stop to maitain rpm
On Monday, 12 August 2013 at 15:55:10 UTC, Mike Parker wrote: My view may indeed be heavily tinted by Windows, where this sort of thing just isn't an issue to care about. I suppose I'll have to adjust that a bit. Hah, yeah, I guess the very understanding of user-distributed package is very different between various OS users. As far as I remember, it was considered a normal practice to pack all used shared libraries with programs installation in Windows (ignoring shared part) - something that is allowed in Linux repository packages only in absolutely exceptional cases. And Mac OS is somewhere in between.
Re: stop to maitain rpm
On 2013-08-12 12:38, Russel Winder wrote: Currently GDC is in Debian, but I have to get DMD from a private Debian repository instead of the official one, and I build LDC myself because the Debian package is too old. This measn having to have three versions of all the libraries and packages because each compiler requires it's own. This sort of situation is well supported via platform packaging and currently seems unsupported completely via D-specific things – but I may be missing something. DVM installs each compiler in its own directory. Although you have to manually put libraries and imports in the correct directories. It also currently only supports DMD. -- /Jacob Carlborg
Re: glad OpenGL loader generator
On Monday, 12 August 2013 at 13:45:46 UTC, David wrote: Did you confuse gles2 (GL ES 2.0) with gl3n? Or did you speak of glamour, which has indeed gl3n interaction, which can be turned on with -version=gl3n: make DCFLAGS+=-version=gl3n. But I recommend you to include gl3n and glamour as submodule or if you don't use git, simply the sources. This makes your code independent of a systemwide installation and it's only a few files. glad is a replacement for Derelicts GL bindings. Soon it will also provide a EGL support (which should already work), WGL and GLX. no no, i don't want use other opengl bindings right now, derelict just fine, but i need some good(public available) math lib to put in my examples, and the problem is that gl3n compiles as 32 bit(-m32) on OS X(i use it because i don't have PC and i don't know when i would have it) by default and there seems no way to remove this misbehavior :(
Re: Darwin 32 release broken (in uni.d)
12-Aug-2013 17:57, monarch_dodra пишет: It looks like the darwin 32 release is broken at the phobos unittest stage. It would appear the breakage is in the uni.d debug step: make[1]: *** [generated/osx/debug/32/unittest/std/uni] Segmentation fault: 11 I don't think it is the new uni module that is responsible, since it worked fine when it was merged. I haven't pinned down which pull triggered the breakage, but I figure the first step to getting the release fixed is to announce it as broken. Or I should file a report instead? That's right but ... In the phobos mailing list next time :) -- Dmitry Olshansky
