digitalmars.D - What library functionality would you most like to see in D?
- Jonathan M Davis (20/20) Jul 30 2011 I think that it would be useful to query the community for what piece of...
- Nick Sabalausky (3/32) Jul 30 2011 Off the top of my head: curl and xml
- Jonathan M Davis (5/45) Jul 30 2011 Fortunately, both of those are in the works. A curl wrapper is more or l...
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (81/101) Jul 30 2011 Here's a bunch of ideas, listed in no particular order...
- Anders Ahlstrm (6/16) Jul 31 2011 I'm new to D, but I guess I might be able to develop some sort of config...
- Mirko Pilger (2/5) Jul 31 2011 maybe boost::property_tree could be of some inspiration here:
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/20) Jul 31 2011 That seems like a good idea! As the doc page suggests, we could store
- Anders Ahlstrm (6/29) Jul 31 2011 The property tree is independent of the underlying format, isn't it? Wha...
- Caligo (1/1) Jul 31 2011 I would like to see something similar to Boost Graph Library for D.
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (35/64) Jul 31 2011 Yes, indeed. It would be interesting, though, if we could utilize D's
- Jacob Carlborg (7/12) Jul 31 2011 It's easy to do a simple config module that's probably would be enough
- Jacob Carlborg (11/55) Jul 31 2011 Have a look at Derelict: http://dsource.org/projects/derelict/
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/12) Jul 31 2011 I know of the Goldie project. Is this it?
- Jonathan M Davis (20/29) Jul 31 2011 Off and on, I've been working on porting dmd's lexer to D for Phobos, b=
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (10/30) Jul 31 2011 A generator is what I had in mind - it would allow users to more easily
- Jonathan M Davis (34/68) Jul 31 2011 s,
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/54) Jul 31 2011 It's something I wouldn't mind having a look into. I think we could do
- Jacob Carlborg (6/10) Jul 31 2011 I would really hope that the compiler itself could be built on top of
- Jacob Carlborg (6/26) Jul 31 2011 Yes, exactly, I was referring to your port of the DMD lexer. I really
- Jacob Carlborg (5/19) Jul 31 2011 Yes, I think so as well.
- Jacob Carlborg (5/9) Jul 31 2011 Not officially that I know of, I know someone is working on OpenCL
- Mike Parker (4/8) Jul 31 2011 Yes, eventually. But I make no promises as to win. I work on Derelict at...
- Nick Sabalausky (4/7) Aug 01 2011 I'm very interested in doing what I can to make Goldie suitable for what...
- Johann MacDonagh (26/36) Jul 31 2011 I've started on a port of DMD's lexer (not really a port ;) ):
- Andrej Mitrovic (1/1) Jul 31 2011 Btw why not take DDMD's lexer.d and start from there?
- Johann MacDonagh (8/9) Jul 31 2011 I wasn't sure how up-to-date DDMD was when I started. Plus, I thought a
- Jonathan M Davis (19/20) Jul 31 2011 It's a possibility but has 2 downsides to it.
- Johann MacDonagh (2/5) Jul 31 2011 Derp. I meant to say "Jonathan".
- Jonathan M Davis (26/70) Jul 31 2011 If we do a hand-written lexer of D for Phobos, it really should be a fai...
- Johann MacDonagh (20/45) Jul 31 2011 Yeah, I get the point, but I feel that I could port most trivial changes...
- Jonathan M Davis (9/67) Jul 31 2011 I can tell you right now that he wants a generic, template-based lexer /...
- Johann MacDonagh (3/11) Jul 31 2011 I see. In that case, my hybrid solution doesn't solve either problem ;)
- Jacob Carlborg (5/22) Aug 01 2011 I think you should continue on your lexer, we need a hand-written
- Jacob Carlborg (5/13) Aug 01 2011 I think it's absolutly worth having a hand-written port of the DMD front...
- Jonathan M Davis (10/42) Jul 31 2011 Phobos for D2 is for D2, not D1. Mixing D1 into the mix complicates thin...
- Andrei Alexandrescu (5/9) Jul 31 2011 Until we have fully integrated, EASY to use, and FAST lexer and parser
- Jonathan M Davis (7/16) Jul 31 2011 We need to have all of the dmd and Phobos developers in triplicate. Then...
- Marco Leise (35/37) Aug 01 2011 From reading what some C++ folks think is 'forced' on them in D (making...
- Jacob Carlborg (6/31) Aug 01 2011 In the long run I hope that this won't be necessary, I'm hoping that DMD...
- Jonathan M Davis (10/42) Aug 01 2011 Well, when I have multiple things on my plate, and Andrei has a major
- Jacob Carlborg (4/46) Aug 01 2011 Fair enough.
- Heywood Floyd (3/3) Aug 01 2011 - DBs
- Paul D. Anderson (7/8) Aug 01 2011 vote++
- Andrej Mitrovic (2/2) Jul 31 2011 Are you sure it's LGPL? There's two licenses AFAIK, GPL and Artistic.
- Walter Bright (2/5) Jul 31 2011 I suggest making the input a range.
- Johann MacDonagh (5/13) Aug 01 2011 So, the reason I didn't do this initially was to make slicing a lot
- Jonathan M Davis (15/30) Aug 01 2011 Some adjustment can be made. It _does_ need to have a range-based API, a...
- Johann MacDonagh (8/38) Aug 02 2011 Ok, I'll work on that this weekend. I'll do as close to a port as
- Jacob Carlborg (11/31) Jul 31 2011 I personally would like to see DWT (GUI library,
- Jim Hewes (42/50) Jul 31 2011 I agree with this one. I'll tell you why, hopefully without getting too
- Jacob Carlborg (13/67) Aug 01 2011 I fully agree with that and it's annoying. The wiki page could probably
- Jim Hewes (17/39) Aug 01 2011 I didn't mean to criticize the D compiler installation, which seems to
- Jacob Carlborg (8/29) Aug 02 2011 There is no standard GUI for D. Well, actually, as I think it says on
- simendsjo (25/45) Jul 31 2011 From the top of my head, in no particular order:
- Jacob Carlborg (14/19) Jul 31 2011 Orange: http://dsource.org/projects/orange/
- Jimmy Cao (2/62) Jul 31 2011 FTP, HTTP, and SMTP are the protocols that are included in etc.curl.
- Robert Clipsham (5/25) Jul 31 2011 Async I/O.
- Peter Alexander (4/24) Jul 31 2011 My wish list:
- Brian Hay (2/5) Jul 31 2011 +1 vector math lib.
- Andrej Mitrovic (2/2) Jul 31 2011 Some template/mixin functions which ease generating C or C++ bindings.
- filgood (8/14) Aug 01 2011 +1 for a good math lib (it would be cool if Scid cool become part of
- so (6/7) Aug 02 2011 Speed is mostly up to the compilers' ability to optimize, especially
- dsimcha (9/29) Jul 31 2011 I could really use a linear algebra library, but the GSoC project I'm me...
- bearophile (29/32) Jul 31 2011 This is not a complete list, I have surely forgotten some interesting th...
- Nick Sabalausky (3/4) Aug 01 2011 That'd be very nice to have in phobos.
- Simen Kjaeraas (5/7) Aug 10 2011 Nice idea. So simple yet so useful.
- bearophile (5/6) Aug 10 2011 It's not an original idea, it's essentially a Phobos version of this Pyt...
- Walter Bright (3/6) Jul 31 2011 Better Unicode support.
- KennyTM~ (26/46) Jul 31 2011 1. An officially endorsed XML *and* HTML library that supports Xpath.
- Johann MacDonagh (5/25) Jul 31 2011 My top 3:
- Nick Sabalausky (5/8) Aug 01 2011 Agreed, but fortunately Adam's stuff for that is shaping up nicely:
- Andrei Alexandrescu (6/15) Aug 01 2011 Interesting. What platforms does DWT work on? What is the general
- Jesse Phillips (4/17) Aug 01 2011 I think DWT for D2 worked with Windows and Linux (tested on).
- Jacob Carlborg (4/21) Aug 02 2011 --
- Jesse Phillips (8/14) Aug 02 2011 Well, not much thought has gone into it, but I'm thinking list displays
- Brad Roberts (11/33) Aug 01 2011 I don't think that any gui library belongs in phobos because there's
- Andrei Alexandrescu (3/28) Aug 01 2011 Python has something and as far as I can tell people are fine with that.
- Brad Roberts (6/14) Aug 01 2011 It has something _in the base library_? It has wrappers for all/most
- Lutger Blijdestijn (4/20) Aug 02 2011 It only has a wrapper for the Tkinter (from Tcl/Tk). I don't think a lot...
- Adam D. Ruppe (7/7) Aug 01 2011 I've been thinking about a minimalist drawing library for
- Marco Leise (22/29) Aug 01 2011 I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and ...
- Andrej Mitrovic (7/38) Aug 02 2011 Johannes Pfau is working on a D2 wrapper for Cairo:
- Jos van Uden (3/6) Aug 04 2011 +1
- Mehrdad (4/4) Aug 04 2011 More powerful regexes (like in .NET).
- Graham Fawcett (6/11) Aug 04 2011 Just a thought -- libpcre is a very popular RE library, available under
- Marco Leise (12/24) Aug 04 2011 I wonder what the general consensus is on wrappers. Berkley Sockets are ...
- Dmitry Olshansky (17/21) Aug 04 2011 I'm working on a replacement engine as GSOC project, both named captures...
- Mehrdad (2/22) Aug 04 2011 Dude, that's awesome! Can't wait to see the beta!! :)
- bearophile (11/15) Aug 01 2011 The situation is quite complex, some notes:
- so (5/9) Aug 02 2011 Wrapper over http://nothings.org/stb_image.c and no license issue.
- Marco Leise (12/21) Aug 02 2011 Are you serious?! :
- user (6/10) May 09 2012 You guys have no idea, how much its hurting D.
- so (9/19) Aug 02 2011 I agree, GUIs (and other huge libraries that everyone has their own
- Jimmy Cao (4/27) Aug 02 2011 If a GUI library were included in Phobos, that would make D a much bette...
- Marco Leise (6/41) Aug 02 2011 Why is it so important that the GUI library is included in the std
- Jimmy Cao (4/43) Aug 02 2011 You're right, it's probably not that important.
- Jacob Carlborg (4/7) Aug 02 2011 I think that would make most sense.
- Lutger Blijdestijn (4/35) Aug 02 2011 I really doubt that. You don't get to really compete with C# until D run...
- KennyTM~ (5/40) Aug 03 2011 There was a D.net (which seems no longer updated), and when D runs on
- Andrej Mitrovic (5/5) Aug 03 2011 There's pdcurses which apparently works on Windows. It's public
- Andrej Mitrovic (4/4) Aug 03 2011 This is interesting:
- Jimmy Cao (4/27) Aug 02 2011 If a GUI library were included in Phobos, that would make D a much bette...
- Andrei Alexandrescu (3/26) Aug 02 2011 I think a small and simple GUI would be the worst of all worlds.
- Andrej Mitrovic (1/1) Aug 02 2011 Plus that would tie any updates to the GUI with DMD releases. Bad idea!
- Walter Bright (3/11) Aug 02 2011 Also, remember, we did try to endorse a standard gui library for D a whi...
- Jacob Carlborg (5/17) Aug 02 2011 Yes, that was very unfortunate that basically when you announced DWT
- Johann MacDonagh (12/16) Aug 02 2011 After reading through this thread I now agree with you. I do think we ne...
- Jonathan M Davis (12/34) Aug 02 2011 I see no need for an official GUI. If there were an obvious winner, then...
- Jacob Carlborg (23/43) Aug 02 2011 Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X...
- Nick Sabalausky (3/12) Aug 02 2011 It does Solaris, HPUX, and AIX, but not BSD??
- Jacob Carlborg (5/20) Aug 02 2011 I'm just listing was officially supported with binary releases. I don't
- Jacob Carlborg (6/15) Aug 02 2011 That would be an enormous addition (in code) to Phobos. I would guess
- Josh Simmons (10/31) Aug 02 2011 e-web-stuff
- Johann MacDonagh (4/11) Aug 02 2011 Ah nice, I knew he was working on a web framework but I wasn't sure
- Adam Ruppe (9/11) Aug 02 2011 In my collection, I have (kinda crappy) implementations of my
- Johann MacDonagh (24/35) Aug 02 2011 Sounds like a good starting point. I've also written some code for
- Piotr Szturmaj (2/40) Aug 02 2011 Nice! Please also take a look on https://github.com/pszturmaj/ddb.
- Adam D. Ruppe (4/6) Aug 02 2011 Of course, go ahead! You might also want to look up Piotr Szturmaj's
- Johann MacDonagh (4/10) Aug 02 2011 Yep, he posted above ;). Do you know of any other database interfaces
- Adam D. Ruppe (2/3) Aug 02 2011 Not off the top of my head.
- Jonathan M Davis (14/16) Jul 31 2011 It could be GPL. I don't remember whether it's GPL or LGPL, but it doesn...
- Andrej Mitrovic (1/1) Jul 31 2011 Licenses are the greatest code smell.
- Lutger Blijdestijn (11/11) Aug 01 2011 streams and network programming is most desirable, this also impacts oth...
- Piotr Szturmaj (21/41) Aug 01 2011 1. Cryptography (I already wrote all SHA hash implementations and HMAC,
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (3/49) Aug 02 2011 Sounds good to me!
- Daniel Gibson (6/56) Aug 02 2011 Maybe
- Jacob Carlborg (5/25) Aug 02 2011 Some kind of console library to easy handle input from a user,
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (3/40) Aug 02 2011 Perhaps a curses binding of some sort?
- Jacob Carlborg (4/11) Aug 02 2011 Something like that.
- Nick Sabalausky (5/12) Aug 02 2011 Maybe for linux, but it should be cross-platform and therefore use the W...
- Andrej Mitrovic (4/4) Aug 02 2011 There's a win32 curses-like library around afaik. It uses escape codes
- Nick Sabalausky (13/17) Aug 02 2011 Hmm, see that's the problem, the ANSI escape codes don't really exist in...
- Johann MacDonagh (2/4) Aug 02 2011 And backwards compatibility. Nothing like using the BlahExEx() functions...
- Andrej Mitrovic (3/10) Aug 02 2011 Yes that's why I said there was a project that brought them back. I
- Nick Sabalausky (3/14) Aug 02 2011 Oh, I thought you meant it used them internally.
- Andrej Mitrovic (1/1) Aug 02 2011 I'll find the damn thing, gimme a day. :p
- Walter Bright (3/7) Aug 04 2011 I've used this for 25 years now.
- Andrej Mitrovic (4/6) Aug 05 2011 That's freaking great. And it's already in snn.lib. However this
- Walter Bright (2/10) Aug 06 2011
- Caligo (1/1) Aug 06 2011 product(), combinations(), permutations(), etc, are missing from Phobos.
- Jacob Carlborg (5/18) Aug 02 2011 Actually when I think about it I've written a simple library like that
- Paul D. Anderson (3/26) Aug 02 2011 I'm nearing completion on an arbitrary-precision floating point library,...
- Simen Kjaeraas (5/8) Aug 10 2011 Awesome.
- albatroz (2/7) Aug 06 2011
- simendsjo (2/3) Aug 06 2011 http://www.d-programming-language.org/phobos/std_getopt.html ?
- Mehrdad (2/2) Aug 07 2011 A readText() function that would read a text file (**and** autodetect
- Dmitry Olshansky (5/7) Aug 07 2011 Well the name is here, dunno if it meets your expectations:
- Jonathan M Davis (23/29) Aug 07 2011 D (and Phobos in general) assumes that char in UTF-8, wchar is UTF-16, a...
- Mehrdad (24/37) Aug 07 2011 Yeah, although I don't mean anything /other/ than those -- I only care
- Andrei Alexandrescu (4/10) Aug 07 2011 I think we could and should change readText to do the BOM trick. It's
- Nick Sabalausky (4/6) Aug 07 2011 http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/ut...
- Simen Kjaeraas (6/11) Aug 10 2011 Database connectivity, XML, OpenGL bindings, full OS bindings,
- simendsjo (3/12) Aug 10 2011 Second the full OS bindings. etc\c\win32 would be really nice. You'll
- Jacob Carlborg (5/14) Aug 10 2011 Phobos already have an XML module, although not very good. For OpenGL
- Simen Kjaeraas (6/21) Aug 11 2011 I know. As far as I can see, D is a good option for indie gamedevs
I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis
Jul 30 2011
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.1978.1312090051.14074.digitalmars-d puremagic.com...I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Off the top of my head: curl and xml
Jul 30 2011
On Sunday 31 July 2011 01:53:25 Nick Sabalausky wrote:"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message news:mailman.1978.1312090051.14074.digitalmars-d puremagic.com...Fortunately, both of those are in the works. A curl wrapper is more or less ready for review as I understand it, so it could be in Phobos fairly soon, but I have no idea where the new std.xml stands. - Jonathan M DavisI think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Off the top of my head: curl and xml
Jul 30 2011
On 31-07-2011 07:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisHere's a bunch of ideas, listed in no particular order... -- * Native code generation: I know this is quite a stretch for the standard library, but one thing I'm kind of missing at the moment is a uniform way to generate native machine code. This could be a useful piece of functionality for any application that takes code and just-in-time compiles it, in order to subsequently execute it. It could even be abstract enough to be reused as a general-purpose code generation library for executable files. I'm sure compiler/interpreter/VM writers alike would find this useful; I know I would. I'm currently in the process of writing a compiler infrastructure which will be capable of spitting out x86(-64) executable files, as well as executing code right in memory. In order to do this, I have to implement a code generation library for all of x86(-64); this is not a problem, but I'm sure others have had to do this before me (and will in the future). Standard facilities for this would make compiler engineering in D much easier. All this being said, this would probably be scarcely used and thus might not deserve much priority; I'm sure there are other things in much greater need of work at the moment. I just wanted to put this out there, at least. If this is something that would be desirable for the standard library, I would have no problem writing it for Phobos rather than my specific project. * Concurrency: Another thing I'd like to see is a better way of doing message-passing. Since D threads are, effectively, OS threads, spawning lots of actors is not as cheap as one would like. I'd like some way to spawn lightweight threads that integrate with std.concurrency so that actor systems can be modeled naturally (a la Erlang), rather than throwing several actors into one thread. I'm not sure how heavy fibers are in D, but perhaps it could be implemented on top of those? It would be even more awesome if std.concurrency was expanded to actually support distributed message-passing in some way; even heavyweight threads would be acceptable as long as the system could scale horizontally. * GPU/graphics: Standard library support for OpenGL and OpenCL would be a great way to make D more accessible for GPU-oriented programmers, I would think. Wrapping these libraries would probably be rather trivial. DirectX could of course be wrapped too, but I suppose a cross-platform interface would be better. * Configuration: AFAIK, D has no standard way of doing configuration at the moment. I don't know whether people see this as a problem or not. On one hand, just asking some configuration parser to fetch values for you is very convenient, but on the other hand, people might not like having some sort of "official D configuration format". Personally, the former seems appealing to me, as configuration parsing is the last thing I want to work on in my projects. ;) * Cryptography: D could definitely use more implementations of cryptographic algorithms. Wrapping OpenSSL might be a wise thing to do. * Compiler interface: Some primitive sort of interface to invoke the compiler on a set of files with certain options could be useful to invoke child processes with code compiled on the fly. This would of course demand that DMD is installed, but I don't think that's a problem for apps where doing this in the first place is a good idea. * Lexing and parsing: Standard facilities for these tasks could be very useful. Perhaps D could get its own dlex and dyacc or some such tools. Personally, I prefer sticking to LL(1), but LALR is generally more convenient and flexible, and thus I'd suggest something YACC/ANTLR-like. (I know this doesn't have much to do with Phobos per se, but I figured I'd mention it.) * Asynchronous sockets: For high-performance servers, asynchronous sockets utilizing functionality such as IOCP on Windows is important. * Audio/video: Interfaces to a library such as Libav could be included in Phobos. * Serialization: Some kind of serialization library could be useful. It could probably use compile-time reflection to figure out what kind of code to generate for a type, although my knowledge in D's CTR is not really sufficient to judge this. -- Personally, what I'd like to see done first would be native code generation, concurrency, and cryptography. - Alex
Jul 30 2011
== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s articleHere's a bunch of ideas, listed in no particular order... ... * Configuration: AFAIK, D has no standard way of doing configuration at the moment. I don't know whether people see this as a problem or not. On one hand, just asking some configuration parser to fetch values for you is very convenient, but on the other hand, people might not like having some sort of "official D configuration format". Personally, the former seems appealing to me, as configuration parsing is the last thing I want to work on in my projects. ;)I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files? AFAIK, D supports XML already, which can be used for configuration files, but sometimes something simpler can be convenient.
Jul 31 2011
I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files?maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html
Jul 31 2011
On 31-07-2011 11:30, Anders Ahlstr�m wrote:On 31-07-2011 11:44, Mirko Pilger wrote:I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files? AFAIK, D supports XML already, which can be used for configuration files, but sometimes something simpler can be convenient.That seems like a good idea! As the doc page suggests, we could store configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - AlexI'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files?maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html
Jul 31 2011
== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s articleOn 31-07-2011 11:30, Anders Ahlstr�m wrote:The property tree is independent of the underlying format, isn't it? What is needed is a property tree, and then a bunch of parsers each returning a property tree and being able to write it back to disk. The property tree doesn't even have to know if it is an INI file or an XML file it is editing, which is kind of cool, and flexible.On 31-07-2011 11:44, Mirko Pilger wrote:I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files? AFAIK, D supports XML already, which can be used for configuration files, but sometimes something simpler can be convenient.That seems like a good idea! As the doc page suggests, we could store configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - AlexI'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files?maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html
Jul 31 2011
I would like to see something similar to Boost Graph Library for D.
Jul 31 2011
On 31-07-2011 12:09, Anders Ahlstr�m wrote:== Quote from Alex Rønne Petersen (xtzgzorex gmail.com)'s articleYes, indeed. It would be interesting, though, if we could utilize D's compile-time reflection to generate the parsing code instead of reading values by hand. Suppose I have some configuration like: class MainConfig { string ip; int port; class UserConfig { int accessLevel; string password; } UserConfig[string] usernameToConfigMappings; } It would be nice if I could then say: Config config = new XmlParser().ReadTree!MainConfig(); and it would automagically figure out how to map the resulting data to an instance of MainConfig. The config file could look like this in XML: <node name="ip">127.0.0.1</node> <node name="port">65535</node> <child name="usernameToConfigMappings"> <node name="joe"> <node name="accessLevel">1234</node> <node name="password">asdf</node> </node> <node name="alice"> ... </node> ... </child> or something like that, if I'm reading the property trees docs right... - AlexOn 31-07-2011 11:30, Anders Ahlstr�m wrote:The property tree is independent of the underlying format, isn't it? What is needed is a property tree, and then a bunch of parsers each returning a property tree and being able to write it back to disk. The property tree doesn't even have to know if it is an INI file or an XML file it is editing, which is kind of cool, and flexible.On 31-07-2011 11:44, Mirko Pilger wrote:I'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files? AFAIK, D supports XML already, which can be used for configuration files, but sometimes something simpler can be convenient.That seems like a good idea! As the doc page suggests, we could store configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - AlexI'm new to D, but I guess I might be able to develop some sort of configuration file library (supporting reading and writing values etc.). Do you guys have some sort of preferences or should I just go with standard INI files?maybe boost::property_tree could be of some inspiration here: http://www.boost.org/doc/libs/1_47_0/doc/html/property_tree.html
Jul 31 2011
On 2011-07-31 11:57, Alex Rønne Petersen wrote:That seems like a good idea! As the doc page suggests, we could store configuration in XML, JSON, INI, or whatever people would want to use in their application. Phobos AFAIK has facilities for JSON and XML. Not sure about INI, though. - AlexIt's easy to do a simple config module that's probably would be enough for quite many uses. Just serialize an associative array. My serialization library (Orange) already supports multiple formats (although I've only implemented XML). -- /Jacob Carlborg
Jul 31 2011
On 2011-07-31 08:47, Alex Rønne Petersen wrote:* GPU/graphics: Standard library support for OpenGL and OpenCL would be a great way to make D more accessible for GPU-oriented programmers, I would think. Wrapping these libraries would probably be rather trivial. DirectX could of course be wrapped too, but I suppose a cross-platform interface would be better.Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.* Configuration: AFAIK, D has no standard way of doing configuration at the moment. I don't know whether people see this as a problem or not. On one hand, just asking some configuration parser to fetch values for you is very convenient, but on the other hand, people might not like having some sort of "official D configuration format". Personally, the former seems appealing to me, as configuration parsing is the last thing I want to work on in my projects. ;)XML or JSON could be used for this.* Cryptography: D could definitely use more implementations of cryptographic algorithms. Wrapping OpenSSL might be a wise thing to do. * Compiler interface: Some primitive sort of interface to invoke the compiler on a set of files with certain options could be useful to invoke child processes with code compiled on the fly. This would of course demand that DMD is installed, but I don't think that's a problem for apps where doing this in the first place is a good idea. * Lexing and parsing: Standard facilities for these tasks could be very useful. Perhaps D could get its own dlex and dyacc or some such tools. Personally, I prefer sticking to LL(1), but LALR is generally more convenient and flexible, and thus I'd suggest something YACC/ANTLR-like. (I know this doesn't have much to do with Phobos per se, but I figured I'd mention it.)I think someone is working on this.* Asynchronous sockets: For high-performance servers, asynchronous sockets utilizing functionality such as IOCP on Windows is important. * Audio/video: Interfaces to a library such as Libav could be included in Phobos. * Serialization: Some kind of serialization library could be useful. It could probably use compile-time reflection to figure out what kind of code to generate for a type, although my knowledge in D's CTR is not really sufficient to judge this.I'm currently working on this: http://dsource.org/projects/orange/ There's a release available, but now I'm completely rewriting the library to support more types. D could use some better runtime reflection do better support serialization.-- Personally, what I'd like to see done first would be native code generation, concurrency, and cryptography. - Alex-- /Jacob Carlborg
Jul 31 2011
On 31-07-2011 11:57, Jacob Carlborg wrote:Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?I think someone is working on this.I know of the Goldie project. Is this it?I'm currently working on this: http://dsource.org/projects/orange/ There's a release available, but now I'm completely rewriting the library to support more types. D could use some better runtime reflection do better support serialization.That looks like it's exactly what I had in mind. It would be great if something like that could make it into Phobos itself so it's more readily accessible for users. - Alex
Jul 31 2011
On Sunday 31 July 2011 12:01:02 Alex R=C3=B8nne Petersen wrote:On 31-07-2011 11:57, Jacob Carlborg wrote:.Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries==20 That looks nice. Are there any plans for OpenCL support? =20Off and on, I've been working on porting dmd's lexer to D for Phobos, b= ut I've=20 had enough else going on, that I haven't gotten much done on it of late= . And=20 there is some controversy on the matter, because Andrei and others want= a=20 lexer/parser generator in Phobos rather than a hand-written lexer and p= arser.=20 Both are of value though. So, I don't know what we'll end up with in th= e end.=20 I'm not aware of anyone working on a lexer or parser generator for Phob= os=20 though. Goldie is the closest to that sort of thing that there is at th= e=20 moment. I think that Jacob was referring to my efforts to port the dmd = lexer=20 though. - Jonathan M DavisI think someone is working on this.=20 I know of the Goldie project. Is this it?
Jul 31 2011
On 31-07-2011 12:24, Jonathan M Davis wrote:On Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:A generator is what I had in mind - it would allow users to more easily approach parsing, I think. Hand-written parsers have a much greater learning curve. I do agree on both ideas though; a built-in parser for D would probably be pretty useful to have for extracting information from D source code. An interesting exercise would be generating a lexer/parser via CTFE and mixins. :) Perhaps we don't really need dlex/dyacc tools if we could do something like that. - AlexOn 31-07-2011 11:57, Jacob Carlborg wrote:Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M DavisHave a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?I think someone is working on this.I know of the Goldie project. Is this it?
Jul 31 2011
On Sunday 31 July 2011 12:28:29 Alex R=C3=B8nne Petersen wrote:On 31-07-2011 12:24, Jonathan M Davis wrote:es.On Sunday 31 July 2011 12:01:02 Alex R=C3=B8nne Petersen wrote:On 31-07-2011 11:57, Jacob Carlborg wrote:Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related librari=s,=20 That looks nice. Are there any plans for OpenCL support? =20=20 Off and on, I've been working on porting dmd's lexer to D for Phobo=I think someone is working on this.=20 I know of the Goldie project. Is this it?onbut I've had enough else going on, that I haven't gotten much done =dreiit of late. And there is some controversy on the matter, because An=tand others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don'=kingknow what we'll end up with in the end. I'm not aware of anyone wor=seston a lexer or parser generator for Phobos though. Goldie is the clo=obto that sort of thing that there is at the moment. I think that Jac=lywas referring to my efforts to port the dmd lexer though. =20 - Jonathan M Davis=20 A generator is what I had in mind - it would allow users to more easi=approach parsing, I think. Hand-written parsers have a much greater learning curve. =20 I do agree on both ideas though; a built-in parser for D would probab=lybe pretty useful to have for extracting information from D source cod=e.=20 An interesting exercise would be generating a lexer/parser via CTFE a=ndmixins. :) Perhaps we don't really need dlex/dyacc tools if we could =dosomething like that.The idea behind the hand-written D lexer (and eventually parser) for D = is that=20 it follows the implementation of the compiler's front-end, and so using= it to=20 process D code will have the same result as running the compiler. It ob= viously=20 doesn't scale beyond D itself. If you have a lexer generator and/or parser parser generator, then you = can get=20 it to generate a lexer or parser for any grammar that you want. So, it = covers=20 a different use case - which is why both are of value. Personally, I'd probably want to write a parser by hand anyway, since t= here=20 are definite advantages in doing so, but there's no reason why Phobos s= houldn't=20 have a generator for that for those who want it. Someone still needs to= write=20 it though. - Jonathan M Davis
Jul 31 2011
On 31-07-2011 12:36, Jonathan M Davis wrote:On Sunday 31 July 2011 12:28:29 Alex Rønne Petersen wrote:It's something I wouldn't mind having a look into. I think we could do some awesome magic with CTFE/mixins to do it all inside the D language, using no external tools, but I'm not sure. I'll have to dig into the implementations of existing lexers/parsers first and wee how it could be done. - AlexOn 31-07-2011 12:24, Jonathan M Davis wrote:The idea behind the hand-written D lexer (and eventually parser) for D is that it follows the implementation of the compiler's front-end, and so using it to process D code will have the same result as running the compiler. It obviously doesn't scale beyond D itself. If you have a lexer generator and/or parser parser generator, then you can get it to generate a lexer or parser for any grammar that you want. So, it covers a different use case - which is why both are of value. Personally, I'd probably want to write a parser by hand anyway, since there are definite advantages in doing so, but there's no reason why Phobos shouldn't have a generator for that for those who want it. Someone still needs to write it though. - Jonathan M DavisOn Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:A generator is what I had in mind - it would allow users to more easily approach parsing, I think. Hand-written parsers have a much greater learning curve. I do agree on both ideas though; a built-in parser for D would probably be pretty useful to have for extracting information from D source code. An interesting exercise would be generating a lexer/parser via CTFE and mixins. :) Perhaps we don't really need dlex/dyacc tools if we could do something like that.On 31-07-2011 11:57, Jacob Carlborg wrote:Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M DavisHave a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?I think someone is working on this.I know of the Goldie project. Is this it?
Jul 31 2011
On 2011-07-31 12:36, Jonathan M Davis wrote:The idea behind the hand-written D lexer (and eventually parser) for D is that it follows the implementation of the compiler's front-end, and so using it to process D code will have the same result as running the compiler. It obviously doesn't scale beyond D itself.I would really hope that the compiler itself could be built on top of the font end that will hopefully end up in Phobos. Then they would always be in sync and produce correct results. -- /Jacob Carlborg
Jul 31 2011
On 2011-07-31 12:24, Jonathan M Davis wrote:On Sunday 31 July 2011 12:01:02 Alex Rønne Petersen wrote:Yes, exactly, I was referring to your port of the DMD lexer. I really hope that it ends up in Phobos and hoping that DMD can gradual take advantage of the lexer (and hopefully a whole front end) in Phobos. -- /Jacob CarlborgOn 31-07-2011 11:57, Jacob Carlborg wrote:Off and on, I've been working on porting dmd's lexer to D for Phobos, but I've had enough else going on, that I haven't gotten much done on it of late. And there is some controversy on the matter, because Andrei and others want a lexer/parser generator in Phobos rather than a hand-written lexer and parser. Both are of value though. So, I don't know what we'll end up with in the end. I'm not aware of anyone working on a lexer or parser generator for Phobos though. Goldie is the closest to that sort of thing that there is at the moment. I think that Jacob was referring to my efforts to port the dmd lexer though. - Jonathan M DavisHave a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?I think someone is working on this.I know of the Goldie project. Is this it?
Jul 31 2011
On 2011-07-31 12:01, Alex Rønne Petersen wrote:On 31-07-2011 11:57, Jacob Carlborg wrote:I was referring to Jonathan's port of the DMD lexer.Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?I think someone is working on this.I know of the Goldie project. Is this it?Yes, I think so as well. -- /Jacob CarlborgI'm currently working on this: http://dsource.org/projects/orange/ There's a release available, but now I'm completely rewriting the library to support more types. D could use some better runtime reflection do better support serialization.That looks like it's exactly what I had in mind. It would be great if something like that could make it into Phobos itself so it's more readily accessible for users. - Alex
Jul 31 2011
On 2011-07-31 12:01, Alex Rønne Petersen wrote:On 31-07-2011 11:57, Jacob Carlborg wrote:Not officially that I know of, I know someone is working on OpenCL bindings, don't remember who. -- /Jacob CarlborgHave a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?
Jul 31 2011
On 7/31/2011 7:01 PM, Alex Rønne Petersen wrote:On 31-07-2011 11:57, Jacob Carlborg wrote:Yes, eventually. But I make no promises as to win. I work on Derelict at a snail's pace. If someone contributed a binding, it would get in a lot quicker!Have a look at Derelict: http://dsource.org/projects/derelict/ It wraps OpenGL, OpenAL and other game/multimedia related libraries.That looks nice. Are there any plans for OpenCL support?
Jul 31 2011
"Alex Rnne Petersen" <xtzgzorex gmail.com> wrote in message news:j1395t$13bo$1 digitalmars.com...On 31-07-2011 11:57, Jacob Carlborg wrote:I'm very interested in doing what I can to make Goldie suitable for what people need. Are there any particular shortcomings you see with it?I think someone is working on this.I know of the Goldie project. Is this it?
Aug 01 2011
On 7/31/2011 5:57 AM, Jacob Carlborg wrote:I've started on a port of DMD's lexer (not really a port ;) ): https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant). Some features I'm planning: 1. Support D1 and D2. 2. Warnings and errors returned in the tokens. For example, if you use an octal constant for D2 code, it will correctly return an integer constant token with some kind of warning flag set and a message. In terms of errors, if the lexer hits "0xz012", it will return an error token for the slice "0xz" and then start lexing an integer constant "012". No exceptions, easy peasy. 3. CTFEable. Although I'll probably have to wait till the next DMD release. 4. Support any kind of character range. Not sure if people want to lex something that's not a string/wstring/dstring. I'm glad this was brought up. I remember Walter's post last year asking for this module, but the conversation seemed to kill the idea. I started on this just for the fun of it, but then doubted whether Phobos wanted it. I feel that a hand written lexer / parser is going to be faster than something generated, but maybe I'm old fashioned. Anyway, Jim, if you want to do this I can move on to something else. If you want, I can continue on. I didn't see a branch in your repo so I'm not sure what you've done.* Lexing and parsing: Standard facilities for these tasks could be very useful. Perhaps D could get its own dlex and dyacc or some such tools. Personally, I prefer sticking to LL(1), but LALR is generally more convenient and flexible, and thus I'd suggest something YACC/ANTLR-like. (I know this doesn't have much to do with Phobos per se, but I figured I'd mention it.)I think someone is working on this.
Jul 31 2011
Btw why not take DDMD's lexer.d and start from there?
Jul 31 2011
On 7/31/2011 9:31 PM, Andrej Mitrovic wrote:Btw why not take DDMD's lexer.d and start from there?I wasn't sure how up-to-date DDMD was when I started. Plus, I thought a fresh look at a lexer using D2 features rather than a straight port would be a little cleaner. For example, instead of that huge switch statement for all the operators, I have a mixin that generates that huge switch statement based on an array of operator strings: https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer#L0R506 I may end up using "borrowing" some code from DDMD ;)
Jul 31 2011
On Monday 01 August 2011 03:31:41 Andrej Mitrovic wrote:Btw why not take DDMD's lexer.d and start from there?It's a possibility but has 2 downsides to it. 1. Due to licensing issues, you have to get permission from the ddmd developers. The front-end is LGPL IIRC, not Boost. Walter gave permission to port the lexer from the front-end to D and make it Boost, but that doesn't hold for the ddmd code, which was taken from dmd's front-end and ported by other folks. So, their permission would be required. It's not necessarily a big deal, but it is something that needs to be dealt with. 2. To really do it right, you need to understand how it works. Personally, I think that doing all the work of porting it is going to help a _lot_ in gaining that understanding. If all you do is take and adjust the ddmd code, then you don't gain that understanding. So, ddmd's source code definitely could be used as the base for Phobos' D it very valuable to do the porting myself. I haven't gotten very far on of it of late though. Taking ddmd and adjusting would probably be faster, but as a maintainer of the result, it would be harder to maintain just because I wouldn't understand it as well. - Jonathan M Davis
Jul 31 2011
On 7/31/2011 9:29 PM, Johann MacDonagh wrote:Anyway, Jim, if you want to do this I can move on to something else. If you want, I can continue on. I didn't see a branch in your repo so I'm not sure what you've done.Derp. I meant to say "Jonathan".
Jul 31 2011
On Sunday 31 July 2011 21:29:31 Johann MacDonagh wrote:On 7/31/2011 5:57 AM, Jacob Carlborg wrote:If we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer). Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate. As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy. So, if you really want to work on a potential D lexer for Phobos, that's fine, but I really think that it needs to be a rather direct port, and that doesn't sound like what you've been doing. - Jonathan M DavisI've started on a port of DMD's lexer (not really a port ;) ): https://github.com/jmacdonagh/phobos/compare/master...std.lang.d.lexer Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant). Some features I'm planning: 1. Support D1 and D2. 2. Warnings and errors returned in the tokens. For example, if you use an octal constant for D2 code, it will correctly return an integer constant token with some kind of warning flag set and a message. In terms of errors, if the lexer hits "0xz012", it will return an error token for the slice "0xz" and then start lexing an integer constant "012". No exceptions, easy peasy. 3. CTFEable. Although I'll probably have to wait till the next DMD release. 4. Support any kind of character range. Not sure if people want to lex something that's not a string/wstring/dstring. I'm glad this was brought up. I remember Walter's post last year asking for this module, but the conversation seemed to kill the idea. I started on this just for the fun of it, but then doubted whether Phobos wanted it. I feel that a hand written lexer / parser is going to be faster than something generated, but maybe I'm old fashioned. Anyway, Jim, if you want to do this I can move on to something else. If you want, I can continue on. I didn't see a branch in your repo so I'm not sure what you've done.* Lexing and parsing: Standard facilities for these tasks could be very useful. Perhaps D could get its own dlex and dyacc or some such tools. Personally, I prefer sticking to LL(1), but LALR is generally more convenient and flexible, and thus I'd suggest something YACC/ANTLR-like. (I know this doesn't have much to do with Phobos per se, but I figured I'd mention it.)I think someone is working on this.
Jul 31 2011
On 7/31/2011 9:56 PM, Jonathan M Davis wrote:If we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate.Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy.Well, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?So, if you really want to work on a potential D lexer for Phobos, that's fine, but I really think that it needs to be a rather direct port, and that doesn't sound like what you've been doing. - Jonathan M DavisIf we decide to scrap my idea and go a more generic route, I'd probably start working on a standard database interface. I'd like to see D become a little more web framework friendly, and a nice generic database interface is definitely a start. So, Andrei, what do you think about a lexer / parser in Phobos? Generic or a straight port?
Jul 31 2011
On Sunday 31 July 2011 22:28:51 Johann MacDonagh wrote:On 7/31/2011 9:56 PM, Jonathan M Davis wrote:I can tell you right now that he wants a generic, template-based lexer / parser generator rather than a hand-written solution. He doesn't like the idea of the hand-written solution. And I definitely think that we should have a template-based lexer / parser generator. The question is whether it's also worth having a hand-written port of the dmd front-end's lexer and parser to Phobos so that we can have on official lexer and parser in Phobos which parse D the same way that the compiler does. - Jonathan M DavisIf we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate.Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy.Well, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?So, if you really want to work on a potential D lexer for Phobos, that's fine, but I really think that it needs to be a rather direct port, and that doesn't sound like what you've been doing. - Jonathan M DavisIf we decide to scrap my idea and go a more generic route, I'd probably start working on a standard database interface. I'd like to see D become a little more web framework friendly, and a nice generic database interface is definitely a start. So, Andrei, what do you think about a lexer / parser in Phobos? Generic or a straight port?
Jul 31 2011
On 7/31/2011 10:34 PM, Jonathan M Davis wrote:I can tell you right now that he wants a generic, template-based lexer / parser generator rather than a hand-written solution. He doesn't like the idea of the hand-written solution. And I definitely think that we should have a template-based lexer / parser generator. The question is whether it's also worth having a hand-written port of the dmd front-end's lexer and parser to Phobos so that we can have on official lexer and parser in Phobos which parse D the same way that the compiler does. - Jonathan M DavisI see. In that case, my hybrid solution doesn't solve either problem ;) I'll keep my code in that branch and start on something new.
Jul 31 2011
On 2011-08-01 04:38, Johann MacDonagh wrote:On 7/31/2011 10:34 PM, Jonathan M Davis wrote:I think you should continue on your lexer, we need a hand-written lexer/parser in Phobos, preferably a port of the DMD front end. -- /Jacob CarlborgI can tell you right now that he wants a generic, template-based lexer / parser generator rather than a hand-written solution. He doesn't like the idea of the hand-written solution. And I definitely think that we should have a template-based lexer / parser generator. The question is whether it's also worth having a hand-written port of the dmd front-end's lexer and parser to Phobos so that we can have on official lexer and parser in Phobos which parse D the same way that the compiler does. - Jonathan M DavisI see. In that case, my hybrid solution doesn't solve either problem ;) I'll keep my code in that branch and start on something new.
Aug 01 2011
On 2011-08-01 04:34, Jonathan M Davis wrote:I can tell you right now that he wants a generic, template-based lexer / parser generator rather than a hand-written solution. He doesn't like the idea of the hand-written solution. And I definitely think that we should have a template-based lexer / parser generator. The question is whether it's also worth having a hand-written port of the dmd front-end's lexer and parser to Phobos so that we can have on official lexer and parser in Phobos which parse D the same way that the compiler does. - Jonathan M DavisI think it's absolutly worth having a hand-written port of the DMD front end in Phobos. -- /Jacob Carlborg
Aug 01 2011
On Sunday 31 July 2011 22:28:51 Johann MacDonagh wrote:On 7/31/2011 9:56 PM, Jonathan M Davis wrote:Phobos for D2 is for D2, not D1. Mixing D1 into the mix complicates things. If it's easy to tell the lexer to lex D1 or D2 without negatively impacting performance and without seriously impacting the implementation, then we can support D1. But personally, I don't think that it's worth the extra complication. The compiler separates them with ifdefs, which isn't going to work as well in Phobos. You'd probably end up having to use templates and static ifs to deal with the differences. It can be done, but I don't think that it's worth the gain. The lexer is complicated enough as it is. - Jonathan M DavisIf we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).Yeah, I get the point, but I feel that I could port most trivial changes from DMD's lexer to lexer.d. The layout of the code is different, of course, but I'm borrowing most of the lexing logic from DMD. Plus with unittests, I think we could ensure things are lexing the same.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate.Well, it doesn't appear that there are that many lexical differences between D1 and D2. A few operators, a few keywords, D2 supports a few different string constants, etc... I wanted this to be usable by IDEs. Do we not want to support D2 for development? I could certainly make this D2 only.
Jul 31 2011
On 07/31/2011 09:28 PM, Johann MacDonagh wrote:Well, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?Until we have fully integrated, EASY to use, and FAST lexer and parser generators, we haven't yet proven the power of CTFE technology. I don't have the time to embark on such a project for the time being. Andrei
Jul 31 2011
On Sunday 31 July 2011 22:18:51 Andrei Alexandrescu wrote:On 07/31/2011 09:28 PM, Johann MacDonagh wrote:We need to have all of the dmd and Phobos developers in triplicate. Then maybe we could actually get everything done that we'd like to get done... Well, at least the change to github has better enabled commmunity support outside of the primary developers. So, even if still don't get it everything done that we'd like to, we're at least doing much better. - Jonathan M DavisWell, if Andrei wants to flex the power of D2's templates / etc... with a parser generator then maybe we should go down that route. Andrei, what do you think? Would the lexer/parser be generated at compile time or a a regular tool that would generate the appropriate D files?Until we have fully integrated, EASY to use, and FAST lexer and parser generators, we haven't yet proven the power of CTFE technology. I don't have the time to embark on such a project for the time being.
Jul 31 2011
Am 01.08.2011, 05:31 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:We need to have all of the dmd and Phobos developers in triplicate. Then maybe we could actually get everything done that we'd like to get done...From reading what some C++ folks think is 'forced' on them in D (making common things easy vs a low level structure covering all exotic use cases) and my experience with the RedBlackTree (it is fast but, couldn't be created empty as I am used to from other language libraries) I think it is not just about getting things done, but about brainstorming in advance. When we use containers, what use cases do we have? Programmer A wants to be able to easily switch the container implementation from an array list to a sorted tree, B requires pure speed without the overhead of virtual functions and a class hierarchy. Either A or B give in, there is room for both in Phobos or either A or B go and (re)write the containers. I believe this discussion has been here already, but I wasn't reading the list at that time. :) So what I want to say is, before someone starts writing the code for a parser generator, try to make a list of use cases. I don't say every use case must be covered, but it would be great, if there were 'entry points' for others to implement what they need. A common example is a sorted set that sorts by the natural ordering of elements, but can be augmented with a comparator function. So far we have the - general idea of a lexer/parser - a D source code parser I'd be very exited to see a CTFE solution to building a parser *g*, you know just for the awe of it. If that works out and it turns out that it is actually quite fast it *could* be used to write a D parser from definitions. But the point that you would want to keep close to the C source of DMD is strong. I wanted to write a disk cleanup tool for Linux that uses a simple special script language basically using list operations (like list all java processes -> list all files in directory x containing any processes pid -> protect them from deletion). The format consists keywords that can open new blocks that again contain other keywords, so I ended up writing parse functions for each block type. I'd go with a complete AST here instead of the linear list of tokens that has been proposed. If I wrote a syntax highlighter then the AST would not be of much use. So this could be two use cases to cover. Comments?
Aug 01 2011
On 2011-08-01 03:56, Jonathan M Davis wrote:If we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate. As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy.In this case I really don't think that you should listen to Andrei.So, if you really want to work on a potential D lexer for Phobos, that's fine, but I really think that it needs to be a rather direct port, and that doesn't sound like what you've been doing. - Jonathan M Davis-- /Jacob Carlborg
Aug 01 2011
On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:On 2011-08-01 03:56, Jonathan M Davis wrote:Well, when I have multiple things on my plate, and Andrei has a major disagreement with one, I'm less likely to focus on that one. It's also one which takes quite a bit of time and focus, whereas there is other stuff which I can do in smaller chunks of time without needing as much focus. So, I haven't worked on it as much. I should probably remedy that, but there's quite a lot that I've been trying to get done. So, yes. I intend to do it in spite of Andrei's opinion on the matter, but lately I've been focusing on other stuff which needs doing. - Jonathan M DavisIf we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate. As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy.In this case I really don't think that you should listen to Andrei.
Aug 01 2011
On 2011-08-01 10:21, Jonathan M Davis wrote:On Monday 01 August 2011 10:12:17 Jacob Carlborg wrote:Fair enough. -- /Jacob CarlborgOn 2011-08-01 03:56, Jonathan M Davis wrote:Well, when I have multiple things on my plate, and Andrei has a major disagreement with one, I'm less likely to focus on that one. It's also one which takes quite a bit of time and focus, whereas there is other stuff which I can do in smaller chunks of time without needing as much focus. So, I haven't worked on it as much. I should probably remedy that, but there's quite a lot that I've been trying to get done. So, yes. I intend to do it in spite of Andrei's opinion on the matter, but lately I've been focusing on other stuff which needs doing. - Jonathan M DavisIf we do a hand-written lexer of D for Phobos, it really should be a fairly direct port of the dmd front-end. It should be _somewhat_ D-ified as appropriate, (and the API should definitely be properly range-based and all that), but the implementation needs to be fairly close to dmd itself so that it's easy for someone to port changes and fixes back and forth between the two. Otherwise, they're going to get out of sync fairly easily. If we're not going to do a direct port, then we might as well just do the template-based lexer generator that Andrei and others would really like to see (which we should still do, but I think that the hand-written lexer is nowhere near as valuable if it's not a direct port of dmd's lexer).In the long run I hope that this won't be necessary, I'm hoping that DMD will use the lexer from Phobos.Also, I see _zero_ value in making it support D1. If it's for D2's standard library, then what's the point of it lexing D1? That just complicates the lexer for what is essentially a legacy product. And given that the differences between D1 and D2 in dmd's lexer are covered with #ifdefs, it would be rather complicated to try and do a direct port which covers both D1 and D2. It would probably be easier if the two were completely separate. As for what I've done so far, I'd have to go look. I haven't touched it in a couple of months, I expect. There has been a lot of other stuff that I've needed to do, and Andrei was trying to discourage such an implementation the last time that I brought it up. So, I haven't exactly been in a rush to get it done. I'd like to do it, but I've been rather busy.In this case I really don't think that you should listen to Andrei.
Aug 01 2011
- DBs - Incremental GC (for real-time apps) - Code examples!!! ..in the docs, applies to all libs, please..
Aug 01 2011
Heywood Floyd Wrote:- Code examples!!! ..in the docs, applies to all libs, please..vote++ The language and library reference docs work well for learning what's possible but not at how to make it happen. TDPL is better, but it isn't really a "cookbook" either. The good news is that anyone can contribute to a set of code examples. Adding these shouldn't add to the workload of the "senior" developers. In fact learners should probably be the main contributors because they're the ones who notice what's missing. Suggest perhaps we create a page to invite contribution to code examples. There is already a "Tech Tips" page -- may be revive that. Paul
Aug 01 2011
Are you sure it's LGPL? There's two licenses AFAIK, GPL and Artistic. I'm not seeing any mention of LGPL in the code.
Jul 31 2011
On 7/31/2011 6:29 PM, Johann MacDonagh wrote:Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant).I suggest making the input a range.
Jul 31 2011
On 7/31/2011 11:32 PM, Walter Bright wrote:On 7/31/2011 6:29 PM, Johann MacDonagh wrote:So, the reason I didn't do this initially was to make slicing a lot easier. It could easily be changed to any kind of input range of characters. However, it looks like something that's not a direct port of DMD isn't worthwhile.Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant).I suggest making the input a range.
Aug 01 2011
On 7/31/2011 11:32 PM, Walter Bright wrote:Some adjustment can be made. It _does_ need to have a range-based API, and some changes are inevitable in order to do that. But the changes to the basic logic need to be minimal. The thing is that it can be an input range _and_ take advantage of slicing with the use of static ifs in the appropriate places. If hasSlicing!Range is true, then you can have a static if branch for slicing it. If it's a narrow string then you can use another branch. And if it's neither, then it won't get the advantages of slicing. It complicates the code somewhat, but the proper use of Phobos functions which deal with it for you should help. In any case, the point is that we need to port dmd's lexer over to D, changing it enough to give it a range-based interface (so it'll take a range of dchars but return a range of tokens) but avoiding changing more than necessary so that it's easy to port changes and fixes back and forth between it and dmd's front end. - Jonathan M DavisOn 7/31/2011 6:29 PM, Johann MacDonagh wrote:So, the reason I didn't do this initially was to make slicing a lot easier. It could easily be changed to any kind of input range of characters. However, it looks like something that's not a direct port of DMD isn't worthwhile.Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant).I suggest making the input a range.
Aug 01 2011
On 8/1/2011 5:50 PM, Jonathan M Davis wrote:Ok, I'll work on that this weekend. I'll do as close to a port as possible while stripping out anything that doesn't make sense and D-ifying the code a little bit. It will accept anything that isInputRange!R && isSomeChar!(ElementEncodingType!R) and return an input range of tokens. I've already looked through quite a bit of the lexer.c source while writing my other lexer, and the port should be easy (famous last words).On 7/31/2011 11:32 PM, Walter Bright wrote:Some adjustment can be made. It _does_ need to have a range-based API, and some changes are inevitable in order to do that. But the changes to the basic logic need to be minimal. The thing is that it can be an input range _and_ take advantage of slicing with the use of static ifs in the appropriate places. If hasSlicing!Range is true, then you can have a static if branch for slicing it. If it's a narrow string then you can use another branch. And if it's neither, then it won't get the advantages of slicing. It complicates the code somewhat, but the proper use of Phobos functions which deal with it for you should help. In any case, the point is that we need to port dmd's lexer over to D, changing it enough to give it a range-based interface (so it'll take a range of dchars but return a range of tokens) but avoiding changing more than necessary so that it's easy to port changes and fixes back and forth between it and dmd's front end. - Jonathan M DavisOn 7/31/2011 6:29 PM, Johann MacDonagh wrote:So, the reason I didn't do this initially was to make slicing a lot easier. It could easily be changed to any kind of input range of characters. However, it looks like something that's not a direct port of DMD isn't worthwhile.Basically, you give it some string (string, wstring, or dstring), and it gives you a range of tokens back. The token has the type, a slice of the input that corresponds to the token, line / column, and a value (e.g. an integer constant).I suggest making the input a range.
Aug 02 2011
On 2011-07-31 07:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisI personally would like to see DWT (GUI library, http://dsource.org/projects/dwt) in a more finished state. These are things that need work: * Finishing the Mac OS X port * Update to later SWT versions * Fixing bugs * Port to 64bit Any help is much appreciated. Currently DWT is a low priority for me. -- /Jacob Carlborg
Jul 31 2011
On 7/31/2011 3:01 AM, Jacob Carlborg wrote:I personally would like to see DWT (GUI library, http://dsource.org/projects/dwt) in a more finished state. These are things that need work: * Finishing the Mac OS X port * Update to later SWT versions * Fixing bugs * Port to 64bit Any help is much appreciated. Currently DWT is a low priority for me.I agree with this one. I'll tell you why, hopefully without getting too long-winded. :-) I've just been a lurker here and although I like the D language haven't really used it seriously yet. Where I work, we use Visual Studio C++ for the main product. It's highly unlikely that would just get switch to using D. But we also write various small utilities and test programs that we use internally. These are almost all written in C++ with MFC. I have never been a fan of MFC. (Even from the beginning I preferred Borland's ObjectWindows.) But it has some advantages. It's a common, almost standard GUI that comes with VS and to some extent is integrated with VS. Using MFC I can produce single-file EXEs with a GUI that can be easily passed around the company internally. I can tell users to just grab one EXE, copy it to your computer and run it. Very easy for people. My point here is that these little applications are not critical and so they could be written in any language. In my company, this would be the best way for a new language had any complaints. For my job I work on Windows, though I try not to be an O/S fanboy and try to treat all platforms with equal credibility. But I guess one of my peeves about open source and Linux (which seem to go together) is that for any target goal there are a hundred half-finished, abandoned projects. I assume this is because people don't get paid to do it and so once they get tired of it they move on to other more interesting things. I can't depend on that or sell it to my colleagues. Take a look at the GUI page on the D wiki. There are a lot of projects, but almost all of them seem to be either in alpha or beta stage or are abandoned. Further, in every project, each developer usually chose to use some different array of tools that I need to download and install in my computer just to build his project. This gets kind of annoying on Windows. I've recently downloaded the QtD binding to take a look because Qt seem to be a pretty popular cross-platform library. I was able to build it and then also build a couple of the sample projects, although I haven't really spent time with it beyond that. It seems that not only is a Hello World program a 1.7MB executable, but I think I would also need to distribute the libcpp_core.dll and libcpp_gui.dll files with it for a total of about 17MB. QtD looks like a lot of good work and I don't mean to knock it here. I just mean to say that in contrast what would be nice is a “standard” GUI written in D that could be statically linked and would be not too large. I confess I have not tried the existing DWT yet, mostly since I just didn't want to also download Tango. Jim
Jul 31 2011
On 2011-07-31 21:06, Jim Hewes wrote:On 7/31/2011 3:01 AM, Jacob Carlborg wrote:That's understandable.I personally would like to see DWT (GUI library, http://dsource.org/projects/dwt) in a more finished state. These are things that need work: * Finishing the Mac OS X port * Update to later SWT versions * Fixing bugs * Port to 64bit Any help is much appreciated. Currently DWT is a low priority for me.I agree with this one. I'll tell you why, hopefully without getting too long-winded. :-) I've just been a lurker here and although I like the D language haven't really used it seriously yet. Where I work, we use Visual Studio C++ for the main product. It's highly unlikely that would just get switch to using D. But we also write various small utilities and test programs that we use internally. These are almost all written in C++ with MFC. I have never been a fan of MFC. (Even from the beginning I preferred Borland's ObjectWindows.) But it has some advantages. It's a common, almost standard GUI that comes with VS and to some extent is integrated with VS. Using MFC I can produce single-file EXEs with a GUI that can be easily passed around the company internally. I can tell users to just grab one EXE, copy it to your computer and run it. Very easy for people. My point here is that these little applications are not critical and so they could be written in any language. In my company, this would be the best way for a new language had any complaints.For my job I work on Windows, though I try not to be an O/S fanboy and try to treat all platforms with equal credibility. But I guess one of my peeves about open source and Linux (which seem to go together) is that for any target goal there are a hundred half-finished, abandoned projects. I assume this is because people don't get paid to do it and so once they get tired of it they move on to other more interesting things. I can't depend on that or sell it to my colleagues. Take a look at the GUI page on the D wiki. There are a lot of projects, but almost all of them seem to be either in alpha or beta stage or are abandoned. Further, in every project, each developer usually chose to use some different array of tools that I need to download and install in my computer just to build his project. This gets kind of annoying on Windows.I fully agree with that and it's annoying. The wiki page could probably use some cleanup. About the tools, I'm working on a package manager for D that will ease installation of D libraries, tools and application. I and at least one other person is working on a build tool with the hope that we can all agree on one standard built tool for D.I've recently downloaded the QtD binding to take a look because Qt seem to be a pretty popular cross-platform library. I was able to build it and then also build a couple of the sample projects, although I haven't really spent time with it beyond that. It seems that not only is a Hello World program a 1.7MB executable, but I think I would also need to distribute the libcpp_core.dll and libcpp_gui.dll files with it for a total of about 17MB. QtD looks like a lot of good work and I don't mean to knock it here. I just mean to say that in contrast what would be nice is a “standard” GUI written in D that could be statically linked and would be not too large. I confess I have not tried the existing DWT yet, mostly since I just didn't want to also download Tango. JimDWT works with D2 (Phobos) as well. It's statically linked so the hello world application gets quite large. But that's because it pulls in a lot of the library, meaning even if you start using other parts of the library it won't increase the size of the executable at the same rate. -- /Jacob Carlborg
Aug 01 2011
"Jacob Carlborg" <doob me.com> wrote in message news:j15kug$1v62$1 digitalmars.com...On 2011-07-31 21:06, Jim Hewes wrote:I didn't mean to criticize the D compiler installation, which seems to install pretty well on Windows. That is, after you install it you're ready to go without additional setup or needing to install other things. I was referring more to the peripheral projects and also just to open source in general. If DWT is the standard GUI in the same sense that MFC is for Microsoft C++, then I thought it would be nice if it were included in the installer for the D compiler. It could be an optional feature during installation. But if you do choose to install it, then right after installation you should immediately be able to build included sample GUI code projects.For my job I work on Windows, though I try not to be an O/S fanboy and try to treat all platforms with equal credibility. But I guess one of my peeves about open source and Linux (which seem to go together) is that for any target goal there are a hundred half-finished, abandoned projects. I assume this is because people don't get paid to do it and so once they get tired of it they move on to other more interesting things. I can't depend on that or sell it to my colleagues. Take a look at the GUI page on the D wiki. There are a lot of projects, but almost all of them seem to be either in alpha or beta stage or are abandoned. Further, in every project, each developer usually chose to use some different array of tools that I need to download and install in my computer just to build his project. This gets kind of annoying on Windows.I fully agree with that and it's annoying. The wiki page could probably use some cleanup. About the tools, I'm working on a package manager for D that will ease installation of D libraries, tools and application. I and at least one other person is working on a build tool with the hope that we can all agree on one standard built tool for D.DWT works with D2 (Phobos) as well. It's statically linked so the hello world application gets quite large. But that's because it pulls in a lot of the library, meaning even if you start using other parts of the library it won't increase the size of the executable at the same rate.Yeah, the main GUI library page on the wiki says that it works with Phobos, but the Windows installation guide says to download Tango. So I wasn't sure it was really updated to support Phobos. Thanks, I will try to check it out next weekend. Jim
Aug 01 2011
On 2011-08-01 21:03, Jim Hewes wrote:I didn't mean to criticize the D compiler installation, which seems to install pretty well on Windows. That is, after you install it you're ready to go without additional setup or needing to install other things. I was referring more to the peripheral projects and also just to open source in general.Ok.If DWT is the standard GUI in the same sense that MFC is for Microsoft C++, then I thought it would be nice if it were included in the installer for the D compiler. It could be an optional feature during installation. But if you do choose to install it, then right after installation you should immediately be able to build included sample GUI code projects.There is no standard GUI for D. Well, actually, as I think it says on the wiki is that DWT is the standard GUI library, but that's referring to an older, windows only, version of DWT.I guess the DWT project page could use some updating. -- /Jacob CarlborgDWT works with D2 (Phobos) as well. It's statically linked so the hello world application gets quite large. But that's because it pulls in a lot of the library, meaning even if you start using other parts of the library it won't increase the size of the executable at the same rate.Yeah, the main GUI library page on the wiki says that it works with Phobos, but the Windows installation guide says to download Tango. So I wasn't sure it was really updated to support Phobos. Thanks, I will try to check it out next weekend. Jim
Aug 02 2011
On 31.07.2011 07:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisFrom the top of my head, in no particular order: * xml * csv * ini * logging * database interface * serialization * parsing / easier to create external dsl's - antlr port? * smtp * uri - a complete uri implementation, not the simple validation that exists now * wsdl - far from everything is REST * ftp (this is perhaps included with curl?) * globalization - languages, number formats etc. * gui - perhaps not best done in phobos, but it's difficult to get up and running to say the least.. * html producer * html parser * cgi/fastcgi * cryptography * oauth And some windows specifics: * "complete" win32 bindings - move the win32 project to etc/c/win32? * better com integration (like http://dsource.org/projects/juno)
Jul 31 2011
On 2011-07-31 13:13, simendsjo wrote:Orange: http://dsource.org/projects/orange/ There are already a quite usable version available. But now I'm currently rewriting most of the library to support more types, among other things.- Jonathan M DavisFrom the top of my head, in no particular order: * serialization* gui - perhaps not best done in phobos, but it's difficult to get up and running to say the least..DWT: http://dsource.org/projects/dwt Needs: * Bug fixes * Finish the Mac OS X port * Update to later SWT versions * Port to 64bit * More developers -- /Jacob Carlborg
Jul 31 2011
On Sun, Jul 31, 2011 at 6:13 AM, simendsjo <simendsjo gmail.com> wrote:On 31.07.2011 07:27, Jonathan M Davis wrote:FTP, HTTP, and SMTP are the protocols that are included in etc.curl.I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisFrom the top of my head, in no particular order: * xml * csv * ini * logging * database interface * serialization * parsing / easier to create external dsl's - antlr port? * smtp * uri - a complete uri implementation, not the simple validation that exists now * wsdl - far from everything is REST * ftp (this is perhaps included with curl?) * globalization - languages, number formats etc. * gui - perhaps not best done in phobos, but it's difficult to get up and running to say the least.. * html producer * html parser * cgi/fastcgi * cryptography * oauth And some windows specifics: * "complete" win32 bindings - move the win32 project to etc/c/win32? * better com integration (like http://dsource.org/projects/**juno<http://dsource.org/projects/juno> )
Jul 31 2011
On 31/07/2011 06:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisAsync I/O. -- Robert http://octarineparrot.com/
Jul 31 2011
On 31/07/11 6:27 AM, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisMy wish list: - A good allocator model and integration with standard containers - Fast vector math library suitable for games.
Jul 31 2011
On 31/07/2011 9:51 PM, Peter Alexander wrote:My wish list: - A good allocator model and integration with standard containers - Fast vector math library suitable for games.+1 vector math lib.
Jul 31 2011
Some template/mixin functions which ease generating C or C++ bindings. Same goes for DLLs.
Jul 31 2011
On 31/07/2011 22:15, Brian Hay wrote:On 31/07/2011 9:51 PM, Peter Alexander wrote:+1 for a good math lib (it would be cool if Scid cool become part of phobos after GSOC project) also: standard database lib (including bindings for postgresql, sqlite, etc) gui lib (DWT2?) thanks, filgoodMy wish list: - A good allocator model and integration with standard containers - Fast vector math library suitable for games.+1 vector math lib.
Aug 01 2011
On Sun, 31 Jul 2011 14:51:17 +0300, Peter Alexander <peter.alexander.au gmail.com> wrote:- Fast vector math library suitable for games.Speed is mostly up to the compilers' ability to optimize, especially inlining in this case. We already have math libraries and there are one in the works for phobos, if they are not enough for you please everyone state your requirements.
Aug 02 2011
== Quote from Jonathan M Davis (jmdavisProg gmx.com)'s articleI think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisI could really use a linear algebra library, but the GSoC project I'm mentoring is oriented towards creating one and it's now close to usable. (I'd like to thank Cristi Cobzarenco for doing a great job on his GSoC project so far.) Next in line would be high-level MPI wrappers, like boost::mpi, or something functionally similar, like a std.concurrency that works across multiple address spaces. std.parallelism works great for SMP parallelism (which is what it was designed to do), but sometimes I want an easy way to parallelize stuff across address spaces, too.
Jul 31 2011
Jonathan M Davis:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see.This is not a complete list, I have surely forgotten some interesting things. Some things in modules already present: - Few more higher order functions like amap/afilter/table, something to build an associative array, a redesigned max/min, ecc; - Few more math functions like isLog2, intSqrt, intCubeRoot, etc; - Lazy permutations, combinations, etc; - Few more handy collections, like a stack, deque, hashSet, treeSet, growable circular queue, Union-Find; - Maybe even Range Minimum Query; - Two or three more types of Heaps (like the Fibonacci one); - A very lazy prime number generator range; - A flexible tagged pointer (a struct); - A hierarchical manual memory allocator; - Few more functionalities for std_bitmanip.BitArray and std.bitmanip.bitfields; - Weak references; - A prettyPrinter function; - Tuple slicing and joining; - Some standard exceptions; - In Bugzilla I have some enhancement requests where sometimes I have added the code for a new functions I'd like to be added. Few new modules: - std.graphics: small graphics module, useful for simple quick things and to define a standard basic interface for other graphic D libraries; - std.image: module to read and write png, jpeg, gif, bmp, ppm images; - std.graph: Graph module, with some useful algorithms (BFS, shortest path, connected components, etc). This is also useful to fix an API for external graph packages too; - std.geometry: A small geometry module with very fast 2D, 3D and 4D vectors (for 3D graphics, games, etc), convex hull algorithm, polygon centroid algorithm, to avoid reinventing the wheel every day; - std.operator: standard operators as functions, to be used with higher order functions; - std.icollections: few immutable collections, to be used in parallel code or for safety. Maybe they need their own module. Tools added to the standard distribution: - A statistical profiler like http://h3.gd/code/xfProf/ Bye, bearophile
Jul 31 2011
"bearophile" <bearophileHUGS lycos.com> wrote in message news:j13mhm$1prf$1 digitalmars.com...- std.image: module to read and write png, jpeg, gif, bmp, ppm images;That'd be very nice to have in phobos.
Aug 01 2011
On Sun, 31 Jul 2011 15:49:42 +0200, bearophile <bearophileHUGS lycos.com> wrote:- std.operator: standard operators as functions, to be used with higher order functions;Nice idea. So simple yet so useful. -- Simen
Aug 10 2011
Simen Kjaeraas:Nice idea. So simple yet so useful.It's not an original idea, it's essentially a Phobos version of this Python standard library :-) http://docs.python.org/library/operator.html Bye, bearophile
Aug 10 2011
On 7/30/2011 10:27 PM, Jonathan M Davis wrote:So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Better Unicode support. http://training.perl.com/OSCON2011/index.html
Jul 31 2011
On Jul 31, 11 13:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis1. An officially endorsed XML *and* HTML library that supports Xpath. Preferably with an interface as easy to use as Python's lxml. I don't know how long the current std.xml will stay, if it's upon rewrite please do consider supporting Xpath (or CSS3 selector). (lxml is based on libxml2 and libxslt which are MIT license and may not be compatible with Boost; lxml's source code itself is in BSD) 2. More containers, including: - std.container.HashTable (or allow void[T] in the language). - std.container.List (doubly linked list) - std.container.Deque - std.container.IntervalSet - std.container.Trie (or PatriciaTrie) - Adaptors to RedBlackTree and HashTable, making it a Set, Dictionary (map) and CountedSet (bag/multiset). - Ordered associative array 3. A std.variant.Algebraic that does not rely on typeid (like C++'s Boost.Variant). 4. Wrapper to GSL (= GNU Scientic Library, GPL of course). 5. Unicode normalization (the NFKD stuff) and other Unicode support, preferably as a wrapper to ICU (non-restrictive license: http://source.icu-project.org/repos/icu/icu/trunk/license.html). 6. Rational numbers (std.fraction?). 7. Serialization library (yes I know there's Orange). 8. Support for CSV and plist 9. More pure/ safe/const :)
Jul 31 2011
On 7/31/2011 1:27 AM, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisMy top 3: 1. Database interface. Should support sqlite, mysql, postgres, etc... 2. DWT fixed up and merged into Phobos. 3. Some kind of web framework.
Jul 31 2011
"Johann MacDonagh" <johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 01 2011
On 8/1/11 4:35 PM, Nick Sabalausky wrote:"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 01 2011
Andrei Alexandrescu Wrote:On 8/1/11 4:35 PM, Nick Sabalausky wrote:I think DWT for D2 worked with Windows and Linux (tested on). The port is very Java style, it doesn't have a D layer to make it work nicely with ranges (err last time I used it 3 yrs ago). All the packages are org.eclipse... The library itself is huge and the port isn't complete. It probably isn't a good idea to bring it into Phobos since it needs to be easy to keep up with SWT development. However it might be reasonable to take DWT, mold it into a D like library and continue development separate from SWT. I don't know if that is easier than developing a D2 GUI library from scratch, but having such a library in Phobos is probably a *great* idea."Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in messageInteresting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 01 2011
On 2011-08-02 01:48, Jesse Phillips wrote:Andrei Alexandrescu Wrote:How would the ranges be used in a GUI library?On 8/1/11 4:35 PM, Nick Sabalausky wrote:I think DWT for D2 worked with Windows and Linux (tested on). The port is very Java style, it doesn't have a D layer to make it work nicely with ranges (err last time I used it 3 yrs ago). All the packages are org.eclipse... The library itself is huge and the port isn't complete."Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in messageInteresting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei2. DWT fixed up and merged into Phobos.That'd certainly be nice.It probably isn't a good idea to bring it into Phobos since it needs to be easy to keep up with SWT development. However it might be reasonable to take DWT, mold it into a D like library and continue development separate from SWT. I don't know if that is easier than developing a D2 GUI library from scratch, but having such a library in Phobos is probably a *great* idea.-- /Jacob Carlborg
Aug 02 2011
On Tue, 02 Aug 2011 10:49:45 +0200, Jacob Carlborg wrote:Well, not much thought has gone into it, but I'm thinking list displays could take ranges and provide a range interface. But maybe a ranges laziness is of no benefit and array() isn't so bad. I suppose working with Phobos containers would be a better example. I should probably look at using DWT again. I started used DFL because I needed a dependencyless Windows library for D2 and DWT wasn't there yet, and in general it is pretty big...The port is very Java style, it doesn't have a D layer to make it work nicely with ranges (err last time I used it 3 yrs ago). All the packages are org.eclipse... The library itself is huge and the port isn't complete.How would the ranges be used in a GUI library?
Aug 02 2011
On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:On 8/1/11 4:35 PM, Nick Sabalausky wrote:I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 01 2011
On 8/1/11 7:51 PM, Brad Roberts wrote:On Mon, 1 Aug 2011, Andrei Alexandrescu wrote:Python has something and as far as I can tell people are fine with that. AndreiOn 8/1/11 4:35 PM, Nick Sabalausky wrote:I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard."Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 01 2011
On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote:On 8/1/11 7:51 PM, Brad Roberts wrote:It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last.I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard.Python has something and as far as I can tell people are fine with that. Andrei
Aug 01 2011
Brad Roberts wrote:On Monday, August 01, 2011 7:31:13 PM, Andrei Alexandrescu wrote:It only has a wrapper for the Tkinter (from Tcl/Tk). I don't think a lot of people use it for serious stuff, it's kinda ancient. A lot of people use the Qt bindings though - these are not in the standard library.On 8/1/11 7:51 PM, Brad Roberts wrote:It has something _in the base library_? It has wrappers for all/most of the popular libraries? The standard distributions install some combination of those? I don't use python so I'm ill equipped to discuss, but my guess is that it's not the first but rather the last.I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard.Python has something and as far as I can tell people are fine with that. Andrei
Aug 02 2011
I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles. Nobody is likely to agree on a widget set, but basic drawing functions give a little usability with pretty small cost. I had a decent start a month or two ago but have since stalled out as my schedule became more ridiculous.
Aug 01 2011
Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>:I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles. Nobody is likely to agree on a widget set, but basic drawing functions give a little usability with pretty small cost. I had a decent start a month or two ago but have since stalled out as my schedule became more ridiculous.I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and recently Cairo. If there was a drawing API in Phobos I wish it was like Cairo. While some basic APIs have some special ability (like shadows in the HTML canvas) they often lack some essential functions. Java2D offers a lot, but I consider it bloated, YMMW. When I was writing a tool I came to need more and more advanced features: - fonts and text drawing - clipping - scaling (part of matrix manipulation) - transparency - measuring of the extents of what is about to be drawn I was using GtkD, the D wrapper for Gtk and Gtk lacked a lot of this. Fortunately Gtk comes with Cairo bindings which offered all that. This is just one example and just me, but I really think Cairo's API is very well designed, similar to Java2D and HTML5 Canvas and would be my reference for a drawing API in D. It doesn't need to offer bezier curves and anti-aliasing in the first version, but the idea of filling and stroking shapes or drawing surfaces that can be rendered into each other are kind of a standard now that can be built upon :) - Marco
Aug 01 2011
On 8/2/11, Marco Leise <Marco.Leise gmx.de> wrote:Am 02.08.2011, 04:48 Uhr, schrieb Adam D. Ruppe <destructionator gmail.com>:Johannes Pfau is working on a D2 wrapper for Cairo: https://github.com/jpf91/cairoD Unlike gtkD the bindings are Boost licensed, so I think one could make a small trivial windowing library with Cairo drawing and put that into Phobos. Of course the user would have to install either Gtk itself or the Cairo DLLs from the Gtk website before they can use the code.I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles. Nobody is likely to agree on a widget set, but basic drawing functions give a little usability with pretty small cost. I had a decent start a month or two ago but have since stalled out as my schedule became more ridiculous.I used a few drawing APIs: Delphi/Win32, Java2D, HTML5 Canvas, Gtk+ and recently Cairo. If there was a drawing API in Phobos I wish it was like Cairo. While some basic APIs have some special ability (like shadows in the HTML canvas) they often lack some essential functions. Java2D offers a lot, but I consider it bloated, YMMW. When I was writing a tool I came to need more and more advanced features: - fonts and text drawing - clipping - scaling (part of matrix manipulation) - transparency - measuring of the extents of what is about to be drawn I was using GtkD, the D wrapper for Gtk and Gtk lacked a lot of this. Fortunately Gtk comes with Cairo bindings which offered all that. This is just one example and just me, but I really think Cairo's API is very well designed, similar to Java2D and HTML5 Canvas and would be my reference for a drawing API in D. It doesn't need to offer bezier curves and anti-aliasing in the first version, but the idea of filling and stroking shapes or drawing surfaces that can be rendered into each other are kind of a standard now that can be built upon :) - Marco
Aug 02 2011
On 2-8-2011 4:48, Adam D. Ruppe wrote:I've been thinking about a minimalist drawing library for phobos - just basic 2d stuff, but with easy enough hooks to add more (native api events and handles.+1 I'd very much like to see this implemented.
Aug 04 2011
More powerful regexes (like in .NET). The current one is pretty much unusable due to lack of support for Unicode, and lacks lots of important features (named captures come to mind).
Aug 04 2011
On Thu, 04 Aug 2011 15:50:18 +0000, Mehrdad wrote:More powerful regexes (like in .NET). The current one is pretty much unusable due to lack of support for Unicode, and lacks lots of important features (named captures come to mind).Just a thought -- libpcre is a very popular RE library, available under BSD. It has UTF-8 support, though not support for other Unicode encodings. Google's pcrecpp wrapper might be a source of inspiration. Would a PCRE wrapper be suitable for Phobos? Graham
Aug 04 2011
Am 04.08.2011, 18:42 Uhr, schrieb Graham Fawcett <fawcett uwindsor.ca>:On Thu, 04 Aug 2011 15:50:18 +0000, Mehrdad wrote:I wonder what the general consensus is on wrappers. Berkley Sockets are good, since all supported OSs implement that API somehow. But GUI, PCRE and others need libraries installed. In my perfect world there would be wrappers, but they would work with corresponding libraries on Windows and Posix bases OSs. The idea of package dependencies is just not wide-spread in the Windows world and installing pcre, gtk, cairo, ... together with D on Windows seems clumsy to me :D If these libraries aren't available on Windows then the second best is a unique D implementation. If D was Linux only then I'd agree. I could understand if others say that the D installer for Windows could install those libraries as well. Just my 2 centsMore powerful regexes (like in .NET). The current one is pretty much unusable due to lack of support for Unicode, and lacks lots of important features (named captures come to mind).Just a thought -- libpcre is a very popular RE library, available under BSD. It has UTF-8 support, though not support for other Unicode encodings. Google's pcrecpp wrapper might be a source of inspiration. Would a PCRE wrapper be suitable for Phobos? Graham
Aug 04 2011
On 04.08.2011 19:50, Mehrdad wrote:More powerful regexes (like in .NET). The current one is pretty much unusable due to lack of support for Unicode, and lacks lots of important features (named captures come to mind).I'm working on a replacement engine as GSOC project, both named captures and modern Unicode support are implemented. I plan to wrap up a public beta by the next week, to get some early feedback. In terms of speed in general it seems to be on par with PCRE, but I haven't done any pattern-specific tuning (which PCRE surely does). I looked over all what .NET supports, and right now new engine has support for the most of it's syntactic riches (including character set operations) albeit with slightly different syntax. comment) and setting flags in midair (?im). I'll definitely add free spacing syntax mode (see perl) and setting flags though. Anyway, if you are wondering if I missed any other cool regex feature, just ask :) -- Dmitry Olshansky
Aug 04 2011
On 8/4/2011 10:23 AM, Dmitry Olshansky wrote:On 04.08.2011 19:50, Mehrdad wrote:Dude, that's awesome! Can't wait to see the beta!! :)More powerful regexes (like in .NET). The current one is pretty much unusable due to lack of support for Unicode, and lacks lots of important features (named captures come to mind).I'm working on a replacement engine as GSOC project, both named captures and modern Unicode support are implemented. I plan to wrap up a public beta by the next week, to get some early feedback. In terms of speed in general it seems to be on par with PCRE, but I haven't done any pattern-specific tuning (which PCRE surely does). I looked over all what .NET supports, and right now new engine has support for the most of it's syntactic riches (including character set operations) albeit with slightly different syntax. comment) and setting flags in midair (?im). I'll definitely add free spacing syntax mode (see perl) and setting flags though. Anyway, if you are wondering if I missed any other cool regex feature, just ask :)
Aug 04 2011
Andrei Alexandrescu: Brad Roberts:The situation is quite complex, some notes: - CPython indeed has a GUI toolkit in the standard distribution, it's not native, it's a whole different interpreter with its GUI toolkit (Tcl-Tk), with a thin Python wrapper around it (tkinter). Despite looking like a card castle this somehow works and some people (like me) use this GUI toolkit to write simple GUIs. Scientific programs sometimes enjoy such simple GUIs. - For a lot of time the GUIs created with tkinter didn't look native at all (the GUI were almost ugly (recently Tk has improved a lot on this, now it looks much more native)). And Tk despite having some qualities (efficiency, compactness, flexibility and more), was also limited and "strange" in its usage (it's like working with soft rubber). So people that want to create serious GUIs for Python programs never use tkinter. They use GTK, Wx and lately Qt. So using Python as comparison point for D GUI toolkits in the std library is not the best thing to do, because in a sense the Python std library GUI toolkit is not used by serious people. - I like the idea of having a wide D standard library. But GUI toolkits are large, and they change a lot with time, so I accept to have them as external libraries. - Delphi has a good enough built-in GUI toolkit, and people use it a lot. I have used it plenty. This seems a better comparison point for D. - I'd like a simple graphics module in Phobos, to show simple graphics. It's handy in many situations, and it's useful to establish *standard D-wide* method/function names to plot a point, a line, circle, box, ecc. The same names can later appear in non-Phobos GUI toolkits. - I'd also like a std.image module to load and save images in png, gif, jpeg, ppm, bmp. This is a very common need, even more common than a GUI toolkit, and there are far less ways to load a PNG than to create the API of a GUI toolkit. Bye, bearophileI don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard.Python has something and as far as I can tell people are fine with that.
Aug 01 2011
On Tue, 02 Aug 2011 06:10:29 +0300, bearophile <bearophileHUGS lycos.com> wrote:- I'd also like a std.image module to load and save images in png, gif, jpeg, ppm, bmp. This is a very common need, even more common than a GUI toolkit, and there are far less ways to load a PNG than to create the API of a GUI toolkit.Wrapper over http://nothings.org/stb_image.c and no license issue. Sean Barrett wouldn't mind Boost i think. Though i am not sure it serves the general needs.
Aug 02 2011
Am 02.08.2011, 17:38 Uhr, schrieb so <so so.so>:On Tue, 02 Aug 2011 06:10:29 +0300, bearophile <bearophileHUGS lycos.com> wrote:Are you serious?! : " QUICK NOTES: Primarily of interest to game developers and other people who can avoid problematic images and only need the trivial interface JPEG baseline (no JPEG progressive) PNG 8-bit only [...] " I don't mind missing support for exotic varieties like um... RGB JPEG, but I think this file lacks too much support to be 'standard'. It fits well for what is described in the notes though.- I'd also like a std.image module to load and save images in png, gif, jpeg, ppm, bmp. This is a very common need, even more common than a GUI toolkit, and there are far less ways to load a PNG than to create the API of a GUI toolkit.Wrapper over http://nothings.org/stb_image.c and no license issue. Sean Barrett wouldn't mind Boost i think. Though i am not sure it serves the general needs.
Aug 02 2011
You guys have no idea, how much its hurting D. At my work place, we wanted to quickly develop a small gui tool, considered python and D, guess which we picked? pyhton, just because tkInter comes packaged with python, even though it sucks. Now tkInter in python became the official gui lib for such tools! -SaiI don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard.Python has something and as far as I can tell people are fine with that. Andrei
May 09 2012
On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <braddr slice-2.puremagic.com> wrote:I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
2011/8/2 so <so so.so>On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts < braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao <jcao219 gmail.com>:2011/8/2 so <so so.so>Why is it so important that the GUI library is included in the std library? Unless it is like Delphi, VisualBasic & others that it comes with a GUI designer and an IDE I personally find it ok to look for the best library for your project on the internet (small Windows-only, cross-platform, ...) :)On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts < braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
On Tue, Aug 2, 2011 at 11:34 AM, Marco Leise <Marco.Leise gmx.de> wrote:Am 02.08.2011, 17:35 Uhr, schrieb Jimmy Cao <jcao219 gmail.com>: 2011/8/2 so <so so.so>You're right, it's probably not that important. I guess it's most important that a cross-platform GUI library can simply be easily installed and set up (with some sort of D package manager).On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <Why is it so important that the GUI library is included in the std library? Unless it is like Delphi, VisualBasic & others that it comes with a GUI designer and an IDE I personally find it ok to look for the best library for your project on the internet (small Windows-only, cross-platform, ...) :)braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, Brad I agree, GUIs (and other huge libraries that everyone has their ownfavorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
On 2011-08-02 19:58, Jimmy Cao wrote:You're right, it's probably not that important. I guess it's most important that a cross-platform GUI library can simply be easily installed and set up (with some sort of D package manager).I think that would make most sense. -- /Jacob Carlborg
Aug 02 2011
Jimmy Cao wrote:2011/8/2 so <so so.so>.NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference.On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts < braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
On Aug 3, 11 13:53, Lutger Blijdestijn wrote:Jimmy Cao wrote:There was a D.net (which seems no longer updated), and when D runs on .NET, the language can use all .NET libraries like WinForms and WPF immediately, and there's no need to have another GUI lib.2011/8/2 so<so so.so>.NET and perhaps even until microsoft adopts it. I don't think a standard gui lib will make any difference.On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts< braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 03 2011
There's pdcurses which apparently works on Windows. It's public domain. I'm not sure if this is the one that supports ASCII escape codes though. And I haven't tested it. Home: http://pdcurses.sourceforge.net/ Binaries: http://gnuwin32.sourceforge.net/packages/pdcurses.htm
Aug 03 2011
This is interesting: http://openil.sourceforge.net/ In particular that news post from 2010. Apparently the author might consider changing the license if there's interest in it.
Aug 03 2011
2011/8/2 so <so so.so>On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts < braddr slice-2.puremagic.com> wrote: I don't think that any gui library belongs in phobos because there'sIf a GUI library were included in Phobos, that would make D a much better possible in the future. I see why it might not be possible, though.essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
On 8/2/11 10:25 AM, so wrote:On Tue, 02 Aug 2011 03:51:56 +0300, Brad Roberts <braddr slice-2.puremagic.com> wrote:I think a small and simple GUI would be the worst of all worlds. AndreiI don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradI agree, GUIs (and other huge libraries that everyone has their own favorite) don't belong standard library. Other languages get away with it because they are either platform themselves or support only one platform. Another reason not to include them to the standard library, remember phobos has rules (we might need to change many things). But if we have something small, simple and cross-platform somewhere, why not!
Aug 02 2011
Plus that would tie any updates to the GUI with DMD releases. Bad idea!
Aug 02 2011
On 8/1/2011 5:51 PM, Brad Roberts wrote:I don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library.Also, remember, we did try to endorse a standard gui library for D a while back. It was a disaster on every front.
Aug 02 2011
On 2011-08-02 21:48, Walter Bright wrote:On 8/1/2011 5:51 PM, Brad Roberts wrote:Yes, that was very unfortunate that basically when you announced DWT (the old one) as the standard GUI library the development stopped. -- /Jacob CarlborgI don't think that any gui library belongs in phobos because there's essentially no agreement about what cross-platform library is standard. Pick any random 10 gui developers about what library they used (assuming they do anything cross-platform) and you'll get more than 1 answer. I'd be shocked if you get a clear enough majority to suggest 1 that'd make a big set of people happy. Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library.Also, remember, we did try to endorse a standard gui library for D a while back. It was a disaster on every front.
Aug 02 2011
On 8/1/2011 8:51 PM, Brad Roberts wrote:Sorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradAfter reading through this thread I now agree with you. I do think we need: 1. Ability to quickly install DWT (D package manager) 2. Links and documentation on d-p-l.org That way it's sort of the official GUI library, but we're not tying up Phobos development with this gigantic code base. Do you think this is a good idea? I think having some official GUI makes designers for a particular library. What about wxWidgets? It has C bindings making the wrappers easy. There's already wxD (http://wxd.sourceforge.net/), but I'm not sure how mature it is.
Aug 02 2011
On 8/1/2011 8:51 PM, Brad Roberts wrote:I see no need for an official GUI. If there were an obvious winner, then maybe, but there isn't. And as Walter pointed out, apparently there was a previous attempt at endorsing a GUI library as the standard GUI library for D in the past and that went quite badly. Having a package management tool for D would definitely help, and maybe some of the more major D projects should be listed on the official site so that it's easier for people to know about them and find them. But trying to make a particular GUI library official is not a good idea IMHO. What we need is for it to be easier to find and use major D projects such as GUI toolkits for D not to try and put them in the standard library so that it's easier for people to find them. - Jonathan M DavisSorry, the gui library landscape just doesn't approach being obvious enough to be in the standard library. My 2 cents, BradAfter reading through this thread I now agree with you. I do think we need: 1. Ability to quickly install DWT (D package manager) 2. Links and documentation on d-p-l.org That way it's sort of the official GUI library, but we're not tying up Phobos development with this gigantic code base. Do you think this is a good idea? I think having some official GUI makes designers for a particular library. What about wxWidgets? It has C bindings making the wrappers easy. There's already wxD (http://wxd.sourceforge.net/), but I'm not sure how mature it is.
Aug 02 2011
On 2011-08-02 00:34, Andrei Alexandrescu wrote:On 8/1/11 4:35 PM, Nick Sabalausky wrote:Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bit Graphics systems used: Windows - win32 Posix - GTK2 Mac OS X - Cocoa I would be willing to take on this task, but it's not a priority I have right now. If anyone else wants to do it I have no problems with that. It would probably be best if at least three people did the integration, ,one for windows, one for linux and one for osx, and work close together for any non-platform specific code. I'm using Mac OS X as my main system. BTW, the Mac OS X specific code could really benefit from Michel Fortin's Objective-C fork of DMD. -- /Jacob Carlborg"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...Interesting. What platforms does DWT work on? What is the general community opinion on integrating it within Phobos? Is there anyone willing to take on this task? Thanks, Andrei1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 02 2011
"Jacob Carlborg" <doob me.com> wrote in message news:j18dfe$20rj$1 digitalmars.com...Windows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bitIt does Solaris, HPUX, and AIX, but not BSD??
Aug 02 2011
On 2011-08-02 21:57, Nick Sabalausky wrote:"Jacob Carlborg"<doob me.com> wrote in message news:j18dfe$20rj$1 digitalmars.com...I'm just listing was officially supported with binary releases. I don't see a reason why GTK on BSD wouldn't work. -- /Jacob CarlborgWindows and Linux (GTK) 32bit. I'm in the middle of porting the Mac OS X version. These are the platforms that SWT supports: Windows 32/64bit Windows CE Linux 32/64bit and PPC64 Solaris 10 x86 and Sparc HPUX IA64_32 AIX PPC/64 Mac OS X 32/64bitIt does Solaris, HPUX, and AIX, but not BSD??
Aug 02 2011
On 2011-08-01 23:35, Nick Sabalausky wrote:"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...That would be an enormous addition (in code) to Phobos. I would guess that the code base of DWT, for just one platform, is larger than the whole Phobos. -- /Jacob Carlborg1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff2. DWT fixed up and merged into Phobos.That'd certainly be nice.
Aug 02 2011
On Tue, Aug 2, 2011 at 5:45 PM, Jacob Carlborg <doob me.com> wrote:On 2011-08-01 23:35, Nick Sabalausky wrote:ssage"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> =C2=A0wrote in me=e-web-stuffnews:j1501g$tbs$1 digitalmars.com...1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-languag=tThat would be an enormous addition (in code) to Phobos. I would guess tha=2. DWT fixed up and merged into Phobos.That'd certainly be nice.the code base of DWT, for just one platform, is larger than the whole Phobos. -- /Jacob CarlborgNot sure what point adding these kinds of things to phobos would serve. As far as I can see it all you're going to do is discourage alternative implementations and encourage people to code before thinking about their own requirements. And for that you've made phobos significantly larger and harder to maintain= .
Aug 02 2011
On 8/1/2011 5:35 PM, Nick Sabalausky wrote:"Johann MacDonagh"<johann.macdonagh.no spam.gmail.com> wrote in message news:j1501g$tbs$1 digitalmars.com...Ah nice, I knew he was working on a web framework but I wasn't sure about database support. Perhaps we should start taking a look at it, making it "Phobos-like", and create bindings for a set of databases.1. Database interface. Should support sqlite, mysql, postgres, etc... 3. Some kind of web framework.Agreed, but fortunately Adam's stuff for that is shaping up nicely: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Aug 02 2011
Johann MacDonagh wrote:Perhaps we should start taking a look at it, making it "Phobos-like", and create bindings for a set of databases.In my collection, I have (kinda crappy) implementations of my interface for mysql, postgres, sqlite and most recently ODBC. Since they all use C libs though, I'm not really completely sure on if they are license compatible with phobos. And, of course, I'm happy with a minimal set of features; I'm happy enough with strings since it's better than PHP, so mission accomplished. (I also have a lot of other code. Check out the readme in my github for a listing of many of them.)
Aug 02 2011
On 8/2/2011 7:39 PM, Adam Ruppe wrote:Johann MacDonagh wrote:Sounds like a good starting point. I've also written some code for allowing "LINQ" style queries in D. You'd be able to do something like: auto x = new SqliteConnection("mydata.db"); foreach(y; x.MyTable.where("someField > 10")) { // y is a wrapper around Variant[string] with some opDispatch magic writeln(to!string(y.MyField)); writeln(to!int(y.SomeOtherField)); } There were other things you could chain, such as: x.MyTable.startAt(20).limit(10).where("blah").select("somefield", "sometingElse"); You'd also be able to do something like x.MyTable.select!MyStruct(); which would pull field names out of struct fields, and return a range of structs rather than something that has to go through the Variant[string] stuff. It's just a prototype for now, I have a working POC for sqlite3 (however it doesn't support the where clause ;) ), but it might be something useful for quickly prototyping code that deals with databases. Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about? Then we can discuss licensing issues with various databases systems.Perhaps we should start taking a look at it, making it "Phobos-like", and create bindings for a set of databases.In my collection, I have (kinda crappy) implementations of my interface for mysql, postgres, sqlite and most recently ODBC. Since they all use C libs though, I'm not really completely sure on if they are license compatible with phobos. And, of course, I'm happy with a minimal set of features; I'm happy enough with strings since it's better than PHP, so mission accomplished. (I also have a lot of other code. Check out the readme in my github for a listing of many of them.)
Aug 02 2011
Johann MacDonagh wrote:On 8/2/2011 7:39 PM, Adam Ruppe wrote:Nice! Please also take a look on https://github.com/pszturmaj/ddb.Johann MacDonagh wrote:Sounds like a good starting point. I've also written some code for allowing "LINQ" style queries in D. You'd be able to do something like: auto x = new SqliteConnection("mydata.db"); foreach(y; x.MyTable.where("someField > 10")) { // y is a wrapper around Variant[string] with some opDispatch magic writeln(to!string(y.MyField)); writeln(to!int(y.SomeOtherField)); } There were other things you could chain, such as: x.MyTable.startAt(20).limit(10).where("blah").select("somefield", "sometingElse"); You'd also be able to do something like x.MyTable.select!MyStruct(); which would pull field names out of struct fields, and return a range of structs rather than something that has to go through the Variant[string] stuff. It's just a prototype for now, I have a working POC for sqlite3 (however it doesn't support the where clause ;) ), but it might be something useful for quickly prototyping code that deals with databases. Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about? Then we can discuss licensing issues with various databases systems.Perhaps we should start taking a look at it, making it "Phobos-like", and create bindings for a set of databases.In my collection, I have (kinda crappy) implementations of my interface for mysql, postgres, sqlite and most recently ODBC. Since they all use C libs though, I'm not really completely sure on if they are license compatible with phobos. And, of course, I'm happy with a minimal set of features; I'm happy enough with strings since it's better than PHP, so mission accomplished. (I also have a lot of other code. Check out the readme in my github for a listing of many of them.)
Aug 02 2011
Johann MacDonagh wrote:Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about?Of course, go ahead! You might also want to look up Piotr Szturmaj's database code. He has some nice Postgres code including a D struct -> db table ORM thingy.
Aug 02 2011
On 8/2/2011 8:22 PM, Adam D. Ruppe wrote:Johann MacDonagh wrote:Yep, he posted above ;). Do you know of any other database interfaces people have been working on? I'll make this my next priority after porting the D lexer.Would you mind if I take some of your ideas and come up with a proposal for the D community to talk about?Of course, go ahead! You might also want to look up Piotr Szturmaj's database code. He has some nice Postgres code including a D struct -> db table ORM thingy.
Aug 02 2011
Johann MacDonagh wrote:Do you know of any other database interfaces people have been working on?Not off the top of my head.
Aug 02 2011
On Monday 01 August 2011 04:03:11 Andrej Mitrovic wrote:Are you sure it's LGPL? There's two licenses AFAIK, GPL and Artistic. I'm not seeing any mention of LGPL in the code.It could be GPL. I don't remember whether it's GPL or LGPL, but it doesn't really matter as far as Phobos goes. It needs to be Boost for Phobos, and Walter gave his permission to port dmd's lexer over to D with the Boost license, and no such permission has been given from the ddmd guys. Now, I haven't asked for it yet either. It hasn't been high enough on my priority list to deal with that yet, and I want to do the majority of the port myself to ensure that I understand it. Looking at ddmd and possibly copying some of what it did would be helpful, so I'd like to get the permission thing sorted out with ddmd if possible. I just haven't taken the time to do it. Regardless, the point is that dmd and ddmd are not under Boost - regardless of whether they're under GPL or LGPL - and without permission from the appropriate copyright holders, a port can't be moved to Boost. - Jonathan M Davis
Jul 31 2011
Licenses are the greatest code smell.
Jul 31 2011
streams and network programming is most desirable, this also impacts other libraries. Another big one is async programming. Some kind of unified, higher level framework to deal with this could be a huge help - it's a hard problem. It's interesting to see that in .NET a lot of new stuff concerning async programming is coming out, suggesting that the (many) existing patterns are feature with the async/await keywords. There is also the reactive extensions library for async streams: http://msdn.microsoft.com/en-us/data/gg577609. Most interesting about this one is how easy it is to compose async operations.
Aug 01 2011
Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis1. Cryptography (I already wrote all SHA hash implementations and HMAC, they will be open sourced under Boost license, I'm also working on Rijndael/AES impl.) some of the proposed namespaces (just thinking loud): std.crypto.cipher - block and stream ciphers std.crypto.hash - message digests (SHA1, RIPEMD, ...) std.crypto.mac - message auth codes like HMAC, CMAC, UMAC std.crypto.mode - block cipher modes like CBC, GCM, ... std.crypto.padding - padding schemes std.crypto.pki - asymmetric cryptography (RSA), PKI std.crypto.x509 - certificate support 2. Easy to use non-GC threads for soft real time support. Non-GC threads must not be suspended by the GC and they must support some kind of reliable communication with normal (GC) threads. This should be similar to IPC, where there's no shared memory between GC and non-GC threads. Consider running two separate programs, one written in D with GC support and one written in plain C. These programs communicate with each other using some IPC mechanism. The latter is never suspended. The whole point is to make equivalent of this configuration in a single executable using mixture of GC and non-GC threads.
Aug 01 2011
On 02-08-2011 01:51, Piotr Szturmaj wrote:Jonathan M Davis wrote:Sounds good to me! - AlexI think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis1. Cryptography (I already wrote all SHA hash implementations and HMAC, they will be open sourced under Boost license, I'm also working on Rijndael/AES impl.) some of the proposed namespaces (just thinking loud): std.crypto.cipher - block and stream ciphers std.crypto.hash - message digests (SHA1, RIPEMD, ...) std.crypto.mac - message auth codes like HMAC, CMAC, UMAC std.crypto.mode - block cipher modes like CBC, GCM, ... std.crypto.padding - padding schemes std.crypto.pki - asymmetric cryptography (RSA), PKI std.crypto.x509 - certificate support
Aug 02 2011
Am 02.08.2011 01:51, schrieb Piotr Szturmaj:Jonathan M Davis wrote:Maybe http://www.dsource.org/projects/dcrypt could be used. Cheers, - DanielI think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis1. Cryptography (I already wrote all SHA hash implementations and HMAC, they will be open sourced under Boost license, I'm also working on Rijndael/AES impl.) some of the proposed namespaces (just thinking loud): std.crypto.cipher - block and stream ciphers std.crypto.hash - message digests (SHA1, RIPEMD, ...) std.crypto.mac - message auth codes like HMAC, CMAC, UMAC std.crypto.mode - block cipher modes like CBC, GCM, ... std.crypto.padding - padding schemes std.crypto.pki - asymmetric cryptography (RSA), PKI std.crypto.x509 - certificate support
Aug 02 2011
On 2011-07-31 07:27, Jonathan M Davis wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisSome kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar. -- /Jacob Carlborg
Aug 02 2011
On 02-08-2011 18:44, Jacob Carlborg wrote:On 2011-07-31 07:27, Jonathan M Davis wrote:Perhaps a curses binding of some sort? - AlexI think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisSome kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar.
Aug 02 2011
On 2011-08-02 19:45, Alex Rønne Petersen wrote:On 02-08-2011 18:44, Jacob Carlborg wrote:Something like that. -- /Jacob CarlborgSome kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar.Perhaps a curses binding of some sort? - Alex
Aug 02 2011
"Alex Rnne Petersen" <xtzgzorex gmail.com> wrote in message news:j19d45$pt5$1 digitalmars.com...On 02-08-2011 18:44, Jacob Carlborg wrote:Maybe for linux, but it should be cross-platform and therefore use the Win API for that stuff on Windows. (For some bizarre reason, ANSI display support was removed from approx Win2k onward.)Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar.Perhaps a curses binding of some sort?
Aug 02 2011
There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Btw I've tried using WinAPI for console coloring, it's so damn clumsy to use. -_-
Aug 02 2011
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message news:mailman.2068.1312316161.14074.digitalmars-d puremagic.com...There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls.Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+: http://en.wikipedia.org/wiki/ANSI_escape_code#Windows_and_DOS Granted, that doesn't cite any sources, unfortunately. But my experience porting the download progress bar in DVM to Windows supports what that Wikipedia article says. I had to rip out the escape codes and just use carriage-return (without line-feed). Although I suppose it's possible there are non-ANSI escape codes that I'm not aware of.Btw I've tried using WinAPI for console coloring, it's so damn clumsy to use. -_-I've never used it, but I don't doubt that. The WinAPI can be pretty clumsy in general (due in no small part to being so C-centric).
Aug 02 2011
On 8/2/2011 8:02 PM, Nick Sabalausky wrote:I've never used it, but I don't doubt that. The WinAPI can be pretty clumsy in general (due in no small part to being so C-centric).And backwards compatibility. Nothing like using the BlahExEx() functions ;)
Aug 02 2011
On 8/3/11, Nick Sabalausky <a a.a> wrote:"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message news:mailman.2068.1312316161.14074.digitalmars-d puremagic.com...Yes that's why I said there was a project that brought them back. I can't recall the name though :/There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls.Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+:
Aug 02 2011
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message news:mailman.2071.1312335864.14074.digitalmars-d puremagic.com...On 8/3/11, Nick Sabalausky <a a.a> wrote:Oh, I thought you meant it used them internally."Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message news:mailman.2068.1312316161.14074.digitalmars-d puremagic.com...Yes that's why I said there was a project that brought them back. I can't recall the name though :/There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls.Hmm, see that's the problem, the ANSI escape codes don't really exist in Win2K+:
Aug 02 2011
I'll find the damn thing, gimme a day. :p
Aug 02 2011
On 8/2/2011 1:15 PM, Andrej Mitrovic wrote:There's a win32 curses-like library around afaik. It uses escape codes instead of WinAPI calls. Btw I've tried using WinAPI for console coloring, it's so damn clumsy to use. -_-I've used this for 25 years now. http://www.digitalmars.com/rtl/disp.html
Aug 04 2011
On 8/4/11, Walter Bright <newshound2 digitalmars.com> wrote:I've used this for 25 years now. http://www.digitalmars.com/rtl/disp.htmlThat's freaking great. And it's already in snn.lib. However this doesn't work on Linux, right? Works great in D on win32. Thanks W.
Aug 05 2011
On 8/5/2011 11:12 AM, Andrej Mitrovic wrote:On 8/4/11, Walter Bright<newshound2 digitalmars.com> wrote:Right, though porting it wouldn't be hard.I've used this for 25 years now. http://www.digitalmars.com/rtl/disp.htmlThat's freaking great. And it's already in snn.lib. However this doesn't work on Linux, right?Works great in D on win32. Thanks W.
Aug 06 2011
product(), combinations(), permutations(), etc, are missing from Phobos.
Aug 06 2011
On 2011-08-02 22:01, Nick Sabalausky wrote:"Alex Rnne Petersen"<xtzgzorex gmail.com> wrote in message news:j19d45$pt5$1 digitalmars.com...Actually when I think about it I've written a simple library like that in C++ for a school project. I wonder if I still have it somewhere. -- /Jacob CarlborgOn 02-08-2011 18:44, Jacob Carlborg wrote:Maybe for linux, but it should be cross-platform and therefore use the Win API for that stuff on Windows. (For some bizarre reason, ANSI display support was removed from approx Win2k onward.)Some kind of console library to easy handle input from a user, displaying progress bars, outputting text in different colors and similar.Perhaps a curses binding of some sort?
Aug 02 2011
Jonathan M Davis Wrote:I think that it would be useful to query the community for what piece of library functionality they don't currently have in D and would most like to see. For instance, there is no official logging framework in D or any 3rd party libraries which do it AFAIK. So, that could be one type of functionality that you may like to see. Now, there is a prospective implementation for std.log which shouldn't be all that far away from being reviewed, so listing that here wouldn't be all that useful, since it's on its way. But what other major functionality do you miss in D that other languages' that you use have available in their libraries? My hope here would be that we could get some good ideas going here such that we have can have a better idea what type of functionality it would be particularly useful to be working on for Phobos or 3rd party D libraries for the community, and maybe it'll even get some people to actually go and work on these ideas so that we can improve the libraries that we have to work with in D. We can always use more help, and we definitely need a richer library ecosystem for D. But even just discussing ideas could be of benefit. So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M DavisI'm nearing completion on an arbitrary-precision floating point library, along with implementations of decimal32, decimal64 and decimal128 structs. Paul
Aug 02 2011
On Tue, 02 Aug 2011 20:04:40 +0200, Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> wrote:I'm nearing completion on an arbitrary-precision floating point library, along with implementations of decimal32, decimal64 and decimal128 structs.Awesome. -- Simen
Aug 10 2011
Nice to have, a command-line parser. Jonathan M Davis wrote:So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs? - Jonathan M Davis
Aug 06 2011
On 06.08.2011 19:01, albatroz wrote:Nice to have, a command-line parser.http://www.d-programming-language.org/phobos/std_getopt.html ?
Aug 06 2011
A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.
Aug 07 2011
On 07.08.2011 12:09, Mehrdad wrote:A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText -- Dmitry Olshansky
Aug 07 2011
On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote:On 07.08.2011 12:09, Mehrdad wrote:D (and Phobos in general) assumes that char in UTF-8, wchar is UTF-16, and dchar is UTF-32. You're going to get an exception thrown pretty quickly if you're trying to use those types with values that don't match those encodings. As such, readText assumes that the file is in whatever encoding the character type is that it's instantiated with. So, if you try and read in a file which doesn't match the character encoding of the character type that you're using (which is char by default), you're going to get a UtfException. What Mehrdad wants is a way to read in a file with an encoding other than UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's BOM, and then convert it it to whatever encoding is that the character type that readText is using uses. readText doesn't currently do anything of the sort. At this point, dealing with anything which has an encoding other than UTF-8, UTF-16, or UTF-32 is problematic in D. std.encoding helps, but it's not necessarily all that good (Andrei considers it a failed experiment which either needs to be redesigned or removed). So, one of the things that still needs to be figured out for Phobos is how to better handle encodings other than UTF-8, UTF-16, and UTF-32. For the most part, other encodings are likely to be dealt with only when reading or writing I/O while UTF-8, UTF-16, and UTF-32 are dealt with inside of D programs, but we still need to fix things so that we can readily deal with I/O that isn't UTF-8, UTF-16, or UTF-32. - Jonathan M DavisA readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText
Aug 07 2011
On 8/7/2011 3:21 AM, Jonathan M Davis wrote:On Sunday 07 August 2011 14:08:06 Dmitry Olshansky wrote:Yeah, although I don't mean anything /other/ than those -- I only care about Unicode, but I think it should be auto-detected, not based on the template parameter. On 8/7/2011 6:21 AM, Andrei Alexandrescu wrote:On 07.08.2011 12:09, Mehrdad wrote:... What Mehrdad wants is a way to read in a file with an encoding other than UTF-8, UTF-16, or UTF-32, have it autodetect the encoding by reading the file's BOM, and then convert it it to whatever encoding is that the character type that readText is using uses.A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readTextI think we could and should change readText to do the BOM trick. It's been on my mind forever.I /do/ have an implementation, but it's (1) only for Windows, (2) hastily written (no error checking or whatever), and (3) doesn't work for UTF-16 BE (although it works for LE), and (4) only returns the result in UTF-8. It's a starting point, though. An added bonus is the fact that it actually looks at the file data as well, so the heuristic is rather nice. pragma(lib, "advapi32.lib"); extern(Windows) BOOL IsTextUnicode(in void* pBuffer, int cb, int* lpi); string readText(const(char)[] name) { auto data = cast(char[])file.read(name); int test = 0xFFFF; if (IsTextUnicode(data.ptr, data.length, &test)) { return (cast(wchar[])(test & 0x00088 ? data[2 .. $] : data)).toUTF8(); } else { return (data.startsWith([0xEF, 0xBB, 0xBF]) ? data[3 .. $] : data).toUTF8(); } }
Aug 07 2011
On 8/7/11 5:08 AM, Dmitry Olshansky wrote:On 07.08.2011 12:09, Mehrdad wrote:I think we could and should change readText to do the BOM trick. It's been on my mind forever. AndreiA readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.Well the name is here, dunno if it meets your expectations: http://d-programming-language.org/phobos/std_file.html#readText
Aug 07 2011
"Mehrdad" <wfunction hotmail.com> wrote in message news:j1lh84$2n2j$1 digitalmars.com...A readText() function that would read a text file (**and** autodetect its encoding from its BOM) would be of great help.http://www.dsource.org/projects/semitwist/browser/trunk/src/semitwist/util/io.d#L24 I agree a function like that needs to be in Phobos, though.
Aug 07 2011
On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games). -- Simen
Aug 10 2011
On 10.08.2011 19:02, Simen Kjaeraas wrote:On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:Second the full OS bindings. etc\c\win32 would be really nice. You'll not get cross platform support, but at least you have it handy.So, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).
Aug 10 2011
On 2011-08-10 19:02, Simen Kjaeraas wrote:On Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:Phobos already have an XML module, although not very good. For OpenGL bindings there is Derelict: http://www.dsource.org/projects/derelict -- /Jacob CarlborgSo, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).
Aug 10 2011
On Thu, 11 Aug 2011 08:58:28 +0200, Jacob Carlborg <doob me.com> wrote:On 2011-08-10 19:02, Simen Kjaeraas wrote:I know. As far as I can see, D is a good option for indie gamedevs and hobbyists who want to try their hand at making games. For that reason, a 'batteries included' version would be a good idea, IMO. -- SimenOn Sun, 31 Jul 2011 07:27:19 +0200, Jonathan M Davis <jmdavisProg gmx.com> wrote:Phobos already have an XML module, although not very good. For OpenGL bindings there is Derelict: http://www.dsource.org/projects/derelictSo, what major functionality which we don't currently have would you like to see in either Phobos or in a 3rd party library so that you could use it in your D programs?Database connectivity, XML, OpenGL bindings, full OS bindings, vector math (think games).
Aug 11 2011