Re: Z80 Emulation Engine
On Tue, Apr 22, 2014 at 11:17:32 +1000, Manu via Digitalmars-d-announce wrote: Yeah I know, I just never expected anyone else to take interest. I'm often torn between gpl and bsd/zlib. FYI, if you're using the free services on GitHub, it *must* be FOSS. I think the GitHub terms of service permit forking for public repositories regardless of the license[1]. If something's open source with no commercial intent, is there good reason not to use gpl? http://choosealicense.com/ How hard is it to change later? If you're the only author, you can change at will. If you accept contributions, you'll need everyone to agree (or rip their code out). You could go with a contributor agreement, but I'd advise against it. Personally, I refuse to contribute to projects which require handing copyright of my pathces over. --Ben [1]https://help.github.com/articles/github-terms-of-service §F.1
Re: D Breaks on to the TIOBE Top 20 List.
On Sat, Apr 26, 2014 at 06:54:55 +, Joakim via Digitalmars-d-announce wrote: On Friday, 25 April 2014 at 19:51:22 UTC, Adam Wilson wrote: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html It's interesting that C++ has been declining for the last decade and especially the last year, with C and Objective-C taking its place at the top for compiled languages. Mobile has driven Objective-C use and will drive the next big language, a good opportunity for D given its efficiency and relative ease of use. Wow, TIOBE looks even more useless than the last time looked at it (years ago). Is TSQL really more popular than Perl? I wonder how much oh dear, I need help with this is conflating these ratings. I mean, PostScript is #25 and while it *is* Turing complete, I don't think too many (well-intentioned) projects are targeting printers as their platform (at least via the paper tray). Almost certainly not more than all of Scala, Go, and Haskell. --Ben
Re: Tkd - Cross platform GUI toolkit based on Tcl/Tk
On Thu, May 08, 2014 at 15:41:57 -0400, Nick Sabalausky via Digitalmars-d-announce wrote: Or better yet, don't. Steam's UI is terrible. Clicking search suggestions often does nothing, the search result paging is goofy as hell and very impractical, the whole thing's absurdly sluggish, in general ignores any and all system settings, menu dropdowns open upon hover instead of click, and, oh yea, my trackpad's scrolling gestures don't even fucking work on it (they work fine on nearly anything else). That's all just off the top of my head. From what I've seen of Tk so far, Steam would have been *far* better if it had used it instead of going to the bother of reinventing everything really, really badly. (Well, at least Steam isn't all-green anymore like it used to be :/ ) IIRC, Steam is a Java beast, so I wouldn't go off and blame Qt/Gtk for that. --Ben
Re: OpenGL Examples in D and a birth of a New Initiative
On Mon, May 19, 2014 at 22:46:33 +0200, Andrej Mitrovic via Digitalmars-d-announce wrote: For a second there I thought Dash was a 2D game engine, but it's a 3D one, which is awesome! 2D physics can still be used with 3D graphics to some great effect. But ultimately I would really want us to have a 3D physics engine. Derelict has a module[1] for ODE[2]. --Ben [1]https://github.com/DerelictOrg/DerelictODE [2]http://www.ode.org/
Re: Interview at Lang.NEXT
On Wed, Jun 04, 2014 at 19:13:32 -0300, Ary Borenszweig via Digitalmars-d-announce wrote: The problem comes when you need to refactor your code and swap one type for another. You have to change all ocurrences of that type in that situation for another. That's what polymorphism and type inference is for. In Haskell at least, you rarely need to actually put types in to your source. Usually you decorate top-level API functions to make sure you got it right and for making figuring out what the type of an argument is though. And those types shouldn't be changing all that often. --Ben
Re: Chuck Allison's talk is up
On Thu, Jun 05, 2014 at 19:36:35 +, Craig Dillabaugh via Digitalmars-d-announce wrote: Are these eventually going to be posted for download somewhere (like last year)? My connection is just too slow for streaming. Use youtube-dl[1]. --Ben [1]http://rg3.github.io/youtube-dl/
Re: dmd front end now switched to Boost license
On Sun, Jun 15, 2014 at 02:20:11 +0200, Leandro Lucarella via Digitalmars-d-announce wrote: I just wanted to point out that there might be more ethical licenses to achieve the same effect (allowing companies to build proprietary tools on top on DMDFE). There's MPL which is source-file-based copyleft (rather than link-time copyleft). --Ben
Re: DConf Day 1 Talk 6: Case Studies in Simplifying Code with Compile-Time Reflection by Atila Neves
On Thu, Jun 19, 2014 at 17:14:54 +, Dicebot via Digitalmars-d-announce wrote: I'd say this is typical vote count for something that no one really cares about but is not considered crappy waste of time :) Top 20 of a months ends with ~700 points right now. http://www.reddit.com/r/programming/comments/25yw89/dash_an_opensource_game_engine_coded_in_d/ - this has gathered 250 being top voted entry about D lately. I like how http://www.reddit.com/r/programming/comments/274ugg/introducing_swift/ got 150 votes and http://www.reddit.com/r/programming/comments/287r4i/smashing_swift/ got 250 :D Please note that Reddit adds a constant to up and down votes to thwart vote bots for the purposes of shadow banning them (they don't know if their vote counted or not), so a popular post might have more fake votes which inflates its numbers (the score is valid though). --Ben
Re: DMD v2.066.0-b2
On Wed, Jul 09, 2014 at 14:56:59 +, Andrew Edwards via Digitalmars-d-announce wrote: My concern is that this shouldn't compile in the first place. What is xyz?, Is it a free function? Is it a member variable or function? In my mind it is neither of the two so why does it compile? Removing the string changes the signature of opDispatch but as shown in my prior example, there are orther ways to cause this error. It's swizzling. gl3n[1] implements it as well. --Ben [1]https://github.com/Dav1dde/gl3n/blob/master/gl3n/linalg.d#L375
Re: Coloring terminal output.
On Mon, Jul 14, 2014 at 20:09:04 +, Adam D. Ruppe via Digitalmars-d-announce wrote: My terminal.d offers color output through special function calls: https://github.com/adamdruppe/arsd/blob/master/terminal.d Scanning this, I see missing termcap for screen and screen-256color which are fairly common. Also rxvt-unicode-256color (if it supports 256 colors which a quick scan didn't seem to indicate). --Ben
Re: DUB 0.9.22 released
On Mon, Sep 22, 2014 at 16:00:40 +0200, Mathias Lang via Digitalmars-d-announce wrote: The focus was on allowing one to compile on a limited platform (compiled vibe.d on a Raspberry Pi B, 512 Mos or RAM, no swap). In order to be fast, we will have to implement proper dependency analysis (currently all object file are rebuild when something change). FWIW, the CMake branch[1] Trent and I have been working on has this support if you want something sooner. --Ben [1]https://github.com/trentforkert/CMake
Re: DUB 0.9.22 released
On Mon, Sep 22, 2014 at 21:04:24 +, tn via Digitalmars-d-announce wrote:
What is the recommended way of versioning bindings? If the
binding of the target library 1.2.3 is versioned as 1.2.3 and a
bug is fixed in the binding (no change in the target library),
how should the new version of the binding for target version
1.2.3 be versioned? Using 1.2.4 is not an option because it
potentially collides with the binding for the next version of the
target.
What about 1.2.3.x? How does dub handle letters in version numbers?
Maybe 1.2.3.0w would be viable ('w' for 'wrap').
--Ben
Re: DUB 0.9.22 released
On Fri, Sep 26, 2014 at 06:29:19 +, Dragos Carp via Digitalmars-d-announce wrote: 1.2.3.x is an invalid version number. Only 3 group numbers are allowed [1]. Though you could use prerelease and/or build suffixes (1.2.3-0w / 1.2.3+0w). How would you version a library which wraps another with 4 version components? Enforced semver to the limit that only 3 components are supported seems a little heavy-handed to me. --Ben
Re: 2D game engine written in D is in progress
On Wed, Dec 17, 2014 at 19:06:21 +, solidstate1991 via Digitalmars-d-announce wrote: I still haven't decided to make it open or closed source (if it'll be ever used by any game that makes profit, I'd like to get some share from it). One way to do this is to make the engine FOSS then keep the artwork under a less permissive license (e.g., this is what Froggato does). --Ben
Re: 2015 H1 Vision
On Mon, Feb 02, 2015 at 12:50:54 +, Russel Winder via Digitalmars-d-announce wrote: Given Gradle is both a dependency and build manager, and is the standard platform for Android builds, and has C++ as well as JVM languages support, I would suggest it would be a great base. I've been using CMake (with patches[1]) just fine[2]. --Ben [1]https://github.com/trentforkert/cmake [2]https://github.com/mathstuf/abagames-gunroar
Re: 2D game engine written in D is in progress
On Tue, Feb 03, 2015 at 17:15:28 +, Zoadian via Digitalmars-d-announce wrote: had a quick look: public class Color This is probably going to be slow. you want to read about 'cache friendliness'. And for a game/graphics engine also google 'data oriented design'. http://gameprogrammingpatterns.com/data-locality.html --Ben
Re: This Week in D, issue 1
On Wed, Jan 14, 2015 at 23:02:47 +, Adam D. Ruppe via Digitalmars-d-announce wrote: On Wednesday, 14 January 2015 at 22:19:12 UTC, qznc wrote: Next medium: E-Mail newsletter. Aye, it is on my list (and actually trivial, I probably have just done it in the amount of time I've spent saying it's on the list lol) And for those who like NNTP over email: http://gwene.org/ --Ben
Re: Anyone interested in embedding a JVM in their D app?
On Wed, Jan 14, 2015 at 15:05:18 +1300, Rikki Cattermole via Digitalmars-d-announce wrote: Definitely need to get JNI support first class. It definitely will help with getting D on Android. My experience is that the D runtime needed some work to accept that there are Linux machines without glibc (bionic for Android). After getting those assumptions out, I had it to a point where it was compiling, but things blew up in the runtime somewhere (or bionic; it was never really giving useful backtraces) during my argument parsing (my guess is the GC was mucking with the wrong bits, but there wasn't anything conclusive since debugging was never easier than what I got from logcat and looking at disassemblies). This was back in 2.065 era though and I haven't done much with it since then. --Ben
Re: Calypso: Direct and full interfacing to C++
On Tue, Feb 17, 2015 at 02:16:57 +, Kelly via Digitalmars-d-announce wrote: P.S. I HATE THIS FORUM EDITORplease add a preview button, whoever takes care of this!?!? I take notes in a different editor and then paste here and it looks fine, only to end up mangled when actually submitted...ugh :) You can subscribe via email. --Ben
Re: Interfacing D to existing C++ code
On Sun, Feb 01, 2015 at 22:32:36 +, Sativa via Digitalmars-d-announce wrote: What I mean is, Do we really need to know the default arguments or are we just having to explicitly use them to make the name mangling work? If it is the latter, then surely couldn't the D compiler sort of have a wild card type of default parameter where the compiler allows any such argument to work? i.e., unless we are actually explicitly needed the default argument in some way it seems that we can just derive it's mangled version from the C++ object data and use that directly in the D mangled version? IIRC, C++ default arguments are handled at compile time and are not part of the ABI. --Ben
Re: DDT 0.11.0 released
On Wed, Mar 18, 2015 at 22:32:05 +, Trent Forkert via Digitalmars-d-announce wrote: The only sensible way to use multiple languages in the same project is to use the same build system for them. Anything else is way too fragile and hackish. Arbitrary, contrived example (though not entirely unrealistic): * a C(++) executable needs a static D library * Said D library in turn uses a C(++) library * All three of these are built as components of the same project So now I need a weird tangled mess of build systems calling each other back and forth. Dub really doesn't pull its weight here. FWIW, no language-specific build system I've ever come across does anything better than meh (and that's just one; the rest are basically nope, can't do it) for support outside of their language or compiling C code against the core runtime/libraries. Then toss in cross-compiling of the C bits and all of them just fall apart. You really need something like Make, Ninja, or another generic build tool at the bottom to do things properly with how different dependencies can be constructed in a complex codebase; you can't really bake all of the knowledge required for the general cases in every language's tools. --Ben
Re: dfmt 0.1.0
On Fri, Mar 06, 2015 at 10:31:29 +, Russel Winder via
Digitalmars-d-announce wrote:
That is the whole point of using tabs for indent, you can chose the
indent amount: I tend to use 20ex.
Remember a tab is not a number of spaces, it is semantic markup. Using
spaces is a low-level hack founded on a lack of separation of concerns
and abstraction.
The problem with tabs, IMO, are the following:
- don't look right in patches (notice the different alignment of
indented lines versus lines without any):
-int foo(int bar) {
- return bar;
-}
versus (assuming 8 space indents):
-int foo(int bar) {
-return bar;
-}
- I have yet to see an editor properly do tab-for-indent with proper
space-for-alignment without manual management:
int my_long_function_name(int bar,
int baz)
^__tab_^^___spaces___^
By the way, this is *wrong* because tabs now have a defined size (8
here) which defeats the only (tangible[1]) advantage they have:
int my_long_function_name(int bar,
int baz)
^__tab_^
--Ben
[1]File size savings are negligible.
Re: dfmt 0.1.0
On Fri, Mar 06, 2015 at 19:55:10 +, Russel Winder via
Digitalmars-d-announce wrote:
On Fri, 2015-03-06 at 09:54 -0500, Ben Boeckel via
Digitalmars-d-announce wrote:
-int foo(int bar) {
- return bar;
-}
versus (assuming 8 space indents):
-int foo(int bar) {
-return bar;
-}
Is your point that in this case they have rendered identically?
Well it is now more apparent with more quoting. It now appears that the
first block is using 3-space indents while the bottom looks just fine
even with the quote markers.
- I have yet to see an editor properly do tab-for-indent with proper
space-for-alignment without manual management:
int my_long_function_name(int bar,
int baz)
^__tab_^^___spaces___^
But, for me anyway, the fundamental flaw here is the idea of alignment.
Find a style that eliminates all this alignment malarkey.
Well, when that means you're going to have absurdly long lines to deal
with in anything other than your definition real editors (and I've
never seen one which fits your definition).
I really dislike the Go obsession with block style alignment of
declarations.
I won't say I'm a fan of it indiscriminently, but if it's that or
200+-character lines, I'll chop argument lists up a bit to fit something
more reasonable.
The core problem here is teletype, monospace font thinking. Using a
proper proportional font for you code and you rapidly lose the need for
all this alignment stuff.
Real point but expressed as a bit of a troll, mostly to expose that
this is likely a bikeshed issue.
And I find that monospace fonts tend to make it much easier to tell the
difference between 'l', '1', and 'I'. Not so important in English, but
it can be all the difference in code.
In a real editor there is no hard line break, no need for this form of
indentation. Should a line be too long for the rendering area either
viewport or syntax directed soft line wrap are used. Having overflow is
mixing content with rendering.
You're making assumptions about the features of your users' editors.
These features are not trivial to implement and this basically requires
things like pygments and other tools used to render code to the web with
all kinds of logic to handle dynamic viewports of the shown code. IMO,
it is even worse than putting #vim:, #kate:, or emacs formatting
directives in your code since it is implicit.
Personally, I use Vim because it works similarly for all uses. I don't
know what I'd do if I had to work with a different editor for each
language I work with.
--Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 12:51:36 +, Bruno Medeiros via
Digitalmars-d-announce wrote:
At the time of this message of yours, you didn't offer any concrete,
*technical* reasons of why dub shouldn't be used. Saying one doesn't
*want* to use dub is not a valid reason at all. Saying you can't,
without saying why, is no valid reason either.
Can dub build multiple libraries in the same project? Different flags to
different source files? Running a Python script to generate D code?
And is that a full-featured integration, or does it have significant
limitations? You see, before DUB was, DDT did have it's own `.dproject`
of sorts ('.buildpath' for those who remember), and it's own basic
builder. But that integration was very basic and had severe limitations.
With CMake, you don't need to do the build steps in DDT; Eclipse already
knows how to run an external build tool just fine.
What I'm wondering is how good the VisualD on is then. Unfortunately I
can't easily check it out myself because if the point here is to check
C/C++ I'd probably have to install the commercial version of Visual
Studio to try it out.
VS2013 Community Edition should work.
--Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:04:30 +, Dicebot via Digitalmars-d-announce wrote: If you mean separate compilation with different flags per module and linking into same binary - it is pretty much illegal in D and can only be done at own risk. I don't know if it is mentioned anyway on dlang.org but that is inevitable side-effect of how symbol emitting works. Makes sense for -fversion and the like (it would be nice if libraries exported the list of version symbols they had since it is basically ABI...), but not necessarily for things like SSE support where you want to do runtime detection and run the fastest version based on the running processor. You might need to compile foo.bar.sse3 and foo.bar.sse4 with different compiler flags. --Ben
Re: Release Candidate D 2.067.0-rc1
On Mon, Mar 23, 2015 at 13:49:53 +, Szymon Gatner via Digitalmars-d-announce wrote: Been waiting for this for almost 2 years, might as well wait for another release. Seriously tho, it is surprising how much little attention is put into C++/D integration considering all the recent fuss about this. And yes, I've tried mixed C++/D app on x64 Win, it crashes with simple writeln() call. At least you get that far; Android doesn't even get there (though those patches to even let people get toolchains up and running are only around a year old). --Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 14:25:22 +, Bruno Medeiros via Digitalmars-d-announce wrote: Yes - use DUB sub-packages. Ah, had missed this. Different flags to different source files? What dicebot said. That looks like an invalid, abstraction-breaking thing to do Not all flags are -fversion or -I flags. Running a Python script to generate D code? Yes, in DUB you can run arbitrary external commands before and after the D sources compilation. But not in between? Basically, can you have a tool written in D built with the project and then used to generate code in the same project? --Ben
Re: GSoC 2015 - Application Rejected
On Mon, Mar 02, 2015 at 23:57:56 +, Piotrek via Digitalmars-d-announce wrote: I remember someone somewhere suggested to make our own summer of code (however I don't know how this would look like). Fedora runs its own[1]. --Ben [1]https://fedoraproject.org/wiki/Summer_Coding_SIG
Re: GSoC 2015 - Application Rejected
On Tue, Mar 03, 2015 at 08:20:41 +, Russel Winder via Digitalmars-d-announce wrote: But this is funded either by GSoC or RH. I don't think Fedora even requests money from GSoC itself anymore. Red Hat funding it makes sense though. And it's not like there aren't companies with 9+ zeros active in and aware of this community. And one notable one in particular has decent multipliers over even Red Hat's size. I see no reason why targeted GSoC-like things can't be organized by those companies besides a presumed lack of ROI. --Ben
Re: Release D 2.067.0
On Tue, Mar 24, 2015 at 19:18:22 +0100, Martin Nowak via Digitalmars-d-announce wrote: What I'm regretting more, is that I have to run after every contributor, bugging them 3 times to write a single changelog line. One way to improve this would be to have changelogs in the dmd/druntime/phobos repo and make the entries part of the pull requests. One thing that I've seen done and liked is that branches worthy of release notes drop a file in somewhere like docs/release/notes/dev/$branchname.md or something (pick your favorite doc format and path) and then making notes for an actual release is taking those, collating them and finally cleaning out the directory for the next release. --Ben
Re: DDT 0.11.0 released
On Wed, Mar 18, 2015 at 21:12:07 +, Bruno Medeiros via Digitalmars-d-announce wrote: What kind of Eclipse projects does it generate? If it generates CDT projects, it's not really much help as CDT doesn't understand D (duh), and DDT doesn't work with CDT projects (also duh). It should add DDT support[1] for D projects. --Ben [1]https://github.com/trentforkert/cmake/blob/d_support3/Source/cmExtraEclipseCDT4Generator.cxx#L70-L73
Re: DDT 0.11.0 released
On Thu, Mar 19, 2015 at 15:31:49 +, Bruno Medeiros via Digitalmars-d-announce wrote: Indeed, I reckon in these more complex examples, you'd call DUB from make/cmake/whatever. DUB would be in charge of building the D library aspect/component of that whole project. I don't see why this would not be possible, or otherwise why it would be a tangled messed. If dub needs things built earlier and then the D code is used by CMake, dependency tracking becomes very manual; it's better to have one tool know the entire build structure here. It might force to think of your build components in a more structured/componentized way, instead of the paradigm of building on a file by file basis, the `make` way. (I've only used make though, not cmake, so dunno how much this comment applies to the later) Building file-at-a-time is, for developers, on the whole faster than unity builds because you can parallelize it and only have to build what changed. CMake only really works with .d - .o rules (Java support bends this AFAIK due to restrictions in javac, but I vastly prefer -j8 over a single invokation). --Ben
Re: DDT 0.11.0 released
On Mon, Mar 23, 2015 at 21:14:31 +0100, Jacob Carlborg via Digitalmars-d-announce wrote: On 2015-03-23 13:54, Bruno Medeiros wrote: There's no plans ATM to integrate with CDT itself. (I don't even know what integration with java tools would mean here) Even for CDT, I don't see what much would there be to integrate, other than the build system. I would guess he means using C(++) files and D files in the same project and the build system would just work. From what I understand[1] of Eclipse (which I admit isn't much from a user's PoV), it supports natures to be loaded which provide functionality. Now I have no idea how much work this is, but it would be nice to have a nature for D support (syntax highlighting, completion, etc.). If it includes dub, great, but it might be worth it to have a separate nature for that. CMake (and other theoretical tools) would then just add the D support nature to handle the D files and use the existing build support. Projects created through DDT itself could add the dub nature by default (FWIW, I don't think CDT generates CMake-based projects out of the box either). Basically, make DDT suitable for using it with other projects which don't use dub because it doesn't suit the upstream project whether it be because the project is more than some D code, YAML is preferred to JSON or whatever. Take my gunroar[2] repo for example. It's mainly D code, but there is some C and Java in the src/android directory. If one were working in Eclipse with it, it would be nice to support using CDT features for the C code, the native Java support for the Java code, DDT for the D code, and the build button to put it all together. --Ben [1]This is based on my experience where enabling the Android bits in an Eclipse project generated by CMake is to allow users to add natures to the generated .project file using the ECLIPSE_EXTRA_NATURES global property. [2]https://github.com/mathstuf/abagames-gunroar
Re: Release D 2.068.0
On Tue, Aug 11, 2015 at 15:08:21 -0700, Bill Baxter via Digitalmars-d-announce wrote: New to brew... getting errors with this on Yosemite: Error: Permission denied - /usr/local/etc/dmd.conf and sudo brew install refuses to do so. /usr/local is Apple's domain on Yosemite now. IIRC, even root can't touch it in 10.11. --Ben
Re: Release D 2.068.0
On Tue, Aug 11, 2015 at 22:36:47 +, John Colvin via Digitalmars-d-announce wrote: Not true. AFAIK /usr/local is the only bit of /usr that *is* available for third-parties. Ah, mixed it up with this tidbit: The /usr/local folder remains accessible, however; it's a long-running convention in Unix and variants as a place to stash material and software that individual users rely on. El Capitan will also remove files from those directories that don't belong to Apple. So it isn't safe over an upgrade, but is accessible. --Ben
Re: Beta D 2.068.0-b2
On Sun, Jul 26, 2015 at 20:13:09 +0200, Jordi Sayol via Digitalmars-d-announce wrote: El 26/07/15 a les 15:55, Martin Nowak via Digitalmars-d-announce ha escrit: BTW, I'd like to phase out the fat 50-60MB combined zip, and add tar.xz/gz for linux/freebsd/osx. Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows. 7z and xz are the same compression algorithm (LZMA), but xz works with tar (it works in streaming mode). --Ben
Re: FancyPars
On Thu, Sep 17, 2015 at 23:40:49 +, Bastiaan Veelo via Digitalmars-d-announce wrote: > On Thursday, 17 September 2015 at 20:32:59 UTC, Stefan Koch wrote: > > Hmm reading this. No license, is best for now. > > Take your time, but without a license anyone cloning or forking > your repo is in fact violating your copyright. It is not what > most people expect on github, and I will have to delete my fork > and local clone... By using public repos, you explicitly allow anyone to view and fork your project. There are no implicit rights of *use* of that clone though. --Ben
Re: Scriptlike v0.9.4 - Perl-like interpolated strings, full examples and more.
On Wed, Sep 23, 2015 at 08:30:18 +0200, Jacob Carlborg via Digitalmars-d-announce wrote: > One thing that really bugs me in Phobos, Scriptlike seems to have the > same problem, is that there are three (!!!) different functions to > remove something from the file system. Give me just one function that > removes everything, regardless if it's a file, directory and if it's > empty or not. Be aware that you will have to pay an extra lstat call for such a function so that *it* can call the right function. It certainly shouldn't replace the existing functions. --Ben
