Re: Travis-CI support for D
On 12/14/2014 03:03 PM, Ellery Newcomer wrote: On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ trying it out with pyd, and I'm getting ImportError: libphobos2.so.0.66: cannot open shared object file: No such file or directory are shared libraries supported? .. I'll take that as a no, then.
Re: Travis-CI support for D
On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. http://blog.travis-ci.com/2014-12-10-community-driven-language-support-comes-to-travis-ci/ trying it out with pyd, and I'm getting ImportError: libphobos2.so.0.66: cannot open shared object file: No such file or directory are shared libraries supported?
Re: Travis-CI support for D
On 12/10/2014 08:50 PM, Martin Nowak wrote: Glad to announce that D support on Travis-CI was launched today. I'm a noob when it comes to travis, so it isn't readily apparent to me, but given this, would travis support a build that installs a d compiler and also some version of python?
Re: GDC ARM beta #1 (with binary releases!)
On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
I'm happy to announce the first GDC ARM beta on behalf of the
GDC
team :)
Cool!
Just tried building it with crosstools-ng on my poor old laptop,
and 90 minutes in it gives me
/home/ellery/Downloads/pitools/.build/src/gcc-custom/libphobos/libdruntime/core/threadasm.S:387:
Error: selected processor does not support ARM mode `vpop
{d8-d15}'
Any thoughts? My guesses are 1. set Default Instruction Set to
thumb (?) or 2. the submodules didn't update on git pull. But
I've gotten a working compiler out of this config before, from
Mr. Pfau's fork a few months ago, so prolly not 1.
I'd test these myself, but I don't have a spare 180 minutes
tonight..
gdc-4.8 branch; gcc-4.8.1, should be the linaro source, but not
sure
Re: Fedora RPMs
On 11/19/2013 12:14 AM, Dejan Lekic wrote: by gum, I think you did it right too. I can build a shared lib straight out of the box. Well, unittests seem not to be running, and I'm sure they were a release or two ago. we'll see. I did not check unittests to be honest, will do that later. Well, don't worry too much; I'm doing Unsupported Things: https://bitbucket.org/ariovistus/pyd/src/32cf9709d711bd447941be4e11e09727d8747b7c/examples/misc/dmd_sharedlibs/?at=default But I checked, the unittest definitely ran in dmd 2.063.2 with my build at least. I also noticed some odd compilation failures so had to revert to above build. When I get done with my custodial work on pyd (which might take a while), I'll switch back to your rpms and poke around more.
Re: Fedora RPMs
On 11/18/2013 05:11 PM, Dejan Lekic wrote:
Hello everybody.
I have just committed few changes to https://www.gitorious.org/dejan-
fedora that allow you to build functional RPMs on your Fedora 19 systems.
I will aim for now to support F19, F20, EL5 and EL6. If someone needs
support for something else, please send patches or just simply come to IRC
and let me know what is the problem. :)
this is pretty nice setup you got here.
Few remarks - SPEC file expects source files to be on http://ddn.so/
files/ . I hope our release manager, or so-called build master will
make sure dlang.org provides source tarballs of dmd, phobos, druntime and
tools the same or similar way I have them on http://ddn.so/files/ (btw,
you can't browse it yet, but you can download files).
would it be possible to link to appropriate github repo changesets using
git submodule, and then generate the tarballs from those?
I use the simple get-files.sh (located in the dmd directory in the dejan-
fedora repo) to get those release tarballs from GitHub.
Finally, I decided to be little bit adventurous and made the SPEC file
generate dmd.conf with -defaultlib=libphobos2.so flag in DFLAGS.
by gum, I think you did it right too. I can build a shared lib straight
out of the box. Well, unittests seem not to be running, and I'm sure
they were a release or two ago. we'll see.
Following Fedora package guidelines, I provide static library in the
libphobos-static package instead.
lovely. wait, 42 megabytes? there's one file in that package.. wow.
So far it all works fine. I did not test the i686 packages yet, they
should work. :)
Kind regards, and I hope you find this useful as much as I do.
Me too, I'm sick of maintaining my own buildscripts.
A few suggestions:
/usr/share/d/samples is in dmd-...-{architecture???}, shouldn't they be
in a noarch package, like libphobos-devel?
shouldn't dmd require libphobos-devel rather than libphobos?
libphobos installs libphobos.so.2.064; shouldn't it have also installed
libphobos2.so.2.064.2, cuz you know, this is dmd 2.064.2, and also most
libs in my /usr/lib seem to follow the format libname.so.x.y.z
no dustmite? waaa.. ok fine.
From my own experience, I believe you are going to want
Requires: glibc-devel(x86-32)
Requires: glibc-devel(x86-64)
in the dmd package to ensure -m32/-m64 work properly
feel free to take any more from
https://bitbucket.org/ariovistus/rpm-buildscripts/src/21921c736116a51f60db4ab9cb5852fc0ae0b63c/dmd-git2rpm
I don't know if those Provides are necessary, but I do remember it took
me a frustrating amount of time to get the 64 bit one right.
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 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: dmd 2.063 released with 260 bugfixes and enhancements
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
Re: dmd 2.063 released with 260 bugfixes and enhancements
On 05/30/2013 08:16 AM, Andrei Alexandrescu wrote: Hello, We are pleased to announce that dmd 2.063, the reference compiler of the D programming language, is now available for download for OSX, Windows, and a variety of Unixen: The rpm package doesn't make the appropriate links in /usr/lib, so when I try to build a shared library, at runtime it issues ./test1d: error while loading shared libraries: libphobos2.so.0.63: cannot open shared object file: No such file or directory I would assume the deb package has the same shortcoming
Re: dmd 2.063 released with 260 bugfixes and enhancements
On 05/31/2013 12:32 PM, Russel Winder wrote: On Fri, 2013-05-31 at 12:19 -0700, Ellery Newcomer wrote: […] I would assume the deb package has the same shortcoming I have not seen this with the deb on Debian Unstable. just tried it on ubuntu 12.10, and it does the same. are you using -defaultlib=libphobos2.so ?
Re: dmd 2.063 beta 5
On Tuesday, 21 May 2013 at 20:36:20 UTC, Walter Bright wrote:
Join the dmd beta mailing list to keep up with the betas. This
one is pretty much good to go, unless something disastrous
crops up.
http://ftp.digitalmars.com/dmd2beta.zip
Remaining regressions:
http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED
repost in case the ether ate the last one
just tried building a shared lib with
dmd -fPIC -defaultlib=phobos2so -shared {infiles} -of{outfile}
on ubuntu 12.10 64bit.
during link, it wants libphobos2so.so, but during run it wants
libphobos2.so.0.63
Re: Unmanaged - a D framework on github
On 03/13/2013 11:30 AM, D-ratiseur wrote: uppon everything to bypass the garbage collector. In that case, I call foul. FAddr.length = FAddr.length + 1; types.d#L281 Wait, what? You're using classes everywhere and.. ohhh. you're overriding new. Nifty. Don't know if that's been deprecated or not, but I'm pretty sure Andrei hates it and wants it to die. The delete statement is deprecated in favor of object.destroy or something. For struct ULongRec, shouldn't some of your twiddly stuff be wrapped in version(LittleEndian) ?
Re: ldc new feature
On 12/08/2011 06:52 AM, bioinfornatics wrote: Dear, I am pleased to announce the new features. LDC is now offering the flag-shared-lib and libraries to create static and dynamic. The latest version of ldc works with llvm 3.0 and uses dmdfe 2056. The project ldc sees increased the number of contributors, the team ldc thank each of you for your help and feedback. Feel free to contribute to the project. A big thank you and sokol klickverbot for their excellent work $ ldc2 test.d -oftestd.so -shared or $ ldc2 -c test1.d test2.d $ ld -r test1.o test2.o -o merged.o $ ldc2 merged.o -oftestd.so -shared very nice. will this find its way into fedora repo?
Re: dmd 1.063 and 2.048 release
On 08/11/2010 02:15 AM, Walter Bright wrote: This is probably the last FreeBSD 7 release for D1. The next will be for FreeBSD 8! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.063.zip http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.048.zip Just tried the rpm. It won't install on 64 bit fedora because there is a 32 bit gcc constraint in the rpm. In my experience, dmd has always worked fine with 64 bit gcc.
Re: SQLite 3.6.23.1 wrapper + connector
On 07/18/2010 11:20 PM, awishformore wrote:
I think an empty array/string is safer to return than null.
It doesn't matter. D treats 'null' arrays exactly the same as empty
arrays. Just think of a 'null' array as {length=0, ptr=null}
Re: SQLite 3.6.23.1 wrapper + connector
On 07/18/2010 06:22 PM, BLS wrote: On 19/07/2010 00:57, dsimcha wrote: Given that sqlite is in the public domain, maybe Phobos should eventually include SQLite + a nice D-ish wrapper for it, so that people can use it w/o creating dependency hell in their projects. Agreed, even a very popular and commercial multi OS RAD Tool called Real Basic comes bundled with SQLite. Let's use this excellent tool instead of the thick openrj stuff, we had before. -bjoern I thought Qt does, too. Python definitely does, and I've actually been using it a lot lately. One thing I noticed when switching my code from postgresql to sqlite is that their respective python libraries use different parameter styles. Otherwise, it was completely painless. I'd love to see sqlite distributed with D, but not before a good DB API specification (not to disparage awishformore's work, of course).
Re: SQLite 3.6.23.1 wrapper + connector
On 07/18/2010 05:44 PM, awishformore wrote: Hello there. I've converted the .h file of the latest SQLite version to .d and I thought I'd let the world know (as suggested on IRC ;). Maybe it will save someone some work. I've also written a nice connector class that wraps all the C functions for convenient use in your application. It's very basic, but I will probably add more features (like automatic preparation of statements and automatic caching of several prepared statements) later. For the time being both files are included in the download: http://nexunity.com/sqlite4d.rar btw, would it be possible to distribute as something other than a rar? I wanted to have a peek at what you've done, but apparently nothing on my [linux] system can read that file.
Re: SQLite 3.6.23.1 wrapper + connector
On 07/18/2010 09:20 PM, Jonathan M Davis wrote:
On Sunday 18 July 2010 19:10:35 Ellery Newcomer wrote:
btw, would it be possible to distribute as something other than a rar? I
wanted to have a peek at what you've done, but apparently nothing on my
[linux] system can read that file.
While I hate rar, every distribution than I have used has had unrar. There's a
decent chance that it isn't installed by default though.
- Jonathan M Davis
Hmm. I suppose I could have spent more than 2 seconds trying to open it.
You're right on both counts.
As for the code, I'm looking at SQLiteConnector.ptrtostr. Does reserve
really work that way? Just curious - I wouldn't know one way or the
other, although I would probably use something more like
string ptrtostr(char* ptr, int size = 0){
return ptr ? ptr[0 .. size].idup : null;
}
Re: Fedora 14 to include D compiler
On 07/13/2010 12:57 PM, Walter Bright wrote: http://www.reddit.com/r/programming/comments/cp2qj/fedora_14_to_include_llvmbased_d_compiler/ Mildly curious: who uses fedora around here?
Re: fedora will get ldc and tango in official repo
On 06/26/2010 07:07 AM, bioinfornatics wrote: previously i have write this message in D.gnu but is maybe better here. I�am�a�fedora�packager�ldc�compiler�and�tango�will�be�go�in�official�fedora�repo.�People�who�want�learn�or�advanced�programmer�can�use�Fedora�for�develop�D�application. I�put�here�a�temporary�link�to�b�ta�src.rpm and spec file: - http://bioinfornatics.fedorapeople.org/ Note: if�a�mandriva�or�suse�packager�want�adapt�and�push�to�official�repo�(follow�changelog�;-)�) Nice. When?
Re: D rpm packages for Linux
On 06/25/2010 03:49 PM, Jordi Sayol i Salomó wrote: No, I don't have my reference to this. You do NOT have multiple packages modify the configuration file! You can either choose a master packagethat provides a program to manage the configuration file, or you put that program in a new package which everyone would depend on. This is the practice recommended for building Debian packages. Really? If You installs dmd and after installs a gtkd package. How do gtkd give dmd the Include dirs, lib dirs, etc.? Do You really thinks that dmd.conf contained on dmd package has to contain all configurations for all the installable packages pending on dmd? I know that this is the recommended practice for building Debian packages, but a debian packager told me that the only way to do that is handle the dmd.conf with preinst, prerm, postinst and postrm scripts. maybe an alternative would be to just define /usr/lib/dmd-xxx/ /usr/include/dmd-xxx/ and in dmd.conf: [Environment] DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx and have any additional library put its stuff directly in those two directories?
Re: D rpm packages for Linux
On 06/26/2010 09:46 AM, Jordi Sayol i Salomó wrote: maybe an alternative would be to just define /usr/lib/dmd-xxx/ /usr/include/dmd-xxx/ and in dmd.conf: [Environment] DFLAGS = -L-L/usr/lib/dmd-xxx -I/usr/include/dmd-xxx and have any additional library put its stuff directly in those two directories? here are missing the linkerflags for the linker eh?
Re: D rpm packages for Linux
On 06/25/2010 03:46 AM, Jordi Sayol i Salomó wrote: Many thanks for Your answer. This rpm package is build for a i386 platform, and it's only installable on a i386 system (without force it to), so the dependencies are for i386 installation. Of course It can be forced to install in another platform as x86_64, alpha, arm, hppa, mips, mipsel, powerpc, s390, sparc, etc. but I cannot assure that the compiler will work on all of them. Well, yeah, but from personal experience I can attest that dmd works fine on x86_64 (as does, like, every other 32 bit package), and dmd works fine with 64 bit gcc. at least on my install (fedora 13 - what do you use?). You talk about the glibc-devel package, but this is not the only one needed by the compiler, dmd also needs gcc (32 bits) and in Your rpm (as in mine) do not specifies anything about arch, also there is a missing library on Your rpm, libgcc_s.so.1 is needed too by dmd. Really? The gcc dependency doesn't automatically bring in libgcc? Is that what the GCCVER2 business is about? One solution for this problem is to explain the trick needed to install the ix86 dmd rpm package on a x86_64 system, as Walter has done with the same situation for the dmd deb package, http://www.digitalmars.com/d/2.0/dmd-linux.html#installation The trick for doing this on fedora 86_64 is just yum install gcc glibc-devel.i686 and then putting dmd wherever. Works fine. Another one is to create a x86_64 rpm package of dmd 32 bits compiler. I don't like this solution because when dmd 64 bits appears in the near future, this will be a source of confusion. yeah, don't do that. And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too. I've never found a need to do this (and I also don't know how). I apologize for my bad English. Best regards,
Re: D rpm packages for Linux
On 06/25/2010 10:45 AM, Jordi Sayol i salomó wrote: I use Ubuntu 9.10 i386, and there are a lot of 32 bit packages that do not works on a 64 bit system without a previous trick (installing some 32 bit library packages, etc.) But doesn't your package manager automatically take care of those dependencies? Well, can You assure that in all rpm Linux systems (not only in Fedora/red-hat) everything needed will be installed? From another point of view, if You think that the libgcc_s.so.1 will be automatically installed, Why Your rpm has these other libraries on the Requires (dependencies) tag? libc.so.6, libm.so.6 and libstdc++.so.6 Don't know. I didn't put them there. All I have is Requires: glibc-devel(x86-32) Requires: gcc Other stuff must have gotten added by the rpm build somehow. And My preferred solution, create a i386 chroot machine inside Your x86_64 system, install dmd package on it and compile Yours D programs on it too. I've never found a need to do this (and I also don't know how). Try it! is clean, easy and faster than other virtual machines, for text mode. I don't know how to install it in Fedora. Does it allow different versions of your OS, or just different architectures? More generally, what is it? :) In Ubuntu just install debootstrap. On Debian-like systems, chroot is used to build/compile packages for other architectures than the host system, if it is possible. Another thing about the creation of dmd rpm package. As You know, dmd.conf is a configuration file, and so, it can be changed by another future packages (i.e. gtkd o qtd) or by the final user. I think is not a good solution to just put it on the place, otherwise You have to make some checks during the package installation, upgrading and removing process. Check if the file exist, if not, create it, if exist, modify it to assure that dmd will properly compile, etc. How much of that does the %config directive take care of? Finally, I do my best to build these packages but, of course, I make a lot of mistakes, hope you tell me what can be corrected/improved. And from my side, this is not a competition on who creates the best dmd package, I just want to have a minimal quality dmd packages to easy install/remove on my system. If You do the job, I'll be very happy to enjoy it. Best regards,
Re: D rpm packages for Linux
On 06/25/2010 02:26 PM, Neal Becker wrote:
I'm pretty sure you can put the Requires within an if clause
Here's an example I have with BuidRequires (from emacs.spec)
%ifarch %{ix86}
BuildRequires: setarch
%endif
does that predicate on the target OS architecture or the package's
target architecture?
Re: D rpm packages for Linux
On 06/24/2010 12:22 PM, Andrei Alexandrescu wrote: On 06/24/2010 12:09 PM, Walter Bright wrote: D rpm packages now available http://www.digitalmars.com/d/download.html thanks to Jordi Sayol. Yay! I should mention that Ellery Newcomer also had an independent solution. (Sorry Ellery; I'm sure the learning experience was still useful.) Andrei Also note that mine doesn't fail on x86_64 (you need to add glibc-devel(x86-32) specifically as a dependency)
Re: D rpm packages for Linux
On 06/24/2010 12:09 PM, Walter Bright wrote: D rpm packages now available http://www.digitalmars.com/d/download.html thanks to Jordi Sayol. Also, what about hosting a yum repository?
Re: D rpm packages for Linux
On 06/24/2010 08:40 PM, Andrei Alexandrescu wrote: On 06/24/2010 03:44 PM, Ellery Newcomer wrote: On 06/24/2010 12:09 PM, Walter Bright wrote: D rpm packages now available http://www.digitalmars.com/d/download.html thanks to Jordi Sayol. Also, what about hosting a yum repository? Is that the thing that allows me to insert a line in the Synaptic repositories and then benefit of integration goodies? I'd love something like that. Andrei Ummm.. maybe? Yum is a package manager built on top of rpm, essentially red hat's counterpart to apt-get. I think the idea is each version of dmd as an rpm lives in the yum repository, and as new versions are released, the yum will semi-automatically upgrade the user's install. The nice thing about it is the user doesn't have to go around looking for the download each time the next release of dmd comes out, although they do have to initially configure their system. Typically, the repository host provides a downloadable rpm which performs that action. I don't know that it would be particularly useful for synaptic based linuxen (Andrei, see what you've got me doing?) though. Guess we'd have to make a synaptic repo too.
Re: D rpm packages for Linux
On 06/24/2010 01:14 PM, Jordi Sayol i Salomó wrote: En/na Ellery Newcomer ha escrit: Also note that mine doesn't fail on x86_64 (you need to add glibc-devel(x86-32) specifically as a dependency) Can You be more explicit? I've not a 64 bit system available. dmd links to ctnrl.o or something like that, which is in glibc-devel and must be 32 bit. If the 32 bit version ain't there, there be linker errors on compile. in the spec file, after Requires: gcc add Requires: glibc-devel(x86-32) I know nothing of specific minimum version or anything like that, though.
Re: dcollections 1.0 and 2.0a beta released
On 05/21/2010 09:14 AM, Steven Schveighoffer wrote: Second, since reference types are the right thing to do, classes are much easier to deal with. I know AA's are reference types that are structs, but the code needed to perform this feat is not trivial. The AA has only one member, a reference to the data struct, which is allocated on the heap. Any member function/property that is used on the AA must first check whether the implementation is allocated yet. The only benefit this gives you IMO is not having to use 'new' on it. And even that has some drawbacks. For example, pass an empty AA by value to a function, and if that function adds any data to it, it is lost. But pass an AA by value with one element in it, and the new data sticks. A class gives you much more in terms of options -- interfaces, builtin synchronization, runtime comparison, etc. And it forces full reference semantics by default. I think regardless of whether interfaces are defined for dcollections, classes give a better set of options than structs. Wow. A partially-nullable type. Great. Now I have to review everywhere I ever used an AA. Thanks, D. is there any serious drawback to something like (int[int]).init = InitializedAA!(int,int) ?
Re: dcollections 1.0 and 2.0a beta released
On 05/21/2010 11:55 AM, Ellery Newcomer wrote: On 05/21/2010 09:14 AM, Steven Schveighoffer wrote: Second, since reference types are the right thing to do, classes are much easier to deal with. I know AA's are reference types that are structs, but the code needed to perform this feat is not trivial. The AA has only one member, a reference to the data struct, which is allocated on the heap. Any member function/property that is used on the AA must first check whether the implementation is allocated yet. The only benefit this gives you IMO is not having to use 'new' on it. And even that has some drawbacks. For example, pass an empty AA by value to a function, and if that function adds any data to it, it is lost. But pass an AA by value with one element in it, and the new data sticks. A class gives you much more in terms of options -- interfaces, builtin synchronization, runtime comparison, etc. And it forces full reference semantics by default. I think regardless of whether interfaces are defined for dcollections, classes give a better set of options than structs. Wow. A partially-nullable type. Great. Now I have to review everywhere I ever used an AA. Thanks, D. is there any serious drawback to something like (int[int]).init = InitializedAA!(int,int) ? Or should one just always give an AA param either a const or ref modifier?
Re: dcollections 1.0 and 2.0a beta released
Are the collections supposed to not have isEmpty members? Looking forward to using dcollections, and here's to hoping they make it into phobos. OTish: What are your thoughts on a bimap implementation and a child/sibling or general tree implementation as part of dcollections?
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 03:07 PM, Steven Schveighoffer wrote: Ellery Newcomer Wrote: Are the collections supposed to not have isEmpty members? No. Use length == 0. O(1) length is always supported for all collections. OTish: What are your thoughts on a bimap implementation and a child/sibling or general tree implementation as part of dcollections? I haven't the slightest what a bimap is :) I am not an expert in collections or data structures, I just reimplement things I have understood. My implementations are basically copied from my algorithm book, and refined as much as I can do. I think boost.bimap is where I saw it, though I don't don't use c++. I think it's a map, with values-keys is also a map That being said, if you have any implementation of a tree or hash, it should be easy to insert into dcollections. If you have ideas for other collection types (i.e. other than Map, Set, Multiset or List), then I can look into that if you point me at an implementation or have one of your own. I purposefully left out multi-map because I've never had a huge use for it, and it seemed like a awkward thing to create an interface for... -Steve I have a simple child/sibling tree implementation which I could probably dust off and polish up if you want it. The method for visiting the elements is kind of weird, though. And I don't know that it exactly fits the mold of a reference container. Maybe with cursors. Ugh, I just noticed LinkList doesn't work with interfaces.
Re: dcollections 1.0 and 2.0a beta released
On 05/19/2010 03:55 PM, Steven Schveighoffer wrote:
Ellery Newcomer Wrote:
I have a simple child/sibling tree implementation which I could probably
dust off and polish up if you want it. The method for visiting the
elements is kind of weird, though. And I don't know that it exactly fits
the mold of a reference container. Maybe with cursors.
With opApply, you should have few restrictions on iteration. Technically,
cursors are optional since they are part of the concrete class, but it probably
wouldn't make it into dcollections proper without them.
When I was using it, it was usually more than an iteration that I found
I needed. I think I had preorder traversals and postorder traversals
with the ability to define actions at parent - child, child - sibling,
and child - parent transitions, access to the stack and some of the
history of what had been visited. On the whole, it required heavy
exposure of the structure of the tree. A wrapper around the tree nodes
doesn't make a lot of sense, and if you don't have a wrapper, cursors
don't really make a lot of sense either.
Random thought: wouldn't a child/sibling tree be a good base for
implementing tries?
Ugh, I just noticed LinkList doesn't work with interfaces.
You mean
interface I {}
auto list = new LinkList!I;
??
Please file a ticket w/ test case, it should work.
-Steve
indeed it should, but D doesn't like you :)
http://www.dsource.org/projects/dcollections/ticket/4
Re: dmd 1.057 and 2.041 release
On 03/09/2010 05:53 AM, Steven Schveighoffer wrote: On Mon, 08 Mar 2010 17:52:25 -0500, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Printing values with spaces between them is entirely fine for e.g. all numbers. You know what, you are right. Why should phobos cater to people wanting to print something as arcane as a string array, or a multi-dimensional array. People have no business using such constructs, they should be punished by having to write their own routines. It's all one-dimensional arrays of numbers for me from now on! -Steve and formatted in hex
Re: D compiler as part of GCC
On 01/27/2010 03:40 PM, Eldar Insafutdinov wrote: Google's Go will be in GCC. http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html . They are pushing it very hard. I bet it helps that Go was originally implemented as a front-end to GCC
Re: D compiler as part of GCC
On 01/27/2010 11:24 PM, Joel C. Salomon wrote: On 1/27/2010 5:56 PM, Ellery Newcomer wrote: On 01/27/2010 03:40 PM, Eldar Insafutdinov wrote: Google's Go will be in GCC.http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html. I bet it helps that Go was originally implemented as a front-end to GCC I’d thought the original compiler was based on Ken Thompson’s C compiler for Plan 9. —Joel Salomon Meh, one of the two
Re: The Thermopylae excerpt of TDPL available online
Andrei Alexandrescu wrote: Ellery Newcomer wrote: Andrei Alexandrescu wrote: It's a rough rough draft, but one for the full chapter on arrays, associative arrays, and strings. http://erdani.com/d/thermopylae.pdf Any feedback is welcome. Thanks! Andrei Maybe I haven't been paying attention lately, but shouldn't assert(x == 0) be assert(x[] == 0) ? Where does the former occur? Thanks, Andrei top of page 102
Re: dmd 1.050 and 2.035 release
Walter Bright wrote: Bugzilla 1534: Can't mix in a case statement. Woo hoo!
Re: dmd 1.043 alpha for FreeBSD 7.1
Walter Bright wrote: Now works for FreeBSD 7.1! http://www.digitalmars.com/d/1.0/changelog.html http://ftp.digitalmars.com/dmd.1.043.zip The D2 version for FreeBSD isn't ready yet. Lots of library work to be done. awesome!
Re: Tango 0.99.8 Sean released
Lars Ivar Igesund wrote: Dear D community A new version of Tango is now available for download. The release is named after Sean Kelly for his past work on the Tango runtime and now druntime. The release have several new features, and fairly major changes to tie the IO even closer together. To make the transition easier, the previous incarnation is still available for this release. This has been a much delayed release compared to the earlier Tango releases, but time has been spent fairly well, covering 301 closed tickets and more than 600 commits. * Final refinement of the IO * JSON parser/builder * FTP adapter for the VFS by Lester L. Martin II * Serial port support by Robin Kreis * Inter-thread communication by Steven Schveighoffer * /dev/null support by Fawzi Mohamed * Random framework by same Fawzi * BigInt by Don Clugston * Updated for DMD 1.041, including Mac support * Support for LDC * OpenSolaris support by BlueZeniX * New API docs courtesy of Aziz and Moritz * More containers such as HashFile For a complete list of changes please see the changelog. We welcome all feedback and testing. We're in the process of updating to new API docs as mentioned above, now generated by dil. You can see the docs for 0.99.8 at http://www.dsource.org/projects/tango/docs/0.99.8 or later download them from via the download pages. We are always looking for new participants, so feel free to contact us via the page linked below. In particular, we are looking for someone to help drive the online presence via our Trac pages. The Tango homepage can be found at http://www.dsource.org/projects/tango Downloads: http://www.dsource.org/projects/tango/wiki/Download See http://www.dsource.org/projects/tango/wiki/TopicInstallTango for more detailed installation instructions for your system. Contact information at http://www.dsource.org/projects/tango/wiki/Contact -- Signed, The Tango Team Great job, guys!
Re: dmd 1.041 and 2.026 releases
Walter Bright wrote: davesun wrote: when can I use dmd on 64bit linux ? You can now - 32 bit executables work fine on 64 bit linux! Maybe I should try it again sometime, but I ran into linker issues when I tried using DMD on 64bit linux. Other than that, DMD worked fine.
