Jump to page: 1 25  
Page
Thread overview
Phobos packages a bit confusing
Nov 29, 2009
retard
Nov 29, 2009
Jason House
Nov 29, 2009
retard
Nov 29, 2009
dsimcha
Nov 29, 2009
retard
Nov 29, 2009
dsimcha
Nov 29, 2009
Adam D. Ruppe
Nov 29, 2009
retard
Nov 30, 2009
Nick Sabalausky
Nov 30, 2009
dsimcha
Nov 30, 2009
retard
Nov 30, 2009
KennyTM~
Nov 30, 2009
Ary Borenszweig
Nov 30, 2009
Leandro Lucarella
Nov 30, 2009
retard
Nov 30, 2009
Denis Koroskin
Nov 30, 2009
KennyTM~
Nov 30, 2009
retard
Nov 30, 2009
dsimcha
Nov 30, 2009
dsimcha
Nov 30, 2009
Pelle Månsson
Nov 30, 2009
bearophile
Dec 01, 2009
bearophile
Dec 01, 2009
Pelle Månsson
Dec 01, 2009
Denis Koroskin
Dec 01, 2009
Pelle Månsson
Dec 01, 2009
Rainer Deyke
Dec 01, 2009
bearophile
Dec 02, 2009
retard
Dec 02, 2009
Pelle Månsson
Dec 02, 2009
retard
Dec 02, 2009
Pelle Månsson
Dec 02, 2009
Walter Bright
Dec 02, 2009
bearophile
Dec 02, 2009
Pelle Månsson
Dec 02, 2009
Rainer Deyke
Dec 02, 2009
Jérôme M. Berger
Nov 30, 2009
Nick Sabalausky
Dec 01, 2009
torhu
Nov 30, 2009
dsimcha
Nov 30, 2009
retard
Nov 30, 2009
Nick Sabalausky
November 29, 2009
Hi

after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.

For instance, it took two of us 15 minutes to build a program that reads a line from user, converts the string to a natural number, adds one, and finally prints it to the screen. Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.

When writing this, I already forgot what package contained the to!
template. My intuition says it should be in
 * std.stdint [int related operations]
 * std.format [number formats?]
 * std.typecons [we're constructing a int from a string]
 * std.string [the input was a string, maybe toInt is a string operation]
 * std.numeric [it's a numeric operation, isn't it]

I admit using higher level languages has made major damage to my brain ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather intuitive, but in Phobos the set of packages and their contents feels more or less arbitrary. Is there anything that can be done?
November 29, 2009
retard Wrote:

> Hi
> 
> after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.
> 
> For instance, it took two of us 15 minutes to build a program that reads a line from user, converts the string to a natural number, adds one, and finally prints it to the screen. Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.

That's an interesting example considering how Tango IO is way more complex. Comparatively speaking, 15 minutes is great!

That being said, there probably are ways to make D2 Phobos easier to use.



> When writing this, I already forgot what package contained the to! template.

std.conv (for conversions)


> My intuition says it should be in
>  * std.stdint [int related operations]
>  * std.format [number formats?]
>  * std.typecons [we're constructing a int from a string]
>  * std.string [the input was a string, maybe toInt is a string operation]
>  * std.numeric [it's a numeric operation, isn't it]
> 
> I admit using higher level languages has made major damage to my brain ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather intuitive, but in Phobos the set of packages and their contents feels more or less arbitrary. Is there anything that can be done?

Any massively used language is easier to use because a google search turns up similar code. I've found both D2 Phobos and Tango to be easy to use once you start. Tango was easier to find where most things were, but was amazingly tough to assemble generic pieces for IO. I remember reading line buffered text from standard in was way simpler with D2 Phobos.

November 29, 2009
retard wrote:
> Hi
> 
> after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.
> 
> For instance, it took two of us 15 minutes to build a program that reads a line from user, converts the string to a natural number, adds one, and finally prints it to the screen. Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.
> 
> When writing this, I already forgot what package contained the to! template. My intuition says it should be in
>  * std.stdint [int related operations]
>  * std.format [number formats?]
>  * std.typecons [we're constructing a int from a string]
>  * std.string [the input was a string, maybe toInt is a string operation]
>  * std.numeric [it's a numeric operation, isn't it]
> 
> I admit using higher level languages has made major damage to my brain ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather intuitive, but in Phobos the set of packages and their contents feels more or less arbitrary. Is there anything that can be done?

These are great points. I personally consider import files a necessary evil. There are a couple of things that make me hopeful about simplifying the situation:

a) D parses fast enough to allow importing extensive modules;

b) The "no-hijack" approach allows liberal importing of modules without fear of serious name clashes.

Walter and I discussed quite a few times the possibility of defining std.all that publically imports all of std. My experiments show that a short script importing std.all will compile slower, but not too slow, compared to a script that only import a few modules.

One other possibility would be to define some generic modules that group together useful lower-level modules. The question is of course how to name those aggregation modules (std.common?) and what they should include.

Some PR or tips on how to search the documentation may also be helpful. If you navigate to Phobos' homepage http://digitalmars.com/d/2.0/phobos/phobos.html and then enter

conversion

in the search box, std.conv comes up first. Also, the same module comes up first if you search this with google:

d programming language conversion

It would be great to improve D and Phobos accessibility for first-time users.

(To my personal satisfaction, searching google for

std::algorithm

puts D's std.algorithm in the third or fifth position (depending how you count), after the obligatory C++ reference sites.)


Andrei
November 29, 2009
On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
> after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.

Are you familiar with C's standard library? Phobos is loosely based on it,
so if you can think of where you'd find it in C, it won't be far off in phobos.

> Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.

http://digitalmars.com/d/2.0/phobos/std_stdio.html#File

stdin is just an instance of that struct - directly analogous to how stdin in C is a FILE*. (D actually used C's FILE* directly for the longest time.)

>  * std.string [the input was a string, maybe toInt is a string operation]

That's where it used to be, but now the generic to!() template does it all, including non string types, so it gets its own module.

> I admit using higher level languages has made major damage to my brain ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather intuitive, but in Phobos the set of packages and their contents feels more or less arbitrary. Is there anything that can be done?

I do think some more big picture overview like documentation pages would be a good idea. If I had more time, I'd write some of them myself.

-- 
Adam D. Ruppe
http://arsdnet.net
November 29, 2009
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
> Walter and I discussed quite a few times the possibility of defining std.all that publically imports all of std. My experiments show that a short script importing std.all will compile slower, but not too slow, compared to a script that only import a few modules.

Vote++.  This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago.  A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple).  std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.
November 29, 2009
Sun, 29 Nov 2009 14:36:24 -0500, Jason House wrote:

> retard Wrote:
> 
>> Hi
>> 
>> after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.
>> 
>> For instance, it took two of us 15 minutes to build a program that reads a line from user, converts the string to a natural number, adds one, and finally prints it to the screen. Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.
> 
> That's an interesting example considering how Tango IO is way more complex. Comparatively speaking, 15 minutes is great!
> 
> That being said, there probably are ways to make D2 Phobos easier to use.
> 
> 
> 
>> When writing this, I already forgot what package contained the to! template.
> 
> std.conv (for conversions)
> 
> 
>> My intuition says it should be in
>>  * std.stdint [int related operations] * std.format [number formats?]
>>  * std.typecons [we're constructing a int from a string] * std.string
>>  [the input was a string, maybe toInt is a string operation] *
>>  std.numeric [it's a numeric operation, isn't it]
>> 
>> I admit using higher level languages has made major damage to my brain ("500.1".toInt anyone?), but still using Tango, Java, or C# seems rather intuitive, but in Phobos the set of packages and their contents feels more or less arbitrary. Is there anything that can be done?
> 
> Any massively used language is easier to use because a google search turns up similar code. I've found both D2 Phobos and Tango to be easy to use once you start. Tango was easier to find where most things were, but was amazingly tough to assemble generic pieces for IO. I remember reading line buffered text from standard in was way simpler with D2 Phobos.

Agreed. Also, once you start memorizing stuff, it doesn't matter that much anymore what the functions are called and where they can be found. I found the tutorials on Tango's site very helpful when learning it. I also agree that doing common tasks is more straightforward with Phobos and the resulting code is also a bit shorter, but using Tango was a bit more intuitive.
November 29, 2009
Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:

> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
> article
>> Walter and I discussed quite a few times the possibility of defining std.all that publically imports all of std. My experiments show that a short script importing std.all will compile slower, but not too slow, compared to a script that only import a few modules.
> 
> Vote++.  This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago.  A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple).  std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.

When writing small scripts, I use bpython:

http://www.bpython-interpreter.org/screenshots/

Nicely integrated apidocs.
November 29, 2009
Sun, 29 Nov 2009 15:30:14 -0500, Adam D. Ruppe wrote:

> On Sun, Nov 29, 2009 at 07:12:50PM +0000, retard wrote:
>> after using D1 and Tango for couple of years we decided to experiment with D2 and Phobos in a small scale project. For some reason the mostly flat package hierarchy seemed rather confusing.
> 
> Are you familiar with C's standard library? Phobos is loosely based on it, so if you can think of where you'd find it in C, it won't be far off in phobos.

Nope, I come from Java/C# land.

> 
>> Entities like 'stdin' seem to have no documentation at all. What should I import to get it, what interfaces does it implement etc.
> 
> http://digitalmars.com/d/2.0/phobos/std_stdio.html#File

> stdin is just an instance of that struct - directly analogous to how stdin in C is a FILE*. (D actually used C's FILE* directly for the longest time.)

I got it now. Note that stdin and stdout aren't defined anywhere. They're mentioned only briefly in the examples of the informal documentation.
November 29, 2009
== Quote from retard (re@tard.com.invalid)'s article
> Sun, 29 Nov 2009 20:26:07 +0000, dsimcha wrote:
> > == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s
> > article
> >> Walter and I discussed quite a few times the possibility of defining std.all that publically imports all of std. My experiments show that a short script importing std.all will compile slower, but not too slow, compared to a script that only import a few modules.
> >
> > Vote++.  This would be a nice little convenience when writing small scripts in D, which I actually do quite often because I already know where basic APIs like file I/O are in Phobos and I don't want to learn another API just for small scripts. This goes along with the scaling down thing I was talking about a few days ago.  A well-designed language and library should be good for both big projects (making complicated things possible) and small projects (making things simple).  std.all would be a trivial addition that wouldn't clash with anything else and would really help Phobos scale down better.
> When writing small scripts, I use bpython:
> http://www.bpython-interpreter.org/screenshots/
> Nicely integrated apidocs.

Yeah, I like Python, especially for things where I need tons of libraries that
have simple APIs and are just there, or where I really need a dynamic language and
even D templates aren't a good substitute.  I do most of my coding in D, with
Python as my second language for when D is just the wrong tool for the job.  However,

1.  I'm more used to D and it's almost as easy to use as Python.  Therefore I tend to use D more for the "grab the quickest thing available and get it working" kind of programming.

2.  I sometimes need to write tiny but fast programs, such as simple monte carlo simulations that I want to be able to tweak and run with as little thumb twiddling in between as possible, or utility programs that do some specific operation to a large amount of data.  Since D's build times are negligible for these programs and D code runs much faster than Python, D is the better tool here.

3.  I've built up a whole bunch of custom libraries in D that I like (the better/more universally useful ones I've released under various projects, the more quick and dirty or niche ones I haven't) and I want access to them even in very small scripts.
November 29, 2009
dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail@erdani.org)'s article
>> Walter and I discussed quite a few times the possibility of defining
>> std.all that publically imports all of std. My experiments show that a
>> short script importing std.all will compile slower, but not too slow,
>> compared to a script that only import a few modules.
> 
> Vote++.  This would be a nice little convenience when writing small scripts in D,
> which I actually do quite often because I already know where basic APIs like file
> I/O are in Phobos and I don't want to learn another API just for small scripts.
> This goes along with the scaling down thing I was talking about a few days ago.  A
> well-designed language and library should be good for both big projects (making
> complicated things possible) and small projects (making things simple).  std.all
> would be a trivial addition that wouldn't clash with anything else and would
> really help Phobos scale down better.

Sounds great. I'm even more encouraged by some brief measurement results. I timed dmd against this program:

void main(){}

Then against this program:

import std.stdio;
void main(){}

Then against this program:

import std.stdio;
void main(){}

For convenience of other testers I'm pasting std.all after this message.

The test machine is a 2.5 years old bottom-of-the-line Ubuntu laptop that seems to be in possession of the secret of immortality. Quiescent average run times:

* 0.23 seconds for the first program

* 0.64 seconds for the second program

* 0.98 seconds for the third program

I assume any program or script would have to include at least one module, and the marginal cost of including all other modules is low enough to be encouraging.

Andrei


module std.all;

public import std.algorithm;
public import std.array;
//public import std.atomics;
public import std.base64;
public import std.bigint;
public import std.bitmanip;
public import std.boxer;
public import std.compiler;
public import std.complex;
public import std.contracts;
public import std.conv;
public import std.cpuid;
public import std.cstream;
public import std.ctype;
public import std.date;
public import std.datebase;
public import std.dateparse;
public import std.demangle;
public import std.encoding;
public import std.file;
public import std.format;
public import std.functional;
public import std.getopt;
public import std.intrinsic;
public import std.iterator;
public import std.json;
//public import std.loader;
public import std.math;
public import std.md5;
public import std.metastrings;
public import std.mmfile;
public import std.numeric;
public import std.outbuffer;
public import std.path;
public import std.perf;
public import std.process;
public import std.random;
public import std.range;
public import std.regex;
public import std.regexp;
public import std.signals;
public import std.socket;
public import std.socketstream;
public import std.stdint;
public import std.stdio;
public import std.stdiobase;
public import std.stream;
public import std.string;
public import std.syserror;
public import std.system;
public import std.traits;
public import std.typecons;
public import std.typetuple;
public import std.uni;
public import std.uri;
public import std.utf;
public import std.variant;
public import std.xml;
public import std.zip;
public import std.zlib;
« First   ‹ Prev
1 2 3 4 5