Re: "Try it now"

[Jacob Carlborg]

On 2011-04-13 22:38, Andrei Alexandrescu wrote:

I'm quite excited about the new look of std (right now realized only by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
Here's a suggestion on how we could improve it more.

Adam wrote an in-browser evaluator for D programs. These, when presented
on the homepage with "hello, world" in them are of limited usefulness.
However, a personalized "try it now" button present for _each_ artifact
in an std module would be of great usefulness.

When I try some html or javascript I find it very useful to go to one of
those sites that allow me to try some code right then and there. The key
aspect is that the code edit field is already filled with code that is
close to what I'm looking for, which I can then edit and try until it
does what I want.

Similarly, it would be great if next to e.g.
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
there would be a "Try it now" button. Clicking on that button would open
an overlay with an edit window. The edit window initially contains the
example text:

unittest
{
int[] a = [ 1, 2, 4, 5, 7, 9 ];
int[] b = [ 0, 1, 2, 4, 7, 8 ];
int[] c = [ 10 ];
assert(setUnion(a, b).length == a.length + b.length);
assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
10][]));
}

Then the user can change, compile, and run that program, to ultimately
close the overlay and return to the documentation.

What do you think? This would require some work in the compiler (make
unittests documentable, make their text available to ddoc macros) and
some work in the front end. I hope this catches the fancy of e.g.
Walter/Don and Adam.


Andrei


This is looking better and better each time. One thing I still don't 
like is the cheat sheet, I think it looks cluttered. I think it's just 
too much text in most of the rows. The text in the Set operations looks 
good.


I would also prefer more vertical space in some of the examples. I think 
the first example for the "reduce" function looks good but I find the 
example for the "filter" function harder to read because there's no 
empty newlines.


--
/Jacob Carlborg

Re: "Try it now"

[Sequ]

> bearophile wrote:
> > This is a problem. Unittest code is not meant to produce an output,
> > while online snippets to try are meant to nearly always produce a
> > meaningful output.
> ...

> assert(sort([4, 2]) == [2, 4]);
>
> does look pretty neat. I guess the alternative is:
>
> writeln(sort[4, 2]); // prints "[2, 4]"
> ...

> But, regardless, there's nothing much my compile helper and
> javascript can do here. The examples in the documentation would
> have to be changed.

Is it maybe possible for the Javascript to take all statements of the form:
assert(a == b);
and rewrite them (in the Source Code window that pops up) as:
writeln(a);
?
I'm sure something could be written that works for most of the code found
in the documentation (even if it doesn't work for all possible D code).

Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))

[spir]

On 04/13/2011 11:44 PM, Andrei Alexandrescu wrote:

On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:

Well, standard (printed) typographic practices put spaces outside
the parenthesis and none inside. And as opposed to a lot of
typographic rules, that one is a constant across languages and variants.


Math typography rules also preclude inserting a space between a function's name
and the opening brace. That's why I consistently go with no space after the
opening paren or before the closing paren. Also, that's why there's no need to
make if (condition) and func(args) consistent with regard to space before
opening paren. In the first case the paren is pure punctuation; in the latter
it is an organic part of the function invocation syntax. So one should never
leave a space between function name and opening paren, and decide independently
regarding the existence of a space between if/while etc. and the opening paren.


Agreed.
In the same vein, function definition is not a function call; thus I use to 
write:

int square (int n) {
return n * n;
}
sq = square(3);

Actually, I have never been pleased that func defs (1) look like func calls (2) 
have an exceptional syntax compared to other definitions. I'd like instead eg:


square = function (int n) int {
return n * n;
}

Denis
--
_
vita es estrany
spir.wikidot.com

unittest{...} as "free" code bolck

[spir]

On 04/13/2011 10:38 PM, Andrei Alexandrescu wrote:

Similarly, it would be great if next to e.g.
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
there would be a "Try it now" button. Clicking on that button would open an
overlay with an edit window. The edit window initially contains the example 
text:

unittest
{
   int[] a = [ 1, 2, 4, 5, 7, 9 ];
   int[] b = [ 0, 1, 2, 4, 7, 8 ];
   int[] c = [ 10 ];
   assert(setUnion(a, b).length == a.length + b.length);
   assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
   assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9, 10][]));
}

Then the user can change, compile, and run that program, to ultimately close
the overlay and return to the documentation.


I recently started to realise a side-effect of the unittest feature is to 
provide D with "free code blocks", where one can just put any piece of code; 
code that could go on a module's top-level in a dynamic language.
Typically, this allows clean trials. Eg, does '/' perform euclidean division or 
true division, on integers / reals?


import std.stdio : writeln;
unittest {
writeln("ints");
writeln(2/2);
writeln(3/2);
}
unittest {
writeln("reals");
writeln(2.0/2);
writeln(3.0/2);
}
void main () {}

Sure, one can use main() for this. But unittest blocks are cleaner and allow 
structuration. In the same vein, unittests can be cleanly used to *demonstrate* 
language behaviour; for instance in tutorials, when showing issues like on 
D-leran, or for... bug reports.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/13/2011 10:54 PM, Adam D. Ruppe wrote:

Andrei wrote:

Adam wrote an in-browser evaluator for D programs. These, when
presented on the homepage with "hello, world" in them are of
limited usefulness.
However, a personalized "try it now" button present for _each_
artifact in an std module would be of great usefulness.


Indeed. I actually wrote a little javascript thing for that
new home page that's reusable across other ddoc or similar
sites. Check it out:

http://arsdnet.net/d-web-site/std_algorithm2.html

Every time it sees a d_code block, the script adds a button.
Hit the button, and you can edit the code and send it off
to my completelyexpendable vm to compile and run it.

(It's also on my not-quite-done newsreader so example code in
newsgroup posts are detected and made editable. That's less perfect
since it's trying to pick code out of unstructured text, but it
works reasonably well.)


Of course, most examples fail to actually compile... but maybe
a few replacement rules for the text - automatically insert main()
if it's not there, import std.all or similar at the top,
replace "..." with some generic data.

I think we could make the examples work with just a few lines of
code.


Unittests are a different story though, since their code isn't
in the HTML today. If dmd did make it available though, this same
script should work on it.


What would be helpful, I guess, to have most examples work as is, is 
systematically:

* put the code in a unitest block
* add "void main () {}"
* "import std.commonimports;"
where commonimports is a to-be-defined module publicly importing common tools 
from std.* (there was a similar discussion about scripting in D):


public import std.stdio: write, writef, writeln, writefln;
public import std.string   : format, join;
public import std.conv : to;
...

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

On 2011-04-13 22:38, Andrei Alexandrescu wrote:

I'm quite excited about the new look of std (right now realized only by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
Here's a suggestion on how we could improve it more.

Adam wrote an in-browser evaluator for D programs. These, when presented
on the homepage with "hello, world" in them are of limited usefulness.
However, a personalized "try it now" button present for _each_ artifact
in an std module would be of great usefulness.

When I try some html or javascript I find it very useful to go to one of
those sites that allow me to try some code right then and there. The key
aspect is that the code edit field is already filled with code that is
close to what I'm looking for, which I can then edit and try until it
does what I want.

Similarly, it would be great if next to e.g.
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion
there would be a "Try it now" button. Clicking on that button would open
an overlay with an edit window. The edit window initially contains the
example text:

unittest
{
int[] a = [ 1, 2, 4, 5, 7, 9 ];
int[] b = [ 0, 1, 2, 4, 7, 8 ];
int[] c = [ 10 ];
assert(setUnion(a, b).length == a.length + b.length);
assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
10][]));
}

Then the user can change, compile, and run that program, to ultimately
close the overlay and return to the documentation.

What do you think? This would require some work in the compiler (make
unittests documentable, make their text available to ddoc macros) and
some work in the front end. I hope this catches the fancy of e.g.
Walter/Don and Adam.


Andrei


This is looking better and better each time. One thing I still don't like is
the cheat sheet, I think it looks cluttered. I think it's just too much text in
most of the rows.


Agreed. May I suggest an easy (and imo sensible) doc guideline, which would 
also allow automatising cheat sheet generation?


1. The top line of each doc block defines the *purpose* of the given piece of 
code
   (meaning for a func either what value it computes, or what action it 
performs).
2. This line is taken as is by a cheat sheet generator.

Examples:

PI
  /** The value of pi.
  ... */

struct Circle
  /** Representation of a circle, as defined by radius & position of center.
  ... */

size_t indexOf (E elem) // method of some collection type
  /** Index of first occurrence of elem in collection --else throws IndexError.
  ... */

void_t erase (E elem)   // ditto
  /** Erase all occurrences of elem in collection.
  ... */

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 01:11 AM, bearophile wrote:

* Since most of them don't actually output anything, the program
> now detects output.length == 0 and says "Program run
> successfully." upon completion to give some feedback.

This is a problem. Unittest code is not meant to produce an output, while 
online snippets to try are meant to nearly always produce a meaningful output.


All my unittest blocks produce meaningful output; there exist firstly for that. 
Am I an heretic?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 02:51 AM, Adam D. Ruppe wrote:

Andrej Mitrovic wrote:

I've always wondered.. how do you detect malicious D code?


It doesn't. What it does is use the ulimit feature in linux to
limit the resources available to each process so they can't do
anything.

Try it:

int[] a;
a.length = 5_000_000; // "Memory allocation failed"


for(;;) {} // forcibly terminated by the kernel after ~8 seconds

auto f = File("cool_a_file", "wt");
for(int a = 0; a<  10_000; a++)
   f.writefln("%d", a);

// reports success, but the file is actually only 8 kb:

# ls -l cool_a_file
-rw-r--r-- 1 apache apache 8192 2011-04-13 19:22 cool_a_file

# tail -n 2 cool_a_file
1859
18 // you can see it got forcibly cut off

There's file permissions in place that you shouldn't be able to
access anything on there, except reading the system files. It's
a stock Linux install - nothing to see there. Writing is limited
to the scratchspace directory, which isn't public to the web or
anything.


What if you tried to fill the disk by creating files in a loop?
You actually can do that, until you're killed for either running
for too long or hitting the scratchspace's disk quota. I don't
know how to prevent that except for disabling files altogether,
and I think that would diminish the usefulness a little. File
examples are fun too.

(note if you do fill the scratchspace, it's not a big deal. It's
garbage collected in a way - the compile helper catches disk
full exceptions and cleans it out when needed. Still, don't do that.)

Access to the network is firewalled too. You can play on localhost
to a degree, but anything to and from the outside world is filtered.
Shouldn't be possible to run a spambot on it, since nothing on
that machine is allowed to call out, not even root.


Keep in mind that DMD lives under similar constraints. If it
goes wild, it will be killed by the kernel before too long too,
and can't make files bigger than about a megabyte. It's limited
to 256 MB of RAM.


This describes the limits in the operating system. There's
additional limits at the VM level, so even if you got root, you
couldn't do much with it. This is why it's also on a separate
domain name than anything else too - if you put a web exploit
on it, there's nothing much to do with that either. Like it's
name says, it's all completely expendable info.

Finally, I snapshotted the VM in a known good state. If you do
root the box, I can always revert to that too (considering writing
a program to automatically revert each day actually, but haven't
gotten around to it yet).

Of course, worst case scenario is I just pull the plug on it. I
hope it never comes to that, but some people are assholes, so
if I have to, it's an option.


Anyway, as you can see, I tried to cover all my bases with enough
fallback plans that I'm not concerned about malicious code at all.


We'd need a sandbox.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 02:56 AM, bearophile wrote:

Andrei:


>  I disagree. I find examples that use assert() much clearer than examples
>  that print something to the console and then explain in a comment what
>  you ought to be seeing.

I don't understand why you say that. Isn't learning and understanding based on 
feedback?


Precisely ;-)
That's why sane unittest blocks may/should output! One needs proper data to 
study / diagnose / debig what code *actually* does.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 02:56 AM, bearophile wrote:

Andrei:


I disagree. I find examples that use assert() much clearer than examples
that print something to the console and then explain in a comment what
you ought to be seeing.


I don't understand why you say that. Isn't learning and understanding based on feedback? 
If all the examples do is to show the same "assert passed" message, then what's 
the point in running the examples? Just reading a static page gives the same insight. You 
are able to modify them, of course, and see the modified asserts fail, and you may add a 
writeln statement yourself, but... having to modify each example to see some feedback is 
not a good default. I'd like to know if other people agree with you on this.


I more or less agree with both of you. My problem with using asserts in code 
samples is:

* It's not a feature all languages have, thus readers may not know it (well).
* Asserts in sample is clever "highjacking" of a language feature for a clever 
side-effect.


The point of assert in true code is to catch a potential bug. The point of 
assert in sample code is to bring information to the reader, like if saying 
"this predicate holds here":

   assert(3/2 == 1);
Maybe an alias of assert for such use would help? (but I cannot find one) Or a 
simple comment would do the job better:

   // 3/2 == 1

I long for a different assert that would take one expression and a result, and 
writse out when 'assertMode' is 'verbose':

   assert(3/2, &);
   // outputs "3/2 : 1"
Then, we get both silent and verbose asserts in one go; the former for 
regression testing, the latter mode for diagnose or examples.


I currently do it that way:
auto n = 3/2;
writefln("3/2: %s, n); // commented out for regression test
assert(n == 1);

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

bearophile wrote:

>  This is a problem. Unittest code is not meant to produce an output,
>  while online snippets to try are meant to nearly always produce a
>  meaningful output.

I don't know - I like the approach Andrei took in the docs, writing
a series of true assertations.

assert(sort([4, 2]) == [2, 4]);

does look pretty neat. I guess the alternative is:

writeln(sort[4, 2]); // prints "[2, 4]"


What about

   // sort([4, 2]) == [2, 4])

? Looks to me both simpler & clearer.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 06:32 AM, Walter Bright wrote:

On 4/13/2011 6:04 PM, Adam D. Ruppe wrote:

I don't know - I like the approach Andrei took in the docs, writing
a series of true assertations.

assert(sort([4, 2]) == [2, 4]);

does look pretty neat. I guess the alternative is:

writeln(sort[4, 2]); // prints "[2, 4]"

but it's not as compact with some examples and it doesn't quite
show the same thing - writeln's implementation could change things
there and those details are really beside the point of the example.

On the other hand, having output there might be more interesting
to look at than "yay the asserts all passed!".

I could go either way.


One advantage of the assert() approach is you won't have to over and over again
add in the import std.stdio;

Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes. This holds for simple comments as well:

assert(3/2 == 1);
vs
// 3/2 == 1

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[David Nadlinger]

On 4/14/11 2:26 PM, spir wrote:

Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes.


In which way exactly do I need an import to write »extern(C) int 
system(in char *); system(…);«?


David

Re: Ceylon language

[spir]

On 04/13/2011 02:34 PM, bearophile wrote:


-

Ceylon does not support method overloading (or any other kind of overloading).


How to survive? Named args and default values somewhat mitigate this lack, but 
still...

I read (somewhere) this only for /operator/ overloading.


-

If a value of type T can be null, it must be declared as type Optional, 
which may be abbreviated to T?

String? name = process.args.first;
if (exists name) {
 writeLine("Hello " name "!");
}
else {
 writeLine("Hello World!");
}

Use of an optional value must be guarded by the if (exists ... ) construct. 
Therefore, NullPointerExceptions are impossible.

This is exactly what I suggested for D in a enhancement request.
It seems this kind of stuff is becoming a standard in new languages.


+++

But I guess optionality could, and should, extend to non-ref types; thus, null 
is just a particular case of non-existence. And this would apply especially on 
function parameters:

   void f (int i?) {...}

Also, they should reuse '?' to mean 'exists', possibly '!?' meaning the 
opposite:
   void f (int i?) {
   if (? i) doWithI(i);
   if (!? i) doWithoutI();
   ...
}


-

Attributes and local variables are immutable by default. Assignable values must 
be annotated variable:

variable Natural count := 0;


Immutability should be the default for locals (especialy params) in all 
languages.

'Natural' is great ;-)


-

A getter looks like a method without a parameter list:

shared Natural currentValue {
 return count;
 }
}


good


Attributes are polymorphic. A subclass may override a superclass attribute. It 
may even override a simple attribute with a getter or vice versa!

This means there is no need for explicit getter/setters until you are ready for 
them. This is nice.


very good

I often miss this in D. The fact that subtyping in D applies only to methods 
forces to add fake data members in supertypes (which are thus present in all 
subtypes...). I find this design crazy !!!
Same note for mixins: why do they hold only methods? A "role" to be mixed-in 
often requires both data & methods.



-

There is no new keyword:

Counter c = Counter();


great! get rid of new in D as well

coll = (new Coll(cap)).fill(data);
==>
coll = Coll(cap).fill(data);


-

Assignment to a variable value or attribute setter is done using the := 
operator. The = specifier is used only for specifying immutable values:

shared assign currentValue {
 count := currentValue;
}


If I understand you correctly, this is wrong. The operators should instead make 
distinct *creation* versus *change*:

   variable Natural count = 0;  // create
   count := 3;  // change
   local Natural i = 1; // cannot be changed


-

We may define a class method "by reference":

void hello(String name) = hello;


???


-

A method may declare multiple lists of parameters. The method body is executed 
after arguments have been supplied to all parameter lists:

Float add(Float x)(Float y) {
 return x+y;
}

This is a kind of user defined and safe partial application, it's a cute idea.

Providing arguments to just one parameter list produces a method reference:

Float addOne(Float y) = add(1.0);
Float three = addOne(2.0);

(The point of all this is that we are able to provide all the functionality of 
first-class and higher-order functions without needing to resort to unnatural 
syntactic constructs inspired by the lambda calculus notation.)


I don't get the diff between currying & partial app. And find this feature much 
complication for close to uselessness.



-

There is a Named argument syntax.


A true programmer uses named args in half of all method calls; meaning, 
everywhere args' meanings are not absolutely obvious.


 They use it for a syntax trick: A named argument invocation is enclosed in 

braces, and non-vararg arguments are listed using the name=value; syntax.


This seems one of the most peculiar and refined parts of the syntax of this 
language. See slides 34-37 in the first PDF.


examples?


-

A class or interface satisfies zero or more interfaces

shared class Character(Natural utf16)
 extends Object()
 satisfies Ordinal&  Comparable  {
 ...
}

The syntax X&Y represents the intersection of two types. The syntax X|Y 
represents the union of two types.


Too bad, they got it wrong, like D. Should instead rip Go interfaces, which are 
structural & implicite, while still fully compile-time type-safe:


struct File inStream {
...
void write (string s) {...};
}
...
interface Writer {
void write (string s);
}
File is *also* a Writer, thus one can call the following on a specimen of File:
void formatWrite (Writer w, string s, string format) {...}

More generally, any type can satisfy any number of interfaces, wherever and 
whenever they 

Re: Ceylon language

[spir]

On 04/13/2011 07:06 PM, bearophile wrote:

Kagamin:


>  How will it work on this code?
>
>  String? name = process.args.first;
>  myLibCustomEnforce(exists name);
>  writeLine("Hello " name "!");

If you want to implement the feature well, then the compiler has to manage a bit of type state too. 
The state of the type of the (here immutable) variable "name" before myLibCustomEnforce() 
is different from the state of the type of "name" after that call.


Yo; and while you're at "typestating", extend the feature to any type (not only 
pointers).


Denis
--
_
vita es estrany
spir.wikidot.com

question to Walter - about the GUI library

[David Wang]

Dear Walter Bright,

I would like to know that what GUI library you would like to use for D Language 
?

Have you ever considered the GTK+ 3.0? or other library? or you will produce a
new D library of GUI?


wainting for your kindly feedback.


Best regards.
David.

Re: "Try it now"

[spir]

On 04/14/2011 02:40 PM, David Nadlinger wrote:

On 4/14/11 2:26 PM, spir wrote:

Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes.


In which way exactly do I need an import to write »extern(C) int system(in char
*); system(…);«?


Did I write "it provides safe sandboxes"?

Denis
--
_
vita es estrany
spir.wikidot.com

Re: question to Walter - about the GUI library

[Denis Koroskin]

On Thu, 14 Apr 2011 17:39:32 +0400, David Wang  wrote:


Dear Walter Bright,

I would like to know that what GUI library you would like to use for D  
Language ?


Have you ever considered the GTK+ 3.0? or other library? or you will  
produce a

new D library of GUI?


wainting for your kindly feedback.


Best regards.
David.


Walter is working on a reference compiler, I don't think he is using (let  
alone developing) any GUI library. That should be a community effort.


That said, there are bindings for Gtk+ 2.xx and Qt (called GtkD and QtD  
respectively) as well as a DWT (which is a port of SWT library).

Re: "Try it now"

[David Nadlinger]

On 4/14/11 3:44 PM, spir wrote:

On 04/14/2011 02:40 PM, David Nadlinger wrote:

On 4/14/11 2:26 PM, spir wrote:

Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes.


In which way exactly do I need an import to write »extern(C) int
system(in char
*); system(…);«?


Did I write "it provides safe sandboxes"?

Denis


No, but you wrote that it »helps in having safe sandboxes«, and I'm 
curious how you think it would.


David

Re: "Try it now"

[Steven Schveighoffer]

On Wed, 13 Apr 2011 21:04:25 -0400, Adam D. Ruppe  
 wrote:



On the other hand, having output there might be more interesting
to look at than "yay the asserts all passed!".


I think this is a good point.  Someone playing with a language might type  
in the example, and do:


/home/steves> dmd example.d
/home/steves> ./example
/home/steves> (ok... I guess that worked, but I'm not sure what happened)

In other words, there is a benefit to the interaction with the learner.   
In other words, you get to "see it working", rather than only see when it  
fails.  You also get a confirmation that the compiler is actually building  
something.  For the above code, all one really knows is that the compiler  
made an executable.  There's no confirmation that the code being run is  
actually what you typed in.


Sometimes, I worry that my unit tests or asserts aren't running.  Every  
once in a while, I have to change one to fail to make sure that code is  
compiling (this is especially true when I'm doing version statements or  
templates).  It would be nice if there was a -assertprint mode which  
showed asserts actually running (only for the module compiled with that  
switch, of course).


-Steve

Re: "Try it now"

[David Nadlinger]

On 4/14/11 4:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code is
compiling (this is especially true when I'm doing version statements or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with that
switch, of course).


You are not the only one, I can't resist to do this quite often when I 
work with template-heavy code, or compiler bugs come into play.


At least for the unit tests, this could probably be integrated with a 
test harness (and named tests), which would have a verbose mode which 
logs each completed unittest block.


David

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 6:52 AM, spir wrote:

On 04/14/2011 01:11 AM, bearophile wrote:

* Since most of them don't actually output anything, the program
> now detects output.length == 0 and says "Program run
> successfully." upon completion to give some feedback.

This is a problem. Unittest code is not meant to produce an output,
while online snippets to try are meant to nearly always produce a
meaningful output.


All my unittest blocks produce meaningful output; there exist firstly
for that. Am I an heretic?


No, you're just doing it wrong. Heretic might be sometimes good.

http://www.linfo.org/rule_of_silence.html

Andrei

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 6:49 AM, spir wrote:

On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

On 2011-04-13 22:38, Andrei Alexandrescu wrote:

I'm quite excited about the new look of std (right now realized only by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
Here's a suggestion on how we could improve it more.

Adam wrote an in-browser evaluator for D programs. These, when presented
on the homepage with "hello, world" in them are of limited usefulness.
However, a personalized "try it now" button present for _each_ artifact
in an std module would be of great usefulness.

When I try some html or javascript I find it very useful to go to one of
those sites that allow me to try some code right then and there. The key
aspect is that the code edit field is already filled with code that is
close to what I'm looking for, which I can then edit and try until it
does what I want.

Similarly, it would be great if next to e.g.
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion

there would be a "Try it now" button. Clicking on that button would open
an overlay with an edit window. The edit window initially contains the
example text:

unittest
{
int[] a = [ 1, 2, 4, 5, 7, 9 ];
int[] b = [ 0, 1, 2, 4, 7, 8 ];
int[] c = [ 10 ];
assert(setUnion(a, b).length == a.length + b.length);
assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
10][]));
}

Then the user can change, compile, and run that program, to ultimately
close the overlay and return to the documentation.

What do you think? This would require some work in the compiler (make
unittests documentable, make their text available to ddoc macros) and
some work in the front end. I hope this catches the fancy of e.g.
Walter/Don and Adam.


Andrei


This is looking better and better each time. One thing I still don't
like is
the cheat sheet, I think it looks cluttered. I think it's just too
much text in
most of the rows.


Agreed. May I suggest an easy (and imo sensible) doc guideline, which
would also allow automatising cheat sheet generation?

1. The top line of each doc block defines the *purpose* of the given
piece of code
(meaning for a func either what value it computes, or what action it
performs).
2. This line is taken as is by a cheat sheet generator.

Examples:

PI
/** The value of pi.
... */

struct Circle
/** Representation of a circle, as defined by radius & position of center.
... */

size_t indexOf (E elem) // method of some collection type
/** Index of first occurrence of elem in collection --else throws
IndexError.
... */

void_t erase (E elem) // ditto
/** Erase all occurrences of elem in collection.
... */

Denis


I prefer the cheat sheet contain code snippets. They are very terse and 
eloquent.


Andrei

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 7:25 AM, spir wrote:

On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

bearophile wrote:

> This is a problem. Unittest code is not meant to produce an output,
> while online snippets to try are meant to nearly always produce a
> meaningful output.

I don't know - I like the approach Andrei took in the docs, writing
a series of true assertations.

assert(sort([4, 2]) == [2, 4]);

does look pretty neat. I guess the alternative is:

writeln(sort[4, 2]); // prints "[2, 4]"


What about

// sort([4, 2]) == [2, 4])

? Looks to me both simpler & clearer.

Denis


I don't like that one bit. What is it trying to achieve or improve?

Andrei

Re: question to Walter - about the GUI library

[Jesse Phillips]

David Wang Wrote:

> Dear Walter Bright,
> 
> I would like to know that what GUI library you would like to use for D 
> Language ?
> 
> Have you ever considered the GTK+ 3.0? or other library? or you will produce a
> new D library of GUI?
> 
> 
> wainting for your kindly feedback.
> 
> 
> Best regards.
> David.

Walter has dropped the idea of endorsing a GUI/any library. There was once a 
statement that DWT was the official library for D, development promptly stopped 
afterwards. Not trying to claim there was causation here.

single-line string?

[spir]

Hello,

This may be a feature request for a single-line string syntactic form --if ever 
others are annoyed as well, see below. One possible form may be:

str = s"abc";
I have myself long found it stupid to separate single- and multi-line string, 
since there is no formal reason for that. But there are practical consequences 
on code edition I did not imagine until I started coding in a language not 
making this distinction... namely D.


Problem:

In my editor, Geany, each time I press '"', the whole code (actually the rest 
of the code from the current cursor position) is re-scanned, re-interpreted, 
re-displayed. This is fully logical and in itself is not a major issue in Geany 
because it is very light & fast. I wonder how this goes with heavier editors or 
real IDEs.
But the real point is that this causes a big usability problem, namely that all 
(the rest of) code suddenly gets unfolded! If I want to go on editing 
comfortably, I then need to refold all and manually re-unfold the part(s) I'm 
currently working on. Very annoying. Imagine a debugging session requiring 
debug prints here & there...


This is a bug of the editor, indeed, but since Geany is based on Scintilla's 
editon component, I guess this bug may be widely shared. A solution may be that 
opening of a (possibly multi-line) string should limit the reinterpretation 
scope to the current logical line, or simply suspend it, until either the 
string is closed, or said line is quit (via arrows or mouse). Also, the bug 
happens even if I use Geany's feature of auto-closing delimiters, meaning when 
I press '"' '""' is written out (a feature I hate anyway for code edition). I 
would like to know how & how well other editors deal with all of that 
(especially but not only emacs and vim).


Compare with multi-line comments: the difference is double: (1) there is syntax 
for single-line comment (2) the closing delimiter is different ('/*' vs '*/'). 
This means that (1) use of multi-line syntax is limited to actual need for 
multi-line (2) one can avoid the bug by writing the closing delimiter first, 
hehe! (what I constantly do when writing docs docs)


Any comment ot hint welcome.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 04:21 PM, Andrei Alexandrescu wrote:

On 4/14/11 6:49 AM, spir wrote:

On 04/14/2011 11:30 AM, Jacob Carlborg wrote:

On 2011-04-13 22:38, Andrei Alexandrescu wrote:

I'm quite excited about the new look of std (right now realized only by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).
Here's a suggestion on how we could improve it more.

Adam wrote an in-browser evaluator for D programs. These, when presented
on the homepage with "hello, world" in them are of limited usefulness.
However, a personalized "try it now" button present for _each_ artifact
in an std module would be of great usefulness.

When I try some html or javascript I find it very useful to go to one of
those sites that allow me to try some code right then and there. The key
aspect is that the code edit field is already filled with code that is
close to what I'm looking for, which I can then edit and try until it
does what I want.

Similarly, it would be great if next to e.g.
http://d-programming-language.org/phobos-prerelease/std_algorithm.html#setUnion


there would be a "Try it now" button. Clicking on that button would open
an overlay with an edit window. The edit window initially contains the
example text:

unittest
{
int[] a = [ 1, 2, 4, 5, 7, 9 ];
int[] b = [ 0, 1, 2, 4, 7, 8 ];
int[] c = [ 10 ];
assert(setUnion(a, b).length == a.length + b.length);
assert(equal(setUnion(a, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9][]));
assert(equal(setUnion(a, c, b), [0, 1, 1, 2, 2, 4, 4, 5, 7, 7, 8, 9,
10][]));
}

Then the user can change, compile, and run that program, to ultimately
close the overlay and return to the documentation.

What do you think? This would require some work in the compiler (make
unittests documentable, make their text available to ddoc macros) and
some work in the front end. I hope this catches the fancy of e.g.
Walter/Don and Adam.


Andrei


This is looking better and better each time. One thing I still don't
like is
the cheat sheet, I think it looks cluttered. I think it's just too
much text in
most of the rows.


Agreed. May I suggest an easy (and imo sensible) doc guideline, which
would also allow automatising cheat sheet generation?

1. The top line of each doc block defines the *purpose* of the given
piece of code
(meaning for a func either what value it computes, or what action it
performs).
2. This line is taken as is by a cheat sheet generator.

Examples:

PI
/** The value of pi.
... */

struct Circle
/** Representation of a circle, as defined by radius & position of center.
... */

size_t indexOf (E elem) // method of some collection type
/** Index of first occurrence of elem in collection --else throws
IndexError.
... */

void_t erase (E elem) // ditto
/** Erase all occurrences of elem in collection.
... */

Denis


I prefer the cheat sheet contain code snippets. They are very terse and 
eloquent.

Andrei


Right. Sounds sensible.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 03:50 PM, David Nadlinger wrote:

On 4/14/11 3:44 PM, spir wrote:

On 04/14/2011 02:40 PM, David Nadlinger wrote:

On 4/14/11 2:26 PM, spir wrote:

Not having any imports makes for a faster compile, too.


... and helps in having safe sandboxes.


In which way exactly do I need an import to write »extern(C) int
system(in char
*); system(…);«?


Did I write "it provides safe sandboxes"?

Denis


No, but you wrote that it »helps in having safe sandboxes«, and I'm curious how
you think it would.


I mean imports usually bring in many more tools for naughty code. And I guess 
in some languages, naughty actions can only be performed via such imported 
modules (system control, direct memory access,...), thus forbidding import is 
an easy way of creating a sandbox. At the very minimum, forbidding import or 
limiting it to a predefined set of modules is a necessary first step, I guess.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: single-line string?

[Steven Schveighoffer]

On Thu, 14 Apr 2011 10:49:58 -0400, spir  wrote:


Hello,

This may be a feature request for a single-line string syntactic form  
--if ever others are annoyed as well, see below. One possible form may  
be:

 str = s"abc";
I have myself long found it stupid to separate single- and multi-line  
string, since there is no formal reason for that. But there are  
practical consequences on code edition I did not imagine until I started  
coding in a language not making this distinction... namely D.


Problem:

In my editor, Geany, each time I press '"', the whole code (actually the  
rest of the code from the current cursor position) is re-scanned,  
re-interpreted, re-displayed. This is fully logical and in itself is not  
a major issue in Geany because it is very light & fast. I wonder how  
this goes with heavier editors or real IDEs.
But the real point is that this causes a big usability problem, namely  
that all (the rest of) code suddenly gets unfolded! If I want to go on  
editing comfortably, I then need to refold all and manually re-unfold  
the part(s) I'm currently working on. Very annoying. Imagine a debugging  
session requiring debug prints here & there...


This is a bug of the editor, indeed, but since Geany is based on  
Scintilla's editon component, I guess this bug may be widely shared. A  
solution may be that opening of a (possibly multi-line) string should  
limit the reinterpretation scope to the current logical line, or simply  
suspend it, until either the string is closed, or said line is quit (via  
arrows or mouse). Also, the bug happens even if I use Geany's feature of  
auto-closing delimiters, meaning when I press '"' '""' is written out (a  
feature I hate anyway for code edition). I would like to know how & how  
well other editors deal with all of that (especially but not only emacs  
and vim).


Not sure about folding in vim, since I generally do not use vim's folding  
features, but it does temporarily syntax highlight the rest of the file as  
if it were a string.  However, vim does not re-interpret/display the  
entire file, it generally only cares about the visible portion.


In NetBeans, you can set it up to insert two quotes when you type one  
(i.e. auto-closing delimiters).  However, I use that to edit PHP and HTML,  
so I'm not sure how that compares.


I'd say your best bet is to get the bug fixed in your editor.  Changing  
the language is wholly inappropriate to address an editor bug, especially  
when it's only one editor, and one person's preference that is being  
affected.


-Steve

Re: single-line string?

[Andrej Mitrovic]

Some editors automatically add the closing double quote, which pretty
much eliminates this problem. For example:

step1: string s = | <- caret
step2: string s = "| <- caret
step3: string s = "|" <- editor automatically adds the ending quote
step4: string s = "typesomething"
step5: string s = "typesomething"; <- you don't have to move the
cursor after the closing quote, just type in the extra " and it will
automatically overwrite the existing one. Then you add -> ;

Perhaps Geany doesn't automatically do step5, and doesn't let you
overwrite the extra closing quote. This might explain why you don't
like automatic addition of the closing quote.

This wouldn't be hard to implement using Scintilla. The problem is
most IDE's and editors which use Scintilla barely scratch the surface
of its potential. They just embed the editing component and add a few
dialog boxes to configure font sizes.

Re: "Try it now"

[Andrej Mitrovic]

If you remove asserts then we're forced to run the examples every time
we want to remind ourselves of what the code does. With assert it's
obvious what the code does.

And besides, why discourage newbies from learning about assert?
Looking at examples with write's could make them think it's a standard
way of debugging code. "Just print all the values, and then check them
one by one to see that they're valid". Let them learn about asserts
and unittests.

Another thing is that I believe most newcomers to D are C/C++
programmers. If we show them how easy it is to check code for
validity, they might start thinking that using asserts and unittests
isn't such a bad thing after all. If you ask an average C++ programmer
whether they use asserts and unittests they'll probably say "No,
because it's too difficult to set up and run them, and I'm too lazy".
Heck, every other day someone comes up with a brand new unittest C++
_library_, and people are completely uninterested.

IMO we shouldn't be hiding D's top features just because they might
look foreign at first.

optionally verbose assertions

[spir]

On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running.  Every once in
a while, I have to change one to fail to make sure that code is compiling (this
is especially true when I'm doing version statements or templates).  It would
be nice if there was a -assertprint mode which showed asserts actually running
(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally verbose 
assertions.

This could use 2 arguments instead of a predicate:
assert(expressions, value);
Example use:

unittest {
auto args = [0, 1, -1, 999, -999];
auto vals = [a, b, c, d, e]; // letters here represent expected values
foreach (i ; 0..args.length)
assert(f(args[i]), vals[i]);
}

During a test session, assert-mode is set to 'verbose'. This would print for 
instance, in case f(999) fails:

"
assert: f(0) --> a
assert: f(1) --> b
assert: f(-1) --> c

Assertion Error:
expression  : f(999)
expected: d
outcome : whatever

assert: f(-999) --> e
"
Then, we get all we need to comfortably debug, I guess. Also note /other/ 
unittests (eg one testing g called by f) may also bring in valuable feedback 
data on how the program actually runs.


As is discussed in this thread, this verbose mode is also very nice for code 
samples (introduction to D, manuals, tutorials, howtos, and even exchanges on 
mailing lists...).


For a plain regression test, after some change has been made to a piece of 
code, assert-mode is set to 'silent'. This would only print out failure cases:

"

Assertion Error:
expression  : f(999)
expected: d
outcome : whatever

"
Then, we just have to turn assert-mode back to verbose, and happily start 
debugging ;-)


Note: 2 friendly complementary features are (1) expected outcome may be an 
exception, (2) outcome may be expression via a string representation. This is 
the reason why output shows as '-->', not '=='.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[spir]

On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:

On 4/14/11 6:52 AM, spir wrote:

On 04/14/2011 01:11 AM, bearophile wrote:

* Since most of them don't actually output anything, the program
> now detects output.length == 0 and says "Program run
> successfully." upon completion to give some feedback.

This is a problem. Unittest code is not meant to produce an output,
while online snippets to try are meant to nearly always produce a
meaningful output.


All my unittest blocks produce meaningful output; there exist firstly
for that. Am I an heretic?


No, you're just doing it wrong. Heretic might be sometimes good.

http://www.linfo.org/rule_of_silence.html


Right, I know that and totally disagree. This rule is IMO the exact opposite of 
human-friendliness (numerous authors on usability and friends share this 
opinion, indeed).
Also, this is not what I'm talking about: I'm not here expecting just "all 
fine, brother", but various data helping me and understand how things actually 
worked; to be short, data useful to the coder during development or debug. See 
also reply to Steven's post.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[Daniel Gibson]

Am 14.04.2011 16:56, schrieb spir:
> On 04/14/2011 03:50 PM, David Nadlinger wrote:
>> On 4/14/11 3:44 PM, spir wrote:
>>> On 04/14/2011 02:40 PM, David Nadlinger wrote:
 On 4/14/11 2:26 PM, spir wrote:
>> Not having any imports makes for a faster compile, too.
>
> ... and helps in having safe sandboxes.

 In which way exactly do I need an import to write »extern(C) int
 system(in char
 *); system(…);«?
>>>
>>> Did I write "it provides safe sandboxes"?
>>>
>>> Denis
>>
>> No, but you wrote that it »helps in having safe sandboxes«, and I'm
>> curious how
>> you think it would.
> 
> I mean imports usually bring in many more tools for naughty code. And I
> guess in some languages, naughty actions can only be performed via such
> imported modules (system control, direct memory access,...), thus
> forbidding import is an easy way of creating a sandbox. At the very
> minimum, forbidding import or limiting it to a predefined set of modules
> is a necessary first step, I guess.
> 
> Denis

As long as any C function can be called just by defining it, this is
just snake oil. For other languages this may work, but it'd make more
sense to just use a modified standard-lib that asserts when forbidden
functions are used.

For D (and probably any other system programming language) it makes more
sense to restrict on OS level, for example with SELinux, and assume that
the user code is pure evil.

Cheers,
- Daniel

Re: "Try it now"

[spir]

On 04/14/2011 04:24 PM, Andrei Alexandrescu wrote:

On 4/14/11 7:25 AM, spir wrote:

On 04/14/2011 03:04 AM, Adam D. Ruppe wrote:

bearophile wrote:

> This is a problem. Unittest code is not meant to produce an output,
> while online snippets to try are meant to nearly always produce a
> meaningful output.

I don't know - I like the approach Andrei took in the docs, writing
a series of true assertations.

assert(sort([4, 2]) == [2, 4]);

does look pretty neat. I guess the alternative is:

writeln(sort[4, 2]); // prints "[2, 4]"


What about

// sort([4, 2]) == [2, 4])

? Looks to me both simpler & clearer.

Denis


I don't like that one bit. What is it trying to achieve or improve?


assert(sort([4, 2]) == [2, 4]);

What is it trying to achieve or improve?
plus: is this bebug code / error catching; or information to the reader?

Denis
--
_
vita es estrany
spir.wikidot.com

Re: optionally verbose assertions

[Steven Schveighoffer]

On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:


On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:
Sometimes, I worry that my unit tests or asserts aren't running.  Every  
once in
a while, I have to change one to fail to make sure that code is  
compiling (this
is especially true when I'm doing version statements or templates).  It  
would
be nice if there was a -assertprint mode which showed asserts actually  
running

(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally  
verbose assertions.

This could use 2 arguments instead of a predicate:
 assert(expressions, value);
Example use:


[snip]

I don't think we can change assert syntax now.  What I was looking was for  
something more like:


assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned on.   
This should be easy to do in the compiler by just translating


assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);

-Steve

Re: optionally verbose assertions

[Daniel Gibson]

Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
> On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:
> 
>> On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:
>>> Sometimes, I worry that my unit tests or asserts aren't running. 
>>> Every once in
>>> a while, I have to change one to fail to make sure that code is
>>> compiling (this
>>> is especially true when I'm doing version statements or templates). 
>>> It would
>>> be nice if there was a -assertprint mode which showed asserts
>>> actually running
>>> (only for the module compiled with that switch, of course).
>>
>> Man, I'm very pleased to read someone else advocating for optionally
>> verbose assertions.
>> This could use 2 arguments instead of a predicate:
>>  assert(expressions, value);
>> Example use:
> 
> [snip]
> 
> I don't think we can change assert syntax now.  What I was looking was
> for something more like:
> 
> assert(x == y);
> 
> prints out
> 
> "asserting x == y: true"
> 
> for asserts that pass when you have the 'verbose assert' flag turned
> on.  This should be easy to do in the compiler by just translating
> 
> assert(expr);
> 
> to something like:
> 
> auto result = evaluateAssert(expr);
> print("asserting expr: ", result ? "true" : "false");
> assert(result);
> 
> -Steve

Another possibility are named unittests and printing out "running test
'foobar' was successful".
One message for every assert is too verbose IMHO.

Cheers,
- Daniel

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code is
compiling (this is especially true when I'm doing version statements or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with that
switch, of course).


Could this be achieved within the language?

Andrei

Re: optionally verbose assertions

[Steven Schveighoffer]

On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson   
wrote:



Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:


On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running.
Every once in
a while, I have to change one to fail to make sure that code is
compiling (this
is especially true when I'm doing version statements or templates).
It would
be nice if there was a -assertprint mode which showed asserts
actually running
(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally
verbose assertions.
This could use 2 arguments instead of a predicate:
 assert(expressions, value);
Example use:


[snip]

I don't think we can change assert syntax now.  What I was looking was
for something more like:

assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned
on.  This should be easy to do in the compiler by just translating

assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);

-Steve


Another possibility are named unittests and printing out "running test
'foobar' was successful".
One message for every assert is too verbose IMHO.


I'm thinking of the code examples that have asserts in them.  I totally  
like the idea of code examples in ddoc being compiled as unit tests.  This  
ensures your examples don't get out of date or are not invalid (as many of  
phobos' examples are).  Nothing is worse when learning a language to  
encounter errors or unexpected results from the sanctioned examples.  This  
means they have to look like unit tests, but also be useful for learning  
(see my above issue).


A compromise might be to be able to name unit tests, and then run a  
specific unit test by name on execution only.  This allows you to ensure a  
specific unit test (and specific asserts in that unit test) are running  
without having to see all the asserts from the other unit tests, but also  
allows using asserts for general example code/testing.


This also could mean that you could simply directly compile a phobos  
module with -assertverbose -unittest and do:


./algorithm --run-unit-test std.algorithm.sort_example

to see all the asserts working for that example.

-Steve

Re: "Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu  
 wrote:



On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code is
compiling (this is especially true when I'm doing version statements or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with that
switch, of course).


Could this be achieved within the language?


I think you need to do it at the compiler level to make it useful.  For  
example, an assert like:


assert(container.length == 5);

To print this out properly, I'd want to see that the assert passed, but  
also what the test was.  I think there is already some work being  
commissioned (if not already in progress) on dissecting the expression  
into string form in the compiler.


I don't know how you would do this in a DRY fashion without compiler  
help.  You can't use a mixin string because mixins are compiled in the  
context where you mix them in.


I outlined a possible solution in a response to Daniel that I believe:

1. allows one to 'see' an example working that just uses asserts
2. allows one to run specific unit tests to make sure they are working  
(via names)

3. does not require any changes to any asserts in existance.

I think this would be an awesome feature.  One of the cool things about  
the new way phobos runs unit tests (one module at a time) is that if a  
particular test fails, I can just build/run it over and over again until  
it passes.  This is huge since to run the full phobos unit tests can take  
a while.


To just be able to select on the command line how to run unit tests (I  
think overtaking the command line args for unittest-enabled code is  
reasonable) would be a great tool for debugging code via unittests and  
assert printouts.


It also gives us a smooth transition into using ddoc examples as unit  
tests.


-Steve

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 10:34 AM, spir wrote:

On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:

On 4/14/11 6:52 AM, spir wrote:

On 04/14/2011 01:11 AM, bearophile wrote:

* Since most of them don't actually output anything, the program
> now detects output.length == 0 and says "Program run
> successfully." upon completion to give some feedback.

This is a problem. Unittest code is not meant to produce an output,
while online snippets to try are meant to nearly always produce a
meaningful output.


All my unittest blocks produce meaningful output; there exist firstly
for that. Am I an heretic?


No, you're just doing it wrong. Heretic might be sometimes good.

http://www.linfo.org/rule_of_silence.html


Right, I know that and totally disagree.


This is a good cue to revisit your opinion.


This rule is IMO the exact
opposite of human-friendliness (numerous authors on usability and
friends share this opinion, indeed).


This may be a misunderstanding of a valid human friendliness concern 
with a simple mistake. In addition, you reject an authoritative text 
with an appeal to an undefined authority.


Applying "let me output something and eye it" at the level of each unit 
test does not scale because it makes it extremely difficult to identify 
issues once one test of many produces unexpected output. There are 
programs (such as "expect") that automate that task. The ultimate goal 
is to make errors noisy and easy to identify.



Also, this is not what I'm talking about: I'm not here expecting just
"all fine, brother", but various data helping me and understand how
things actually worked; to be short, data useful to the coder during
development or debug. See also reply to Steven's post.


I understand, and I repeat: that approach works great for exploration, 
but won't scale for systematic unit testing.



Andrei

Re: "Try it now"

[Jonathan M Davis]

> On 04/14/2011 04:22 PM, Andrei Alexandrescu wrote:
> > On 4/14/11 6:52 AM, spir wrote:
> >> On 04/14/2011 01:11 AM, bearophile wrote:
>  * Since most of them don't actually output anything, the program
>  
>  > now detects output.length == 0 and says "Program run
>  > successfully." upon completion to give some feedback.
> >>> 
> >>> This is a problem. Unittest code is not meant to produce an output,
> >>> while online snippets to try are meant to nearly always produce a
> >>> meaningful output.
> >> 
> >> All my unittest blocks produce meaningful output; there exist firstly
> >> for that. Am I an heretic?
> > 
> > No, you're just doing it wrong. Heretic might be sometimes good.
> > 
> > http://www.linfo.org/rule_of_silence.html
> 
> Right, I know that and totally disagree. This rule is IMO the exact
> opposite of human-friendliness (numerous authors on usability and friends
> share this opinion, indeed).
> Also, this is not what I'm talking about: I'm not here expecting just "all
> fine, brother", but various data helping me and understand how things
> actually worked; to be short, data useful to the coder during development
> or debug. See also reply to Steven's post.

And I have no clue what you'd want to print. Normally, if the assertion 
passes, everything's fine. Seeing output from it would just be noise. Now, 
being able to verify that a particular unit test block is running when you're 
dealing with version blocks could be useful periodically, but all you really 
need to verify is that the test is run, not what it's doing. If you need to 
debug it, you debug it. And if you need to debug it, usually the assertions 
would be failing anyway. Having debug output printing all of the time would 
just get in the way and make it harder to find what you need when you're 
actually debugging, since you'd have too much debug output if everything's 
printing debug output. So, I really don't understand what you'd be looking to 
print.

I can understand someone wanting the list of tests printed so that they could 
see where in the tests the program is, but generally, all you need to know is 
whether the tests failed, and seeing the failed assertions gives you that. So, 
ultimately, I don't really understand the push for stuff being printed during 
unit tests unless you're explicitly debugging a unit test.

- Jonathan M Davis

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 12:00 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code is
compiling (this is especially true when I'm doing version statements or
templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with that
switch, of course).


Could this be achieved within the language?


I think you need to do it at the compiler level to make it useful. For
example, an assert like:

assert(container.length == 5);

To print this out properly, I'd want to see that the assert passed, but
also what the test was.


What's needed here is a "text of expression" feature similar to C's "#". 
That would help enforce and other artifacts too. I'm thinking along the 
lines of:


void myassert(string expr = __traits(text, condition))(bool condition) {
  ...
}

with, of course, a simpler syntax.


I think this would be an awesome feature. One of the cool things about
the new way phobos runs unit tests (one module at a time) is that if a
particular test fails, I can just build/run it over and over again until
it passes. This is huge since to run the full phobos unit tests can take
a while.


That's exactly how Phobos unittest work on Linux, and that was the 
motivation behind making it work that way.



Andrei

Re: Slides about Nemerle

[VladD2]

bearophile Wrote:

> Simple slides about Nemerle language, derived from C#, so far I have never 
> used Nemerle:
> http://www.reddit.com/r/programming/comments/gnaop/nemerle_vs_c/

It is better to learn a language by reading articles about it, but not looking 
to slides. Here is a simple introduction to the language:
https://docs.google.com/document/d/140tNKZrj8vgp7uGgK1tb7sVM_G45ZHTBf8McOLppy-k/edit?hl=en&authkey=CIiBucIC#

Re: optionally verbose assertions

[Jonathan M Davis]

> On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson 
> 
> wrote:
> > Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
> >> On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:
> >>> On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:
>  Sometimes, I worry that my unit tests or asserts aren't running.
>  Every once in
>  a while, I have to change one to fail to make sure that code is
>  compiling (this
>  is especially true when I'm doing version statements or templates).
>  It would
>  be nice if there was a -assertprint mode which showed asserts
>  actually running
>  (only for the module compiled with that switch, of course).
> >>> 
> >>> Man, I'm very pleased to read someone else advocating for optionally
> >>> verbose assertions.
> >>> 
> >>> This could use 2 arguments instead of a predicate:
> >>> assert(expressions, value);
> >>> 
> >>> Example use:
> >> [snip]
> >> 
> >> I don't think we can change assert syntax now. What I was looking was
> >> for something more like:
> >> 
> >> assert(x == y);
> >> 
> >> prints out
> >> 
> >> "asserting x == y: true"
> >> 
> >> for asserts that pass when you have the 'verbose assert' flag turned
> >> on. This should be easy to do in the compiler by just translating
> >> 
> >> assert(expr);
> >> 
> >> to something like:
> >> 
> >> auto result = evaluateAssert(expr);
> >> print("asserting expr: ", result ? "true" : "false");
> >> assert(result);
> >> 
> >> -Steve
> > 
> > Another possibility are named unittests and printing out "running test
> > 'foobar' was successful".
> > One message for every assert is too verbose IMHO.
> 
> I'm thinking of the code examples that have asserts in them. I totally
> like the idea of code examples in ddoc being compiled as unit tests. This
> ensures your examples don't get out of date or are not invalid (as many of
> phobos' examples are). Nothing is worse when learning a language to
> encounter errors or unexpected results from the sanctioned examples. This
> means they have to look like unit tests, but also be useful for learning
> (see my above issue).
> 
> A compromise might be to be able to name unit tests, and then run a
> specific unit test by name on execution only. This allows you to ensure a
> specific unit test (and specific asserts in that unit test) are running
> without having to see all the asserts from the other unit tests, but also
> allows using asserts for general example code/testing.
> 
> This also could mean that you could simply directly compile a phobos
> module with -assertverbose -unittest and do:
> 
> ./algorithm --run-unit-test std.algorithm.sort_example
> 
> to see all the asserts working for that example.

I want named unit tests regardless, because then you'd get recognizable 
function names in the stack traces from exceptions that escape unit test 
blocks. Being able to print out which unit test is running or just finished by 
using a particular flag would definitely make some people around here happier 
though (much as it definitely shouldn't be the default behavior).

- Jonathan M Davis

Re: "Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu  
 wrote:



On 4/14/11 12:00 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 9:03 AM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every
once in a while, I have to change one to fail to make sure that code  
is
compiling (this is especially true when I'm doing version statements  
or

templates). It would be nice if there was a -assertprint mode which
showed asserts actually running (only for the module compiled with  
that

switch, of course).


Could this be achieved within the language?


I think you need to do it at the compiler level to make it useful. For
example, an assert like:

assert(container.length == 5);

To print this out properly, I'd want to see that the assert passed, but
also what the test was.


What's needed here is a "text of expression" feature similar to C's "#".  
That would help enforce and other artifacts too. I'm thinking along the  
lines of:


void myassert(string expr = __traits(text, condition))(bool condition) {
   ...
}

with, of course, a simpler syntax.


It still isn't exactly right.  Assert has some special properties that  
cannot be duplicated exactly with library code.  Such as true lazy  
evaluation and elimination during release mode.


But yes, it would be nice to be able to get a string of the parameters of  
a function (macro?).  It would certainly make this more feasible.


However, all this is ignoring one simple thing -- the hundreds of  
thousands of lines of code (mostly from std.datetime ;) ) that already  
have asserts.  Hooking assert directly automatically gives us a tool for  
printf debugging without changing any code.


I would point out that even for this solution, we are still modifying the  
compiler.  Any particular reason why adding a new trait is more desirable  
than modifying assert?  I certainly feel that the auto-inclusion of all  
the existing asserts would far outweigh the extensibility of adding a  
trait (which could probably also be added at the same time).





I think this would be an awesome feature. One of the cool things about
the new way phobos runs unit tests (one module at a time) is that if a
particular test fails, I can just build/run it over and over again until
it passes. This is huge since to run the full phobos unit tests can take
a while.


That's exactly how Phobos unittest work on Linux, and that was the  
motivation behind making it work that way.


Yeah, I know, that's why I brought it up :)

-Steve

Re: optionally verbose assertions

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:27:32 -0400, Jonathan M Davis   
wrote:


On Thu, 14 Apr 2011 12:35:49 -0400, Daniel Gibson  



wrote:
> Am 14.04.2011 17:47, schrieb Steven Schveighoffer:
>> On Thu, 14 Apr 2011 11:28:39 -0400, spir   
wrote:

>>> On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:
 Sometimes, I worry that my unit tests or asserts aren't running.
 Every once in
 a while, I have to change one to fail to make sure that code is
 compiling (this
 is especially true when I'm doing version statements or templates).
 It would
 be nice if there was a -assertprint mode which showed asserts
 actually running
 (only for the module compiled with that switch, of course).
>>>
>>> Man, I'm very pleased to read someone else advocating for optionally
>>> verbose assertions.
>>>
>>> This could use 2 arguments instead of a predicate:
>>> assert(expressions, value);
>>>
>>> Example use:
>> [snip]
>>
>> I don't think we can change assert syntax now. What I was looking was
>> for something more like:
>>
>> assert(x == y);
>>
>> prints out
>>
>> "asserting x == y: true"
>>
>> for asserts that pass when you have the 'verbose assert' flag turned
>> on. This should be easy to do in the compiler by just translating
>>
>> assert(expr);
>>
>> to something like:
>>
>> auto result = evaluateAssert(expr);
>> print("asserting expr: ", result ? "true" : "false");
>> assert(result);
>>
>> -Steve
>
> Another possibility are named unittests and printing out "running test
> 'foobar' was successful".
> One message for every assert is too verbose IMHO.

I'm thinking of the code examples that have asserts in them. I totally
like the idea of code examples in ddoc being compiled as unit tests.  
This
ensures your examples don't get out of date or are not invalid (as many  
of

phobos' examples are). Nothing is worse when learning a language to
encounter errors or unexpected results from the sanctioned examples.  
This

means they have to look like unit tests, but also be useful for learning
(see my above issue).

A compromise might be to be able to name unit tests, and then run a
specific unit test by name on execution only. This allows you to ensure  
a

specific unit test (and specific asserts in that unit test) are running
without having to see all the asserts from the other unit tests, but  
also

allows using asserts for general example code/testing.

This also could mean that you could simply directly compile a phobos
module with -assertverbose -unittest and do:

./algorithm --run-unit-test std.algorithm.sort_example

to see all the asserts working for that example.


I want named unit tests regardless, because then you'd get recognizable
function names in the stack traces from exceptions that escape unit test
blocks. Being able to print out which unit test is running or just  
finished by
using a particular flag would definitely make some people around here  
happier

though (much as it definitely shouldn't be the default behavior).


I agree it should not be the default.

What I'm trying to do is find a solution that makes examples with asserts  
useful for learning (i.e. show that something is happening), and try and  
make it also be useful for unit test debugging.


Obviously, during normal unit tests, you want only errors to print out.

-Steve

Re: "Try it now"

[Jonathan M Davis]

> On Thu, 14 Apr 2011 13:16:33 -0400, Andrei Alexandrescu
> 
>  wrote:
> > On 4/14/11 12:00 PM, Steven Schveighoffer wrote:
> >> On Thu, 14 Apr 2011 12:48:26 -0400, Andrei Alexandrescu
> >> 
> >>  wrote:
> >>> On 4/14/11 9:03 AM, Steven Schveighoffer wrote:
>  Sometimes, I worry that my unit tests or asserts aren't running. Every
>  once in a while, I have to change one to fail to make sure that code
>  is
>  compiling (this is especially true when I'm doing version statements
>  or
>  templates). It would be nice if there was a -assertprint mode which
>  showed asserts actually running (only for the module compiled with
>  that
>  switch, of course).
> >>> 
> >>> Could this be achieved within the language?
> >> 
> >> I think you need to do it at the compiler level to make it useful. For
> >> example, an assert like:
> >> 
> >> assert(container.length == 5);
> >> 
> >> To print this out properly, I'd want to see that the assert passed, but
> >> also what the test was.
> > 
> > What's needed here is a "text of expression" feature similar to C's "#".
> > That would help enforce and other artifacts too. I'm thinking along the
> > lines of:
> > 
> > void myassert(string expr = __traits(text, condition))(bool condition) {
> > 
> > ...
> > 
> > }
> > 
> > with, of course, a simpler syntax.
> 
> It still isn't exactly right. Assert has some special properties that
> cannot be duplicated exactly with library code. Such as true lazy
> evaluation and elimination during release mode.
> 
> But yes, it would be nice to be able to get a string of the parameters of
> a function (macro?). It would certainly make this more feasible.
> 
> However, all this is ignoring one simple thing -- the hundreds of
> thousands of lines of code (mostly from std.datetime ;) ) that already
> have asserts. Hooking assert directly automatically gives us a tool for
> printf debugging without changing any code.

Actually, std.datetime doesn't use assert much. It mostly uses a version of 
assertPred which it has as a private function. Also, I've been rewriting the 
unit tests, and that will result in far fewer actual lines with assert or 
_assertPred thanks to more looping and whatnot. It does increase the need for 
printing out the actual results from an assertion though (which _assertPred 
does on failure). And what you're asking for here is at least related to the 
requested improvements to assert which resulted in assertPred being scrapped.

- Jonathan M Davis

Re: "Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:38:11 -0400, Jonathan M Davis   
wrote:


Actually, std.datetime doesn't use assert much. It mostly uses a version  
of
assertPred which it has as a private function. Also, I've been rewriting  
the

unit tests, and that will result in far fewer actual lines with assert or
_assertPred thanks to more looping and whatnot. It does increase the  
need for
printing out the actual results from an assertion though (which  
_assertPred
does on failure). And what you're asking for here is at least related to  
the
requested improvements to assert which resulted in assertPred being  
scrapped.


I forgot that assert isn't actually used much in std.datetime!

-Steve

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

Any particular reason why adding a new trait is more
desirable than modifying assert?


Absolutely!

Andrei

Re: single-line string?

[Jesse Phillips]

spir Wrote:

>  I 
> would like to know how & how well other editors deal with all of that 
> (especially but not only emacs and vim).

Vim's heritage is line based editing. For this reason operations are performed 
by line and it does processing by line. However as it is visual its buffer 
consists of more than the line being edited.

Highlighting is done once again on a per line basis and only of the visible 
area (give but never take a few). To handle multiple lines Vim uses 
synchronization. It makes use of specific structures which it can use to 
'anchor' how the lines below will be highlighted, and again it only needs to 
process till the end of the visible area (it will continue processing as you 
scroll down).

You can specify how many lines back Vim will look for an anchor before it gives 
up. Right now I think comments are the only anchor for D and it looks back like 
300 lines. This does mean that highlighting can be incorrect. If you jump from 
the top to the bottom (not scrolling) and there was an open quote/comment that 
was never closed you will end up with code which highlights as though it wasn't 
in a quote/comment.

Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))

[Jérôme M. Berger]

spir wrote:
> Actually, I have never been pleased that func defs (1) look like func
> calls (2) have an exceptional syntax compared to other definitions. I'd
> like instead eg:
> 
> square = function (int n) int {
> return n * n;
> }
> 
That is still different from other definitions where the type comes
first. But the following would work too:

function (int n) int square = {
   return n*n;
}

And both would be easier to parse to boot:) There are actually
languages out there with this kind of syntax.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: single-line string?

[spir]

On 04/14/2011 05:03 PM, Andrej Mitrovic wrote:

Some editors automatically add the closing double quote, which pretty
much eliminates this problem. For example:

step1: string s = |<- caret
step2: string s = "|<- caret
step3: string s = "|"<- editor automatically adds the ending quote
step4: string s = "typesomething"
step5: string s = "typesomething";<- you don't have to move the
cursor after the closing quote, just type in the extra " and it will
automatically overwrite the existing one. Then you add ->  ;

Perhaps Geany doesn't automatically do step5, and doesn't let you
overwrite the extra closing quote. This might explain why you don't
like automatic addition of the closing quote.

This wouldn't be hard to implement using Scintilla. The problem is
most IDE's and editors which use Scintilla barely scratch the surface
of its potential. They just embed the editing component and add a few
dialog boxes to configure font sizes.


Geany has this feature (mentionned it in original post, actually), but:
1. As already said, it still reinterprets the code just like if one had typed 
both '"' separately.

2. No step 5, as you guessed.

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu  
 wrote:



On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

Any particular reason why adding a new trait is more
desirable than modifying assert?


Absolutely!


Maybe I worded my question wrong.  What I meant was what *is* the  
particular reason.


And keep in mind, when I say modifying assert, I mean changing the way  
assert compiles, not changing it's usage.


-Steve

Re: optionally verbose assertions

[spir]

On 04/14/2011 05:47 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:


On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running. Every once in
a while, I have to change one to fail to make sure that code is compiling (this
is especially true when I'm doing version statements or templates). It would
be nice if there was a -assertprint mode which showed asserts actually running
(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally verbose
assertions.
This could use 2 arguments instead of a predicate:
assert(expressions, value);
Example use:


[snip]

I don't think we can change assert syntax now. What I was looking was for
something more like:

assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned on. This
should be easy to do in the compiler by just translating

assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);


Yes. Actually, I did not mean changing assert specifically, rather having an 
"asserting func" with 2 arguments, like;

check(expression, expected_value);
Now, my post was unclear (previous ones on the topic used "check").

Denis
--
_
vita es estrany
spir.wikidot.com

Re: optionally verbose assertions

[spir]

On 04/14/2011 06:35 PM, Daniel Gibson wrote:

Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:


On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running.
Every once in
a while, I have to change one to fail to make sure that code is
compiling (this
is especially true when I'm doing version statements or templates).
It would
be nice if there was a -assertprint mode which showed asserts
actually running
(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally
verbose assertions.
This could use 2 arguments instead of a predicate:
  assert(expressions, value);
Example use:


[snip]

I don't think we can change assert syntax now.  What I was looking was
for something more like:

assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned
on.  This should be easy to do in the compiler by just translating

assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);


The problem is how do /you/ get expr's original expression? In other words, is 
there a way to do it without compiler magic?
(I think even passing expr as string and using string mixins would not do it, 
because the string must be constant.)



-Steve


Another possibility are named unittests and printing out "running test
'foobar' was successful".
One message for every assert is too verbose IMHO.


There may be a third, intermediate mode. But many times having the list of 
check result is very helpful to support one's thought, or is just what you need 
in any case. Wouldn't it be stupid to require you to write one writeln per 
assertion just because we omitted this verbode mode?


Denis
--
_
vita es estrany
spir.wikidot.com

Re: optionally verbose assertions

[spir]

On 04/14/2011 06:52 PM, Steven Schveighoffer wrote:

A compromise might be to be able to name unit tests, and then run a specific
unit test by name on execution only.  This allows you to ensure a specific unit
test (and specific asserts in that unit test) are running without having to see
all the asserts from the other unit tests, but also allows using asserts for
general example code/testing.


This is precisely why I often have a single unittest block, that controls 
actual test funcs (which have names :-)


void test1 () {...}
void test2 () {...}
void test3 () {...}
unittest {
// just uncomment func calls you want to run
//~test1();
//~test2();
//~test3();
}
void main () {}

Denis
--
_
vita es estrany
spir.wikidot.com

Re: Linux RPM out of date

[Kai Meyer]

Kai,


It would be indeed great to automate this once and for all.

We have an installer project at
https://github.com/D-Programming-Language/installer. If you create a
pull request for that project, I'd be glad to review and integrate it.

If you need help with creating a pull request on github, feel free to
ask here - several contributors are quite familiar with such.


Thanks,

Andrei


The current project has a few features that I'm not sure are very 
desirable. I would like some feedback as I try to decide how to best


1) Repackage the .zip distribution from the website.
It hurts my brain to think that's the best way to approach this. I've 
already verified that a fairly stock CentOS 5.6 and Fedora 14 systems 
can compile dmd, phobos, and druntime all from source on git. I think 
this would be preferable.


2) Support arbitrary versions of DMD.
I think it would be better to create tags in the installer project that 
match the other tags/versions. I have something that works right now 
with 2.052 (as far as I can test). I would rather not have to worry 
about backwards compatibility as we move forward once it's finished.


3) Makefile creates a spec file and then tries to start the build.
Would we like to have a method that should work something like this?
git clone /installer.git
cd installer
./this-script-should-result-in-the-rpm
Or should we simply provide .patch files and a .spec file?


-Kai Meyer

Re: GSoC 2011 update: we have 3 slots

[Fawzi Mohamed]

On 14-apr-11, at 00:36, Andrei Alexandrescu wrote:

Digital Mars has received 3 slots for GSoC 2011. That means we need  
to choose three student projects to go with.


We have enjoyed many strong applications and we have a great lineup  
of mentors, but Google is reluctant to allocate a lot of slots to  
first-time participants because historically Google has experienced  
a high rate of burn-out with new organizations. Most new  
participants have only received 2 slots, so this is in fact a vote  
of confidence for our fledgling participation.


So we need to prove ourselves by choosing three outstanding projects  
and by taking them to completion. I warmly thank all participants  
(students and mentors) and I hope they all will stick around and  
help even though it is impossible to select them all for formal roles.


I can only agree with Andrei, choosing just 3 projects will be hard,  
and if you happen not to be between the 3 choosen, it doesn't  
necessarily mean that your contribution wasn't good, or you aren't  
good, but simply that given the constraints we had we judged another  
project sightly better or slightly more important for our current  
priorities.
It will be a though decision, and we would for sure be honored and  
happy if some of those that in the end will not be selected still sick  
around contribute to D community, and in any case we wish you all the  
best.
And sorry if we make you jump through some hoops, but it is just that  
it is difficult to decide, and we should choose project that will have  
success, even to guarantee that google will continue to support us.


Fawzi

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

Any particular reason why adding a new trait is more
desirable than modifying assert?


Absolutely!


Maybe I worded my question wrong. What I meant was what *is* the
particular reason.


Already mentioned it - enforce() is a prime example. Any similar 
facility could make good use the feature.



And keep in mind, when I say modifying assert, I mean changing the way
assert compiles, not changing it's usage.


I understand.


Andrei

Re: question to Walter - about the GUI library

[Walter Bright]

On 4/14/2011 7:31 AM, Jesse Phillips wrote:

Walter has dropped the idea of endorsing a GUI/any library. There was once a
statement that DWT was the official library for D, development promptly
stopped afterwards. Not trying to claim there was causation here.


I'm not making that mistake again!

Re: "Try it now"

[spir]

On 04/14/2011 07:09 PM, Andrei Alexandrescu wrote:

Applying "let me output something and eye it" at the level of each unit test
does not scale because it makes it extremely difficult to identify issues once
one test of many produces unexpected output. There are programs (such as
"expect") that automate that task. The ultimate goal is to make errors noisy
and easy to identify.


I do agree. But this point gets very different once:
(1) One can selectively chose which tests to run, thus having only output from 
one(s) relevant to the issue at hand (eg via named unittests),

(2) one can switch from silent to verbose modes.

In the case of unittests used for regression testing (*), the silent mode would 
initially just say "there is an error here". Then switching to verbose mode, on 
relevant tests only, would provide helpful data to solve the issue.
But for me unittests are far to be useful only for regression tests. They are 
everyday development tools I constantly use: as sample code, to study what code 
actually does, te debud or improve a piece of code; even if I don't practice 
TDD at all (rarely use tests as kinf of spec).


I have talked about that already, but the message seems difficult to pass for a 
reason I do not grok.


Denis

(*) I mean, to check all still works fine after a change on an initially 
running codebase.

--
_
vita es estrany
spir.wikidot.com

Re: question to Walter - about the GUI library

[Jacob Carlborg]

On 2011-04-14 16:31, Jesse Phillips wrote:

David Wang Wrote:


Dear Walter Bright,

I would like to know that what GUI library you would like to use for D Language 
?

Have you ever considered the GTK+ 3.0? or other library? or you will produce a
new D library of GUI?


wainting for your kindly feedback.


Best regards.
David.


Walter has dropped the idea of endorsing a GUI/any library. There was once a 
statement that DWT was the official library for D, development promptly stopped 
afterwards. Not trying to claim there was causation here.


It's in development again now. I just announced that it now supports D2.

--
/Jacob Carlborg

Re: Ceylon language

[bearophile]

spir:

> But I guess optionality could, and should, extend to non-ref types; thus, null
> is just a particular case of non-existence. And this would apply especially on
> function parameters:
>void f (int i?) {...}

>From C# experience it seems non-ref nullable types are not so useful (and it's 
>not hard to implement them with the language itself).


> Also, they should reuse '?' to mean 'exists', possibly '!?' meaning the 
> opposite:
> void f (int i?) {
> if (? i) doWithI(i);
> if (!? i) doWithoutI();
> ...
> }

Better to keep the language less perlish.


> great! get rid of new in D as well

This was discussed a lot. I don't have much interest in this change.


>> We may define a class method "by reference":
>>
>> void hello(String name) = hello;
>
> ???

The second hello is a function reference. Nothing so interesting to see here.


> I don't get the diff between currying & partial app.

Take a look at the wikipedia pages, the difference is small, they are quite 
related things, their difference is no so important:
http://en.wikipedia.org/wiki/Currying
http://en.wikipedia.org/wiki/Partial_application


> And find this feature much complication for close to uselessness.

In functional-style programming it's useful to be able to curry (or partially 
applicate) functions, it helps keep the code shorter and less noisy.


> examples?

See the first PDF at those pages. In the meantime people have mirrored those 
PDFs, see the Reddit thread.


> Yo; and while you're at "typestating", extend the feature to any type (not 
> only
> pointers).

For this you may need to look for a language (Rust) designed for the ground up 
for this feature.

Bye,
bearophile

Re: optionally verbose assertions

[Steven Schveighoffer]

On Thu, 14 Apr 2011 14:38:32 -0400, spir  wrote:


On 04/14/2011 06:35 PM, Daniel Gibson wrote:

Am 14.04.2011 17:47, schrieb Steven Schveighoffer:

On Thu, 14 Apr 2011 11:28:39 -0400, spir  wrote:


On 04/14/2011 04:03 PM, Steven Schveighoffer wrote:

Sometimes, I worry that my unit tests or asserts aren't running.
Every once in
a while, I have to change one to fail to make sure that code is
compiling (this
is especially true when I'm doing version statements or templates).
It would
be nice if there was a -assertprint mode which showed asserts
actually running
(only for the module compiled with that switch, of course).


Man, I'm very pleased to read someone else advocating for optionally
verbose assertions.
This could use 2 arguments instead of a predicate:
  assert(expressions, value);
Example use:


[snip]

I don't think we can change assert syntax now.  What I was looking was
for something more like:

assert(x == y);

prints out

"asserting x == y: true"

for asserts that pass when you have the 'verbose assert' flag turned
on.  This should be easy to do in the compiler by just translating

assert(expr);

to something like:

auto result = evaluateAssert(expr);
print("asserting expr: ", result ? "true" : "false");
assert(result);


The problem is how do /you/ get expr's original expression? In other  
words, is there a way to do it without compiler magic?
(I think even passing expr as string and using string mixins would not  
do it, because the string must be constant.)


compiler magic :)  I.e. this proposal requires the compiler to change the  
way assert is implemented.


-Steve

Re: [OT] Spaces/tabs (Was: simple display (from: GUI library for D))

[spir]

On 04/14/2011 07:58 PM, "Jérôme M. Berger" wrote:

spir wrote:

Actually, I have never been pleased that func defs (1) look like func
calls (2) have an exceptional syntax compared to other definitions. I'd
like instead eg:

 square = function (int n) int {
 return n * n;
 }


That is still different from other definitions where the type comes
first.


True. I was firstly evoking the "x = y" form.


 But the following would work too:

function (int n) int square = {
return n*n;
}

And both would be easier to parse to boot:)


Yes, I like your format as well.


 There are actually
languages out there with this kind of syntax.


Yop, I know (my example was Lua-like: we are not reinventing the wheel ;-)

Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[Steven Schveighoffer]

On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu  
 wrote:



On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

Any particular reason why adding a new trait is more
desirable than modifying assert?


Absolutely!


Maybe I worded my question wrong. What I meant was what *is* the
particular reason.


Already mentioned it - enforce() is a prime example. Any similar  
facility could make good use the feature.


Sure.  However, not modifying assert means all asserts in my code should  
now be rewritten to myassert, or whatever function is implemented.  The  
huge benefit of modifying assert is that we don't have to change any  
existing code.


I'm not saying adding a trait is not desirable, I just think it doesn't  
get us to the right place on its own.


If I ever get around to hacking the compiler, I certainly will try this to  
see how well it works.


-Steve

Re: single-line string?

[spir]

On 04/14/2011 07:58 PM, Jesse Phillips wrote:

spir Wrote:


  I
would like to know how&  how well other editors deal with all of that
(especially but not only emacs and vim).


Vim's heritage is line based editing. For this reason operations are performed 
by line and it does processing by line. However as it is visual its buffer 
consists of more than the line being edited.

Highlighting is done once again on a per line basis and only of the visible 
area (give but never take a few). To handle multiple lines Vim uses 
synchronization. It makes use of specific structures which it can use to 
'anchor' how the lines below will be highlighted, and again it only needs to 
process till the end of the visible area (it will continue processing as you 
scroll down).

You can specify how many lines back Vim will look for an anchor before it gives 
up. Right now I think comments are the only anchor for D and it looks back like 
300 lines. This does mean that highlighting can be incorrect. If you jump from 
the top to the bottom (not scrolling) and there was an open quote/comment that 
was never closed you will end up with code which highlights as though it wasn't 
in a quote/comment.


Thanks for this precision.
I prefere the possibility of erroneous highlighting you describe here than 
current Geany's behaviour.


[I have stopped exchanging on Geany's mailing list about features/issues/bugs 
because, it beeing based on scintlla, they seem to constantly forward people to 
request or remark there... except for points they feel concerned with. This is 
understandable, indeed, and rather a fact than a critique; i would probably 
behave the same way in their position. They also are truely blocked by 
scintilla on some points, i guess like when Geany did not properly cope with d 
multiline comments.]


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[Gerrit Wichert]

Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:
I'm quite excited about the new look of std (right now realized only 
by 
http://d-programming-language.org/phobos-prerelease/std_algorithm.html). 


I just had a look and stumbled over the short description of group:

 
group([5, 2, 2, 3, 3]) returns a range containing the tuples 
tuple(5, 1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).


there seems to be one 'touple(5, 1)' too much.

Re: Ceylon language

[spir]

On 04/14/2011 09:06 PM, bearophile wrote:

But I guess optionality could, and should, extend to non-ref types; thus, null
>  is just a particular case of non-existence. And this would apply especially 
on
>  function parameters:
>  void f (int i?) {...}

 From C# experience it seems non-ref nullable types are not so useful (and it's 
not hard to implement them with the language itself).


Dunno C# at all.
But I find optionality far more useful for non-ref types, since in the general 
case there is no truelly special or invalid value like null. What value means 
undefined/inexistent/non-provided, for an int? a bool? Unlike for ref'ed types 
(actual pointers/classes/arrays) we simply cannot express this without language 
support.
This also leads to actual distinction of null and [] or "" for arrays & 
strings. Just dreaming...


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[David Nadlinger]

On 4/14/11 9:38 PM, Gerrit Wichert wrote:

Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:

I'm quite excited about the new look of std (right now realized only
by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).


I just had a look and stumbled over the short description of group:


group([5, 2, 2, 3, 3]) returns a range containing the tuples tuple(5,
1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).

there seems to be one 'touple(5, 1)' too much.


This is already fixed in Git, but Andrei apparently didn't get around to 
update the build on the website – thanks anyway.


David

Re: "Try it now"

[spir]

On 04/14/2011 09:10 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 14:57:44 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 1:26 PM, Steven Schveighoffer wrote:

On Thu, 14 Apr 2011 13:54:00 -0400, Andrei Alexandrescu
 wrote:


On 4/14/11 12:26 PM, Steven Schveighoffer wrote:

Any particular reason why adding a new trait is more
desirable than modifying assert?


Absolutely!


Maybe I worded my question wrong. What I meant was what *is* the
particular reason.


Already mentioned it - enforce() is a prime example. Any similar facility
could make good use the feature.


Sure. However, not modifying assert means all asserts in my code should now be
rewritten to myassert, or whatever function is implemented. The huge benefit of
modifying assert is that we don't have to change any existing code.

I'm not saying adding a trait is not desirable, I just think it doesn't get us
to the right place on its own.

If I ever get around to hacking the compiler, I certainly will try this to see
how well it works.


A solution may be to carefully craft the new trait-using func's interface so 
that upgrading can be automatised (rewriting tool for assert calls only); 
possibly with constraints to make the tool's life easier, like "assertions 
stands alone on their line".


Denis
--
_
vita es estrany
spir.wikidot.com

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 3:00 PM, David Nadlinger wrote:

On 4/14/11 9:38 PM, Gerrit Wichert wrote:

Am 13.04.2011 22:38, schrieb Andrei Alexandrescu:

I'm quite excited about the new look of std (right now realized only
by
http://d-programming-language.org/phobos-prerelease/std_algorithm.html).


I just had a look and stumbled over the short description of group:



group([5, 2, 2, 3, 3]) returns a range containing the tuples tuple(5,
1), tuple(5, 1), tuple(2, 2), and tuple(3, 2).

there seems to be one 'touple(5, 1)' too much.


This is already fixed in Git, but Andrei apparently didn't get around to
update the build on the website – thanks anyway.

David


BTW there is a proposal to change group to yield a range of ranges 
instead of a range of tuples.


Do you folks estimate this could cause significant harm to existing code?


Thanks,

Andrei

Re: "Try it now"

[bearophile]

Andrei:

> BTW there is a proposal to change group to yield a range of ranges 
> instead of a range of tuples.
> 
> Do you folks estimate this could cause significant harm to existing code?

This proposal makes group closer to the semantics of the Python 
itertools.groupby. This change doesn't harm my code significantly.

But in my Python code most times I use groupby I have to convert the inner 
generator (the inner range) in something eager. So for me the current behaviour 
of group is OK. What are the reasons to change it?

Bye,
bearophile

Re: "Try it now"

[Andrei Alexandrescu]

On 4/14/11 3:31 PM, bearophile wrote:

Andrei:


BTW there is a proposal to change group to yield a range of ranges
instead of a range of tuples.

Do you folks estimate this could cause significant harm to existing code?


This proposal makes group closer to the semantics of the Python 
itertools.groupby. This change doesn't harm my code significantly.

But in my Python code most times I use groupby I have to convert the inner 
generator (the inner range) in something eager. So for me the current behaviour 
of group is OK. What are the reasons to change it?

Bye,
bearophile


The reasons for changing is that often you have groups in which elements 
are not identical, but instead in the same equivalence class. So you 
want not only their number - you want to take a look at the actual 
items. (Consider e.g. grouping some strings by their length.)


Andrei

Distinction of null and empty [was Re: Ceylon language]

[Jesse Phillips]

spir Wrote:

> This also leads to actual distinction of null and [] or "" for arrays & 
> strings. Just dreaming...

Really? You want this? I really like that a null array is equal to an empty 
array.

If you really care to find out if a string is null

if(str is null)

Re: question to Walter - about the GUI library

[Jesse Phillips]

Jacob Carlborg Wrote:

> It's in development again now. I just announced that it now supports D2.
> 
> -- 
> /Jacob Carlborg

Yes, I shouldn't have left it sounding as though DWT has died. However it was 
picked up a year or two later and was completely done from scratch.

Re: single-line string?

[Nick Sabalausky]

"spir"  wrote in message 
news:mailman.3500.1302792612.4748.digitalmar...@puremagic.com...
>
> This is a bug of the editor, indeed, but since Geany is based on 
> Scintilla's editon component, I guess this bug may be widely shared.

FWIW, I use Programmer's Notepad 2 which is also based on Scintilla. The 
somewhat older version I've been using (I need to update, just haven't 
gotten around to it yet) doesn't have that problem *because* it doesn't 
recognize D's comments as being multi-line. But I just checked the latest 
version, and it's just like you describe: multi-line strings are highlighted 
correctly, but typing it in unfolds the code that comes after. So it 
probably is a Scintilla issue.

Personally, I don't mind, since I don't use code folding frequently. But I 
can see how that could be annoying. Especially since, just like you, I find 
those "auto-closing" features to just get in my way and I normally turn them 
off.

It's unfortunate, too, since Scintilla does have a lot of good things going 
for it. But then once in a while I'll come across some little thing I wish 
it did differently (for instance, I wish they were receptive to having an 
option for elastic tabstops, and also there's this code folding issue: 
http://code.google.com/p/pnotepad/issues/detail?id=476 ). Heh, Scintilla's 
another one of the 1,000,000 things I'd love to do a D fork of if I had the 
time.

[OT] Partial-reparsing thory?

[Nick Sabalausky]

Is anyone aware of any (formal or informal) 
theory/information/research/articles/etc. that's already been done on the 
idea of reparsing *part* of an already-parsed source? Either lexing, parsing 
or both together. Preferably LR, but LL might be helpful, too. (I'd imagine 
it may be notably more difficult with LR. May need to keep track of all the 
parsing steps taken the first time around, and may need to continue 
re-parsing to the end of the source.)

I know code editors deal with that sort of thing a lot, but my understanding 
is they often accept a certain amount of inaccuracy (for the sake of being 
more line-oriented) and also tend to be more lexing-oriented and very light 
on parsing.

Backporting Tango runtime enhancements to druntime

[SiegeLord]

I am porting Tango to D2 and while I try my best to use druntime instead of 
Tango's runtime, occasionally I find that Tango's runtime has additional 
features that other parts of Tango make use of.

The most important of these differences right now is the Thread module. For 
example, Tango's version has support for schedulers for its fibers. I really 
don't want Tango to lose any features while transferring over to D2, so I'd 
prefer for these differences to be backported to druntime. The copyright of 
these modules seems to be assigned to the current developers of druntime/users 
of D2 (Sean Kelly, Fawzi Mohamed), so in principle licensing should not be an 
issue. Before I embark on the quest to make a druntime pull request, I am 
wondering if there is interest and willingness to merge those changes in on the 
part of the current druntime developers?

Also, if this discussion is best done on the druntime mailing list... can 
someone tell me where that mailing list is?

-SiegeLord

Re: Backporting Tango runtime enhancements to druntime

[Walter Bright]

On 4/14/2011 4:15 PM, SiegeLord wrote:

Also, if this discussion is best done on the druntime mailing list... can
someone tell me where that mailing list is?



http://lists.puremagic.com/mailman/listinfo/d-runtime

Re: [OT] Partial-reparsing thory?

[spir]

On 04/15/2011 12:51 AM, Nick Sabalausky wrote:

Is anyone aware of any (formal or informal)
theory/information/research/articles/etc. that's already been done on the
idea of reparsing *part* of an already-parsed source? Either lexing, parsing
or both together. Preferably LR, but LL might be helpful, too. (I'd imagine
it may be notably more difficult with LR. May need to keep track of all the
parsing steps taken the first time around, and may need to continue
re-parsing to the end of the source.)

I know code editors deal with that sort of thing a lot, but my understanding
is they often accept a certain amount of inaccuracy (for the sake of being
more line-oriented) and also tend to be more lexing-oriented and very light
on parsing.


This is a very interesting question.

I guess it may have to play with "diffs", as a required tool to identify 
differences in-relation-to original source. The result may be a set of 
intervals (each a pair of indices) in both original and modified sources. Then, 
if ever nodes keep track of indices in original source, one may be able to 
identify the one node covering (all of) a diven piece of diff. This would be 
what needs be reparsed.
If ever this succeds, then one can pass to next diff, with an adjustment/offset 
of indices which should normally be already given by the diff tool.
Well, this superficial view may be totally wrong, and/or biased toward PEG 
parsing which I'm most familiar with. I guess things may well become more 
complicated with the common approach of 2-separated-pass lexing + parsing; at 
least, you'd need offset adjustment successively on character- and then on 
lexeme- indices.


There may also be some similarity with the (apparently) simpler problem of 
error recovery: restart parsing "somewhere" after a match failure.


Denis
--
_
vita es estrany
spir.wikidot.com

Re: [OT] Partial-reparsing thory?

[Nick Sabalausky]

"spir"  wrote in message 
news:mailman.3527.1302824019.4748.digitalmar...@puremagic.com...
> On 04/15/2011 12:51 AM, Nick Sabalausky wrote:
>> Is anyone aware of any (formal or informal)
>> theory/information/research/articles/etc. that's already been done on the
>> idea of reparsing *part* of an already-parsed source? Either lexing, 
>> parsing
>> or both together. Preferably LR, but LL might be helpful, too. (I'd 
>> imagine
>> it may be notably more difficult with LR. May need to keep track of all 
>> the
>> parsing steps taken the first time around, and may need to continue
>> re-parsing to the end of the source.)
>>
>> I know code editors deal with that sort of thing a lot, but my 
>> understanding
>> is they often accept a certain amount of inaccuracy (for the sake of 
>> being
>> more line-oriented) and also tend to be more lexing-oriented and very 
>> light
>> on parsing.
>
> This is a very interesting question.
>
> I guess it may have to play with "diffs", as a required tool to identify 
> differences in-relation-to original source. The result may be a set of 
> intervals (each a pair of indices) in both original and modified sources. 
> Then, if ever nodes keep track of indices in original source, one may be 
> able to identify the one node covering (all of) a diven piece of diff. 
> This would be what needs be reparsed.
> If ever this succeds, then one can pass to next diff, with an 
> adjustment/offset of indices which should normally be already given by the 
> diff tool.
> Well, this superficial view may be totally wrong, and/or biased toward PEG 
> parsing which I'm most familiar with. I guess things may well become more 
> complicated with the common approach of 2-separated-pass lexing + parsing; 
> at least, you'd need offset adjustment successively on character- and then 
> on lexeme- indices.
>
> There may also be some similarity with the (apparently) simpler problem of 
> error recovery: restart parsing "somewhere" after a match failure.
>

Yea. My thought was to keep note, for each node, of all the start/end 
indicies into the source. When a chunk of text is changed, the parse tree 
(or list of tokens if it's lex-only) gets notified about what got changed 
and where (Maybe the parse tree would even *be* the primary internal 
representation of the source). Then it can check through the tree and know 
what needs to be re-lexed/re-parsed.

But I guess what I'm more interested in is the mechanics of actually doing 
that re-parsing once you know what sub-tree (or sub-trees) you need to 
re-parse. I guess it may seem simple, just run the lexer/parser on that 
"dirty" subset of the code (using the root of the affected sub-tree as the 
"starting nonterminal" instead of using the grammar's usual "starting 
nonterminal") and replace the "dirty" subtrees with the fresh new ones (and 
then update the start/end indicies of the rest of the tree, perhaps lazily.) 
But I suspect there may be some notable gotchas, especially relating to 
either LR parsing (since it's bottom-up, but you're tying to fit it into a 
known "top" - then again, I guess that's normally true of LR anyway) or just 
what to do with the nodes that come from after the affected part of the 
source (it could probably cause some sort of cascade, or at least a 
partial-cascade). And maybe certain sub-trees of the affected sub-trees 
could be skipped. Etc.

I'd imagine lex-only would be a lot easier.

Re: Ceylon language

[Nick Sabalausky]

"spir"  wrote in message 
news:mailman.3497.1302788057.4748.digitalmar...@puremagic.com...
> On 04/13/2011 02:34 PM, bearophile wrote:
>
>>
>> If a value of type T can be null, it must be declared as type 
>> Optional, which may be abbreviated to T?
>>
>> String? name = process.args.first;
>> if (exists name) {
>>  writeLine("Hello " name "!");
>> }
>> else {
>>  writeLine("Hello World!");
>> }
>>
>> Use of an optional value must be guarded by the if (exists ... ) 
>> construct. Therefore, NullPointerExceptions are impossible.
>>
>> This is exactly what I suggested for D in a enhancement request.
>> It seems this kind of stuff is becoming a standard in new languages.
>
> +++
>
> But I guess optionality could, and should, extend to non-ref types; thus, 
> null is just a particular case of non-existence. And this would apply 
> especially on function parameters:
>void f (int i?) {...}
>

Oh absolutely. Haxe has nullable-primatives which really comes in handly at 
times (it often prevents the need for a separate bool to keep track of). 
Only problem is that in Haxe, not only is nullable the default, but it 
doesn't even *have* any non-nullables at all, for any type.


>
> I don't get the diff between currying & partial app. And find this feature 
> much complication for close to uselessness.
>

I'm not certain either, but I *think* partial application is just like 
currying except there's some sort of arbitrary limitaion on what 
combination(s) of paramaters you can choose to specify or not specify. And 
that limitation is based purely on what order the function defines its 
parameters. So basically, my understanding is that partial application is an 
arbitrarily-gimped currying.


>>
>> A class or interface satisfies zero or more interfaces
>>
>> shared class Character(Natural utf16)
>>  extends Object()
>>  satisfies Ordinal&  Comparable  {
>>  ...
>> }
>>
>> The syntax X&Y represents the intersection of two types. The syntax X|Y 
>> represents the union of two types.
>
> Too bad, they got it wrong, like D. Should instead rip Go interfaces, 
> which are structural & implicite, while still fully compile-time 
> type-safe:
>
> struct File inStream {
> ...
> void write (string s) {...};
> }
> ...
> interface Writer {
> void write (string s);
> }
> File is *also* a Writer, thus one can call the following on a specimen of 
> File:
> void formatWrite (Writer w, string s, string format) {...}
>
> More generally, any type can satisfy any number of interfaces, wherever 
> and whenever they are defined (eg years after, in user code). The 
> obligation of explicitely declaring interface satisfaction is both useless 
> and blocking.
>
> Free interfaces even provide some kind of simple generics for free (like 
> in above example). And there is no need for
>  ... if (is(...))
> or
>  ... if (isWriter!T)
>

I think Go's implicit interfaces are horrible. It's literally nothing more 
than duck-typing at compile time (ie, static duck-typing) and fully inherits 
duck-typing's downfalls (notably that it's sloppy and conflates 
name/signature with semantics - which is an entirely false connection). Of 
course, I guess this argument doesn't hold if you're a duck-typing fan ;)


> Too bad its base for imrovement is Java (there is no way to get light & 
> flexible coding from there, you'd have to change everything ;-),

Yup. This is one of the reasons I don't buy the claims of "Java's fast now, 
really!". In fact, the article I'm [trying to] write for the article 
competition relates to this. Basically, code can't be fast *and* flexible 
*and* maintable without real metaprogramming (and class-based generics don't 
count), and Java AFAIK just doesn't have metaprogramming. Although I suppose 
you might be able to hack it by using a pre-processor, but pre-processors 
have their downsides. And even if you did use one, Java's requirement that 
every aggregate type be a class can be a real hinderance. Of course, the 
JVM's advanced class/object optimizations may be able to help - but only to 
a point, and you still can't reliably prevent situations that would hinder 
the JVM's ability to do the necessary optimizations.

Re: Ceylon language

[Nick Sabalausky]

"bearophile"  wrote in message 
news:io7gk3$1jea$1...@digitalmars.com...
> spir:
>
>> But I guess optionality could, and should, extend to non-ref types; thus, 
>> null
>> is just a particular case of non-existence. And this would apply 
>> especially on
>> function parameters:
>>void f (int i?) {...}
>
> From C# experience it seems non-ref nullable types are not so useful (and 
> it's not hard to implement them with the language itself).
>

My experience indicates it's hard to implement useful generics in C# at all. 
(Ex: Missing IArithmetic, anyone?)

Re: Distinction of null and empty [was Re: Ceylon language]

[Nick Sabalausky]

"Jesse Phillips"  wrote in message 
news:io7oov$21d8$1...@digitalmars.com...
> spir Wrote:
>
>> This also leads to actual distinction of null and [] or "" for arrays &
>> strings. Just dreaming...
>
> Really? You want this? I really like that a null array is equal to an 
> empty array.
>

I've thought about that and I don't know how I feel about it. On one hand, I 
can certainly image cases where the distiction between null and empty would 
be useful. But OTOH, after having to put up with the nightmare of VB6's "One 
million distinct ways to have a string that doesn't contain anything", I'm 
hesitent at embracing extra ways to have "ain't nuthin' here".

Re: Units of measurement for D (Phobos?)

[Nick Sabalausky]

I see no one's responded yet. FWIW, I love the idea of having a static units 
system in D. But I just haven't really had a chance to look through your 
post here, or your code. So busy...  :(

Re: Distinction of null and empty [was Re: Ceylon language]

[Kagamin]

Nick Sabalausky Wrote:

> I've thought about that and I don't know how I feel about it. On one hand, I 
> can certainly image cases where the distiction between null and empty would 
> be useful. But OTOH, after having to put up with the nightmare of VB6's "One 
> million distinct ways to have a string that doesn't contain anything", I'm 
> hesitent at embracing extra ways to have "ain't nuthin' here".
> 

In our project we use

if(string.IsNullOrEmpty(str)){...}

almost everywhere
only in two places null matters.

T__T