Re: emscripten
On Wed, Dec 15, 2010 at 3:16 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com... > > >With my own computer, there are things I can do to prevent that. With > > webapps I'm 100% reliant on someone else: there isn't a damn thing I can > > do. > > > > But what about your group-think lemming mother? > > > > Unfortunately, she leaves the security and accessibility of her data at the > mercy of MS's web monkeys. So tell me how exactly that's supposed to be an > improvement over just keeping it on her local system? Yes, either way there > are possible security risks. But there isn't a chance in hell a webapp can > actually be considered better in that regard. > > > This is what you're not seeing. Web applications have zero-install, zero-configuration, and while you've pointed out that people whine when they change, those same people are already using them and continue to use them anyway. Why? Ease of use. The sad truth is that most computer users know next to nothing about how their computer works, and when given the choice between a fully featured email client they have to set up properly and a ready-to-go webmail system like Gmail/Hotmail, the choice seems fairly obvious. The same average user would probably say their data is safer with Microsoft than on their computer, simply because Microsoft has experts working to maintain privacy and backup, while the user might not even understand how he/she would go about that sort of thing. Now, from the inside that we see as developers, the picture isn't as pretty, but still. Computers and software are designed and created by the elite for both the elite and the non-elite. When the non-elite have a choice between doing it themselves and trusting it to the elite, the rise of web applications shows that they will generally choose the elite. For power users, this choice just isn't the same.
Re: A Benchmark for Phobos Sort Algorithm
On Wednesday 15 December 2010 22:44:39 Sean Kelly wrote: > Nick Voronin Wrote: > > On Thu, 16 Dec 2010 04:52:53 +0300, Craig Black > > wrote: > > > > And here is why. Quicksort is quite famous for being O(n^2) worst case > > (for sorted data). Your straightforward, simple (and less generic, I > > must say) implementation shines for random data, but performs terribly > > for ordered data. Phobos' sort isn't really plain quicksort so it is > > slower for random data (yet still of the same complexity as your code > > best case), but it is pretty fast for ordered data. > > A tweaked version of the Tango sort routine is slower for random data but > roughly 25% faster for ordered data. The straightforward quicksort is > about 30 times slower though. All in all, the Phobos sort routine seems > to do quite well. I'd like to see a test with other types of contrived > worst-case data though. It would be nice to get a fairly extensive lists of types to sort with a variety of values and number of values of those types and set up an extensive set of benchmarking tests. Heck, such a set of types and collections of those types could be a useful benchmarking tool for a variety of algorithms. Then we'll have a good base to build from and compare to. If we're going to tweak algorithms for efficiency, we're going to want to some thorough tests so that we're sure that any tweaks are actually overall improvements. It's easy to find cases which do poorly for a particular algorithm. It can even be fairly easy to tweak an algorithm to improve that particular case. But it's not so easy to be sure that that tweak is actually an overal improvement. - Jonathan M Davis
Re: Fast string search
Leonid Volnitsky: > 36 - is correct. When not found volnitsky() return pointer to next byte > after > last byte of s1 (same as std::search()). Look better at the code, the main contains three writeln(). The first 36 it prints is the length of the s1 string, that's obviously correct. The other two writeln show a wrong result (it may be just a C++==>D translation error of mine). Bye, bearophile
Re: A Benchmark for Phobos Sort Algorithm
Nick Voronin Wrote: > On Thu, 16 Dec 2010 04:52:53 +0300, Craig Black > wrote: > > And here is why. Quicksort is quite famous for being O(n^2) worst case > (for sorted data). Your straightforward, simple (and less generic, I must > say) implementation shines for random data, but performs terribly for > ordered data. Phobos' sort isn't really plain quicksort so it is slower > for random data (yet still of the same complexity as your code best case), > but it is pretty fast for ordered data. A tweaked version of the Tango sort routine is slower for random data but roughly 25% faster for ordered data. The straightforward quicksort is about 30 times slower though. All in all, the Phobos sort routine seems to do quite well. I'd like to see a test with other types of contrived worst-case data though.
Re: Fast string search
36 - is correct. When not found volnitsky() return pointer to next byte after last byte of s1 (same as std::search()). 24 - I don't know D to tell what it is (use of ptr past end of s1?)
Re: A Benchmark for Phobos Sort Algorithm
On Thu, 16 Dec 2010 04:52:53 +0300, Craig Black
wrote:
On my computer, the custom sort algorithm performs almost 40 percent
better than the Phobos one. I provided this in case anyone wanted to
improve the phobos algorithm. I only benchmarked this with DMD. I
would be curious to know how it performs with GDC.
Benchmarks! Love them. They will show whatever you want them to. For
example I see that customSort is of different complexity and much slower
than phobos' sort. =)
void quickSort(A, alias L)(A a, int p, int r)
{
if (p >= r) return;
if(p + 7 > r) return insertionSort!(A, L)(a, p, r);
auto x = a[r];
And here is why. Quicksort is quite famous for being O(n^2) worst case
(for sorted data). Your straightforward, simple (and less generic, I must
say) implementation shines for random data, but performs terribly for
ordered data. Phobos' sort isn't really plain quicksort so it is slower
for random data (yet still of the same complexity as your code best case),
but it is pretty fast for ordered data.
I wonder though, what exactly makes std.algorithm.sort twice slower for
random data... overhead of ranges? more complex logic/more code?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Binary heap method to update an entry.
Hi all, I uploaded [1] a patch for std.container to use BinaryHeap as a priority queue. For the latter one it is often necessary to change a value (often called decreaseKey in a MinHeap). For example, Dijkstra's shortest path algorithm would need such a method. My implementation expects that the user calls the "update" method after changing the entry in the underlying store. My method works for value-decrease and -increase, but one might want to split this functionality into two methods for efficiency reasons. But I thought it'll be better, because one can change the MaxHeap to be a MaxHeap by changing the template alias parameter, but this wouldn't change the method names :-) The patch is against current svn trunk. [1] http://xammy.xammy.homelinux.net/files/BinaryHeap-PriorityQueue.patch
Re: emscripten
> there's no integration with the external environment But it is an advantage at the same time as it's a weakness. The advantage is, I can read and use gmail or google docs anywhere, firewall or not. I could sit here at home, open an openoffice doc, write in it, save it. Then tomorrow go to work, open open office and bitch and scream about why the doc I made last night at home isn't in my recent docs list!! ZOMG!!! I *LOATHE* Open Office! I can't do the simplest thing! But, no, I recognize the limitations of the different mediums, and rather than look at what is not exactly the same as what I'm used to, I can see what it does that I've not been able to do before. If you'd asked me 1 year ago about javascript, I would have laughed and said no way I would want to use that crap. I've learned to think otherwise since. If you go looking for problems, you're going to find them. To me, it simply indicates inflexibility on your part. Which is fine, like I said, the world doesn't care about your inability to adapt and see new possibilities. It's just, the strength of the emotional response in this thread has been kind of revealing. Mike On Wed, Dec 15, 2010 at 9:20 PM, Adam D. Ruppe wrote: > > So much hate because you can't middle-click paste. > > It's illustrative of a bigger overall problem: there's no integration with > the > external environment; no use of native capabilities, ignoring user system > setups, > and not even integration with other web apps. With a Windows program, you > can set > up a user theme. Well behaved programs will honor your colors, layouts, > etc. > > One of the reasons I stick to my old Konqueror is it uses the website icon > and > title in my system taskbar and tries to honor my user settings. Most > browsers > don't even try that, but even with konq, the integration is quite poor. > > While web apps could, in theory, get some consistency with user defined > stylesheets, in practice, this would just break sites, since they are all > so > accustomed to being independent. > > It's just like DOS. Except DOS apps could actually /use/ the hardware > available to > them... >
Re: emscripten
> So much hate because you can't middle-click paste. It's illustrative of a bigger overall problem: there's no integration with the external environment; no use of native capabilities, ignoring user system setups, and not even integration with other web apps. With a Windows program, you can set up a user theme. Well behaved programs will honor your colors, layouts, etc. One of the reasons I stick to my old Konqueror is it uses the website icon and title in my system taskbar and tries to honor my user settings. Most browsers don't even try that, but even with konq, the integration is quite poor. While web apps could, in theory, get some consistency with user defined stylesheets, in practice, this would just break sites, since they are all so accustomed to being independent. It's just like DOS. Except DOS apps could actually /use/ the hardware available to them...
Re: emscripten
So much hate because you can't middle-click paste. Swearing and AAAggghhing, "loathing", etc. It's childish and hard to take such attitudes seriously. The world moves on and doesn't care that you can't adapt to the simplest of things. On Wed, Dec 15, 2010 at 5:20 PM, Adam D. Ruppe wrote: > Tangentially related to this thread. I just went back to my work to-do > list, which > the rest of the team puts up on a Google Doc. > > I *loathe* Google Docs, for a lot of reasons. But one more: my X11 > selection > doesn't work. This is with Firefox 3.6. > > In Linux, with most programs, you can select text, then middle click in a > text > input box to instantly paste it. This includes standard html text in the > web browsers. > > ... but not Google Docs text. It highlights in a weird looking color, not > matching > the rest of my system. It lags as I drag or scroll. And it doesn't update > the X > selection, so when I middle click out of habit... the wrong thing happens. > arrg! > > > Those javascript things never pay attention to details, and even those that > do > don't know the quirks of platforms or individual user setup, and even if > they do > know, there's nothing they can do about it! > > > Now, if they just output a standard html document, these details would be > handled > properly. Firefox itself knows it is a Linux program, has access to the > Linux > APIs, and manages them somewhat well. > > Or if it was a standard doc, I could open it in my other browser and maybe > it'd do > a better job. > > But nope, open it in my no-script Konqueror 3.5, and it just says > > === > Google Docs is not supported in your browser. Learn more Dismiss > === > > And a blank screen under it. I can't even view the text, despite it being > just > text. Fucking garbage. >
A Benchmark for Phobos Sort Algorithm
On my computer, the custom sort algorithm performs almost 40 percent better
than the Phobos one. I provided this in case anyone wanted to improve the
phobos algorithm. I only benchmarked this with DMD. I would be curious to
know how it performs with GDC.
-Craig
import std.stdio;
import std.random;
import std.algorithm;
static bool less(T)(T a, T b) { return a < b; }
void insertionSort(A, alias L)(A a, int low, int high)
{
for(int i = low; i <= high; i++)
{
int min = i;
for(int j = i + 1; j <= high; j++)
if(L(a[j], a[min])) min = j;
swap(a[i], a[min]);
}
}
void quickSort(A, alias L)(A a, int p, int r)
{
if (p >= r) return;
if(p + 7 > r) return insertionSort!(A, L)(a, p, r);
auto x = a[r];
int j = p - 1;
for (int i = p; i < r; i++)
{
if (L(x, a[i])) continue;
swap(a[i], a[++j]);
}
a[r] = a[j + 1];
a[j + 1] = x;
quickSort!(A, L)(a, p, j);
quickSort!(A, L)(a, j + 2, r);
}
void customSort(T)(T[] a)
{
quickSort!(T[], less!T)(a, 0, a.length-1);
}
ulong getCycle() { asm { rdtsc; } }
ulong bench1(double[] vals)
{
ulong startTime = getCycle();
double[] v;
v.length = vals.length;
for(int i = 0; i < 100; i++)
{
for(int j = 0; j < v.length; j++) v[j] = vals[j];
sort(v);
}
return getCycle() - startTime;
}
ulong bench2(double[] vals)
{
ulong startTime = getCycle();
double[] v;
v.length = vals.length;
for(int i = 0; i < 100; i++)
{
for(int j = 0; j < v.length; j++) v[j] = vals[j];
customSort(v);
}
return getCycle() - startTime;
}
void main()
{
Mt19937 gen;
double[] vals;
vals.length = 1000;
for(int i = 0; i < vals.length; i++) vals[i] = uniform(0.0,1000.0);
ulong time1, time2;
for(int i = 0; i < 100; i++)
{
time1 += bench1(vals);
time2 += bench2(vals);
}
writeln("Sorting with phobos sort: ", time1/1e5);
writeln("Sorting with custom quickSort: ", time2/1e5);
writeln(100.0 * (time1-time2) / time1, " percent faster");
}
Re: Infinite loop using phobos sort
On 12/15/10 7:15 PM, Nick Voronin wrote:
On Thu, 16 Dec 2010 03:11:40 +0300, Craig Black
wrote:
When I try to use Phobos to sort my custom Array, it goes into an
infinite loop. I suspect I did something wrong with my Range struct.
Does anyone see an obvious flaw here?
bordercase
this(ref Array!T array)
{
if(array.empty()) return;
start = &array.front();
end = &array.back();
end points to last actual element
Perfect, I logged on to answer the same. Tip: always use begin = first
element, end = past-last element.
Andrei
Re: Infinite loop using phobos sort
On Thu, 16 Dec 2010 03:11:40 +0300, Craig Black
wrote:
When I try to use Phobos to sort my custom Array, it goes into an
infinite loop. I suspect I did something wrong with my Range struct.
Does anyone see an obvious flaw here?
bordercase
this(ref Array!T array)
{
if(array.empty()) return;
start = &array.front();
end = &array.back();
end points to last actual element
}
this(T *_start, T *_end)
{
start = _start;
end = _end;
same
}
Range opSlice(int a, int b) { return Range(start+a, start+b); }
in opSlice second index points _after_ last element you want. a[0..1] --
range of length 1. You need to fix b by -1.
I wonder what kind of assert would catch this one...
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
Infinite loop using phobos sort
When I try to use Phobos to sort my custom Array, it goes into an infinite
loop. I suspect I did something wrong with my Range struct. Does anyone
see an obvious flaw here?
-Craig
import std.stdio;
import std.random;
import std.conv;
import std.algorithm;
import std.c.stdlib;
struct Array(T)
{
public:
this(int length) { resize(length); }
this(T[] a) { append(a); }
this(this)
{
if(!base.array) return;
ArrayBase!T old;
old = base;
base.array = null;
reserve(old.length(), old.length());
copyData(old);
old.array = null;
}
void clear() { base.clear(); }
void resize(int sz)
{
assert(sz >= 0);
if(sz == 0) return clear();
if(!base.array) reserve(sz, sz);
*base.lengthPtr() = sz;
}
void reserve(int capacity, int length)
{
assert(length <= capacity);
if(capacity == 0) return clear();
ArrayBase!T old;
if(base.array)
{
if(base.capacity() >= capacity) return;
old.array = base.array;
base.array = null;
}
base.array = cast(ubyte*)malloc(capacity*T.sizeof+8);
*base.lengthPtr() = length;
*base.capacityPtr() = capacity;
for(int i = 0; i < capacity; i++) emplace!T(base.data()+i);
if(old.array) copyData(old);
}
int length() const { return base.length(); }
int capacity() const { return base.capacity(); }
bool empty() const { return base.array == null; }
ref T at(int i)
{
assert(!empty(), "Array of " ~ T.stringof ~ ": index " ~ to!string(i) ~
" out of bounds of empty array");
assert(i >= 0 && i < length(), "Array of " ~ T.stringof ~ ": index " ~
to!string(i) ~ " out of bounds 0-" ~ to!string(length()-1));
return *cast(T*)(base.array+8+i*T.sizeof);
}
ref const T at(int i) const
{
assert(!empty(), "Array of " ~ T.stringof ~ ": index " ~ to!string(i) ~
" out of bounds of empty array");
assert(i >= 0 && i < length(), "Array of " ~ T.stringof ~ ": index " ~
to!string(i) ~ " out of bounds 0-" ~ to!string(length()-1));
return *cast(T*)(base.array+8+i*T.sizeof);
}
const ref T opIndex(int i) const { return
*cast(T*)(base.array+8+i*T.sizeof); }
void opIndexAssign(T t, int i) { at(i) = t; }
void opIndexAssign(ref T t, int i) { at(i) = t; }
void opAssign(ref const Array!T array)
{
copy(array);
}
void opAssign(T[] array)
{
int len = array.length;
resize(len);
for(int i = 0; i < len; i++) at(i) = array[i];
}
void copy(ref const Array!T array)
{
if(array.empty()) return clear();
int len = array.length();
reserve(len, len);
for(int i = 0; i < len; i++) at(i) = array[i];
}
void opOpAssign(string op, A...)(A a) if(op == "~")
{
appendComposite(a);
}
ref T front() { return at(0); }
const ref T front() const { return at(0); }
ref T back() { return at(length()-1); }
const ref T back() const { return at(length()-1); }
ref T appendOne()
{
int sz = length();
int sp = capacity();
if(sp > sz) (*base.lengthPtr())++;
else
{
sz++;
sp = max(2, sp+sp/2, sz);
reserve(sp, sz);
}
return back();
}
void append(A...)(A a)
{
static if(a.length == 1 && (is(typeof(a[0]) == Array!T) ||
is(typeof(a[0]) == T[])))
{
appendComposite(a[0]);
} else {
appendTuple(a);
}
}
void appendTuple(A...)(A a)
{
foreach(x; a) appendOne() = x;
}
void appendComposite(A)(A a)
{
int prevLen = length();
int alen = a.length;
resize(prevLen + alen);
T *d = base.data();
T *e = &a[0];
for(int i = 0; i < alen; i++) d[i+prevLen] = e[i];
}
static struct Range
{
public:
this(ref Array!T array)
{
if(array.empty()) return;
start = &array.front();
end = &array.back();
}
this(T *_start, T *_end)
{
start = _start;
end = _end;
}
T* start, end;
bool empty() const { return end < start; }
void popFront() { start++; }
void popBack() { end--; }
ref T front() { return *start; }
ref T back() { return *end; }
@property size_t length() { return end-start+1; }
ref T opIndex(int i) { return start[i]; }
Range opSlice(int a, int b) { return Range(start+a, start+b); }
Range save() { return this; }
}
Range opSlice() { return Range(this); }
Range opSlice(int a, int b) { return Range(base.data()+a,
base.data()+b); }
void sort(alias L = less!T)()
{
quickSort!(T*, L)(base.data(), 0, length()-1);
}
private:
static struct ArrayBase(T)
{
public:
~this() { clear(); }
void clear()
{
if(!array) return;
int cap = capacity();
T *d = data();
for(int i = 0; i < cap; i++) .clear(d[i]);
free(array);
}
int length() const { return array ? *lengthPtr() : 0; }
int capacity() const { return array ? *capacityPtr() : 0; }
int* lengthPtr() const { return cast(int*)(array); }
int* capacityPtr() const { return cast(int*)(array+4); }
T* data() const { return cast(T*)(array+8); }
ubyte* array;
}
ArrayBase!T base;
void copyData(ref ArrayBase!T array)
{
int copyLen = min(length, array.length());
T *a = base.data();
T *b = array.data();
for(int i
Re: Fast string search
Leonid Volnitsky:
> Thanks for bug report! Code is very new.
You are welcome :-)
> Bug manifests itself when substring is in 0 position.
> Fix:
I may not understand the purpose of the function, but after your fix this code:
void main() {
string s1 = "hello, how are you? I'm well, thanks";
writeln(s1.length);
string s2 = "wello";
auto ptr = volnitsky(s1, s2);
writeln(ptr - s1.ptr);
writeln(s1[ptr - s1.ptr .. $]);
}
Prints:
36
24
well, thanks
But "wello" is not present in the s1 string, so returning 24 is not what I
desire...
Bye,
bearophile
Re: write, toString, formatValue & range interface
I guess the discussion on bugzilla strayed quite far from original point, so I'll answer here. I don't understand you point about "Now if we bundle data and Range interface together all kind of funny things happen." A type that implement a range always holds data, usually provides many other features that just range/iteration, Look into std/container.d. Containers hold data, Ranges traverse data (and are separate struct types). Think, how would you generally hold data in something which exhaust itself on iteration? There is save(), but then again it may not be there :) And it creates _new_ range object. See, all kind of complications from mixing things, when they are intended to simplify programing. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Why Ruby?
Ary Borenszweig:
> D should provide a yield keyword that basically rewrites the body of the
> method into the first code. What's that "if (result) break;"? That's
> showing the implementation of foreach. Why do I have to rememebr the
> result of dg? What's that? What if I forget it? I just want to yield two
> elements :-(
Time ago I have asked for the "yield" syntax&semantics of Python in D too. It's
just syntax sugar for opApply. A syntax like:
yield(int) squares(int n) {
foreach (i; 0 .. n)
yield i * i;
}
Bye,
bearophile
Re: Why Ruby?
Wed, 15 Dec 2010 16:47:01 -0600, Andrei Alexandrescu wrote:
> On 12/15/10 4:42 PM, retard wrote:
>> Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:
>>
>>> On 12/15/10 4:18 PM, retard wrote:
Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:
> Array(1, 2, 3, 4, 5).sortWith(_> _)
The first instance of _ (from left to right) is replaced with the
first element of the parameter tuple, the second with second element,
etc.
This is actually very useful since many lambdas only use 1-2
parameters. It has its limitations. For example referring to the same
parameter requires a named parameter or some other hack. Combined
with Haskell style partial application this allows stuff like:
Array(1, 2, 3, 4, 5).foreach { println }
Array(1, 2, 3, 4, 5).filter(2<)
>>>
>>> For short lambdas I prefer Phobos' convention of using "a" and "b",
>>> e.g. "2< a" or "a< b". Since it's a string, "_< _" would have been
>>> usable with Phobos too but I wouldn't like such a change.
>>
>> I haven't have time to test this (still using D1 + Tango), but these
>> magical 'a' and 'b' make me wonder whether there are any namespace
>> issues. Can you refer to symbols defined in the current module or in
>> the Phobos module the collection function is declared? Do the 'a' and
>> 'b' shadow some other instances of 'a' and 'b'?
>
> There are no hygiene issues, but lookup is limited to the modules
> included in std.functional. That's goes well with the charter of short
> lambdas - I mean, they are short :o).
Ha, that's the thing I was after. Hopefully it's well documented. No need
to answer, I can check it myself.
Re: Why Ruby?
On 12/15/10 4:42 PM, retard wrote:
Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:
On 12/15/10 4:18 PM, retard wrote:
Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:
Array(1, 2, 3, 4, 5).sortWith(_> _)
The first instance of _ (from left to right) is replaced with the first
element of the parameter tuple, the second with second element, etc.
This is actually very useful since many lambdas only use 1-2
parameters. It has its limitations. For example referring to the same
parameter requires a named parameter or some other hack. Combined with
Haskell style partial application this allows stuff like:
Array(1, 2, 3, 4, 5).foreach { println }
Array(1, 2, 3, 4, 5).filter(2<)
For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
"2< a" or "a< b". Since it's a string, "_< _" would have been usable
with Phobos too but I wouldn't like such a change.
I haven't have time to test this (still using D1 + Tango), but these
magical 'a' and 'b' make me wonder whether there are any namespace
issues. Can you refer to symbols defined in the current module or in the
Phobos module the collection function is declared? Do the 'a' and 'b'
shadow some other instances of 'a' and 'b'?
There are no hygiene issues, but lookup is limited to the modules
included in std.functional. That's goes well with the charter of short
lambdas - I mean, they are short :o).
Andrei
Re: For whom is
(Catching some older posts I have lost in my absence) Andrei Alexandrescu: > * in is a vestige now used for const, and a syntactic component of contracts It's a (nearly) duplicated way to do something, so it may be removed. > * lazy sucks I don't remember why. > We stand to lose the ability to express designs clearly and in good > detail whichever of the above we eliminate. What do we take away? I don't mind having many words to specify my desired semantics to the compiler, so I don't mind twenty attributes. But their purpose and semantics must be clean, each one of them must do just one clear thing and to it well. But I agree that "auto ref" is a bit confusing, I prefer a single keyword, like autoref or auto_ref, or @autoref, or some other single word. Bye, bearophile
Re: Why Ruby?
Wed, 15 Dec 2010 16:33:43 -0600, Andrei Alexandrescu wrote:
> On 12/15/10 4:18 PM, retard wrote:
>> Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:
>>> Array(1, 2, 3, 4, 5).sortWith(_> _)
>>
>> The first instance of _ (from left to right) is replaced with the first
>> element of the parameter tuple, the second with second element, etc.
>>
>> This is actually very useful since many lambdas only use 1-2
>> parameters. It has its limitations. For example referring to the same
>> parameter requires a named parameter or some other hack. Combined with
>> Haskell style partial application this allows stuff like:
>>
>> Array(1, 2, 3, 4, 5).foreach { println }
>>
>> Array(1, 2, 3, 4, 5).filter(2<)
>
> For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
> "2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
> with Phobos too but I wouldn't like such a change.
I haven't have time to test this (still using D1 + Tango), but these
magical 'a' and 'b' make me wonder whether there are any namespace
issues. Can you refer to symbols defined in the current module or in the
Phobos module the collection function is declared? Do the 'a' and 'b'
shadow some other instances of 'a' and 'b'?
Re: Why Ruby?
On 12/15/10 4:18 PM, retard wrote:
Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:
Array(1, 2, 3, 4, 5).sortWith(_> _)
The first instance of _ (from left to right) is replaced with the first
element of the parameter tuple, the second with second element, etc.
This is actually very useful since many lambdas only use 1-2 parameters.
It has its limitations. For example referring to the same parameter
requires a named parameter or some other hack. Combined with Haskell
style partial application this allows stuff like:
Array(1, 2, 3, 4, 5).foreach { println }
Array(1, 2, 3, 4, 5).filter(2<)
For short lambdas I prefer Phobos' convention of using "a" and "b", e.g.
"2 < a" or "a < b". Since it's a string, "_ < _" would have been usable
with Phobos too but I wouldn't like such a change.
Andrei
Re: improvement request - enabling by-value-containers
Kagamin wrote: > What I understand from description, the algorithm consists of several > steps of joining. Did you try to join in place? Can't remember, I had to move and copy some sets around and test which set of sets is the best in some steps or something like that, however, it is somehow irrelevant.
Re: [OT] Browsers (was: Re: emscripten)
On Wed, Dec 15, 2010 at 3:58 PM, Vladimir Panteleev < vladi...@thecybershadow.net> wrote: > I think I had some other problems as well though I >> don't remember exactly what. I posted my impressions of it on this NG, you >> can probably just search the NG for posts from "Sabalausky" with "opera" >> in >> the text. >> > > Hmm, can't find anything (neither in my archives, nor on Google)... This looks like the relevant post by Nick: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.announce&article_id=19476 jcc7
Re: Why Ruby?
Wed, 15 Dec 2010 22:23:35 +0100, Jacob Carlborg wrote:
> On 2010-12-14 22:04, Nick Sabalausky wrote:
>> "Jacob Carlborg" wrote in message
>> news:ie8f5f$o6...@digitalmars.com...
>>>
>>> Probably not, but, for example, Scala allows very compact delegate
>>> literals:
>>>
>>> Array(1, 2, 3, 4, 5).select(_> 3).collect(_ * _)
>>>
>>> Or more verbose:
>>>
>>> Array(1, 2, 3, 4, 5).select((x) => x> 3).collect((x, y) => x * y)
>>>
>>> I'm not 100% sure I that the syntax is correct.
>>>
>>>
>> I'd be surprised if the first one is correct, because that "collect(_ *
>> _)" would seem highly limited (how would you use the same value twice,
>> or use just the second value, or use them in reverse order?).
>
> I guess for anything more complicated you would have to use the =>
> syntax. BTW, I just verified that this works:
>
> Array(1, 2, 3, 4, 5).sortWith(_ > _)
The first instance of _ (from left to right) is replaced with the first
element of the parameter tuple, the second with second element, etc.
This is actually very useful since many lambdas only use 1-2 parameters.
It has its limitations. For example referring to the same parameter
requires a named parameter or some other hack. Combined with Haskell
style partial application this allows stuff like:
Array(1, 2, 3, 4, 5).foreach { println }
Array(1, 2, 3, 4, 5).filter(2 <)
Re: Why Ruby?
"piotrek" wrote in message news:ieb3ik$1ri...@digitalmars.com... > On Wed, 15 Dec 2010 02:53:40 -0500, Nick Sabalausky wrote: > >> "lurker" wrote in message >> news:ie8rc3$27l...@digitalmars.com... >>> Nick Sabalausky Wrote: >>> "piotrek" wrote in message news:ie8fu9$ej...@digitalmars.com... > On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote: >> By the way, I couldn't stop cringing at the distasteful, >> male-centric sexual jokes that the talk is peppered with. Wonder if >> there was any woman in the audience, and how she might have felt. >> And this is not a ghetto rant - it's the keynote of a major Ruby >> conference! (And I'm definitely not a prude.) Am I alone in >> thinking that this is not what our metier should evolve into? >> >> >> Andrei > > You're definitely not. No matter how strong pressure is, I stand and > fight against common acceptance for female humiliation. It's so sad > to me how many think they're real men while treating women as a > things they can freely abuse. > > Didja hear the one about the blonde who couldn't find her pencil? >>> >>> I have a bad sense of humor, but what is this if I'm trolling? >> >> Heh. It's me being an ass :) >> >> But seriously, I'm not flaming anyone here, and really taking a >> round-about way to point out that there's too much "inventing things to >> be offended about" going on in the world. I still haven't looked at the >> video, so maybe some of the things really were worse than the example >> Andrei mentioned or the joke I referenced above, but *if* these things >> are the sorts of things that piotrek and Andrei find "offensive to >> women", then I'd have to call a big "bullshit, this is just inventing >> blatant assumptions and then getting offended by them". > > Firstly I apologize Andrei if I put him in bad light after hijacking his > sub-thread > and then using it to add some personal opinion. Secondly I was referring > to > bigger picture of society and not only this video. And still I don't agree > to > "tolerate"* behavior which is based on so called "freedom". Because all > you do > has its consequence and interacts with "freedom" of other people and vice > versa. Of course appropriate action should be used not exaggerated ones. > And I had a peaceful intercommunication on my mind when speaking about > fighting ;) I can say as a Christian that respect for dignity goes along > with love. > But your choice. And in the world the weak ones are abused all the time. > I couldn't live pretending I don't see it. So one way is to give my > opinion. Not > don't giving a shit. > Yea, it's entirely possible that we have completely different sorts of things in mind when you're talking about "offensive" and when I'm talking about "not offensive". I'll admit I was being a bit of an ass by referencing that joke as an attempt to guage whether or not it was the sort of thing you would find offensive. Should have just come out and asked "Is this the sort of thing you mean?" Feel free not to answer that though, I don't think either of us are feeling particularly inclined to end up in a heated debate about it today.
Re: New syntax for string mixins
"Jonathan M Davis" wrote in message
news:mailman.1035.1292441722.21107.digitalmar...@puremagic.com...
> On Wednesday, December 15, 2010 11:27:47 Jacob Carlborg wrote:
>>
>> That was my idea as well, that
>>
>> @get_set("int", "bar");
>>
>> could be translated into
>>
>> mixin(get_set("int", "bar")); just like
>>
>> just like scope statements are translated into try/catch/finally.
>
> Honestly, I don't see much gain in using @ rather than mixin(). It's a
> little
> less typing, but that's it.
It does seem like a small difference, just replacing "mixin" with "@" and
removing one layer of parens. But I think that extra layer of parens, minor
as it seems, makes a big difference in the readability (and "typeability")
of mixin invocations. Those extra parens do get to be a real bother, major
visual noise at least to my eyes.
> And it precludes stuff like mixin("lhs " ~ op ~ "
> rhs") like happens all the time in overloaded operator functions.
>
I don't see why these shouldn't work:
@"int foo;";
return @("lhs " ~ op ~ " rhs");
At least with just the "@" part of the proposal. Maybe the delegate thing
might make it tricker, I dunno.
Re: [OT] Browsers (was: Re: emscripten)
On Wed, 15 Dec 2010 23:45:49 +0200, Nick Sabalausky wrote: Opera's "extentions" aren't extensions at all but widgets that have little-to-no connection with the web-browsing function. Opera 11 supposedly introduces support for real extensions, though after browsing the extension gallery[1] I haven't noticed anything I'd want to use. They seem to be pimped-up UserScripts, nothing which allows actually modifying the UI (possibly a good thing - a customized Firefox looks like a Frankenbrowser with all the toolbars and buttons). Opera has also supported UserScripts for some time. I think I had some other problems as well though I don't remember exactly what. I posted my impressions of it on this NG, you can probably just search the NG for posts from "Sabalausky" with "opera" in the text. Hmm, can't find anything (neither in my archives, nor on Google)... well, considering that a few years ago someone from Opera Software said that "The best browser in the world doesn't need extensions", I'd say that quite a few things changed ;) [1]: https://addons.opera.com/addons/extensions/ -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: emscripten
David Nadlinger:
> You are confusing the web application and the data it operates on here
The thing is a web application is built on top of its data, almost
literally. Javascript manipulates an HTML document, and you need
to give it one to get started, even if it is an empty document.
If you give the javascript a usable HTML document as its starting
point, you can have your app with scripts available, and still have
the document when the scripts aren't available.
Let me do an example app, hopefully it won't be butchered too
much in transport.
Output this from your server side program:
Thread Participants
AdamRuppe
DavidNadlinger
If you go to that page in any browser, from Lynx up, you have a usable table of
data to look at.
Now add editing.js to it:
=
function makeEditable() {
var input = document.createElement("input");
input.value = this.innerHTML;
this.onclick = null;
input.onblur = function() {
post("/update-cell", { "row" : getRow(this), "column" :
getColumn(this),
"value" : input.value }, function(response) {
this.onclick = makeEditable;
this.innerHTML = response;
});
}
this.innerHTML = "";
this.appendChild(input);
}
window.onload = function() {
var items = document.getElementsByTagName("td");
for(var a = 0; a < items.length; a++) {
var item = items[a];
item.onclick = makeEditable;
}
}
===
Now, if you do have a browser with scripting capabilities, this runs through the
already usable document and makes it more usable, by adding the inline editing
capability. It's now a primitive web app, while still being a usable web page to
browsers without all the fancy capabilities.
(Note that I wrote this on the fly here, without testing. I don't know if it
would
actually run correctly or not. Another thing that sucks about the browser
platform... it's not complex code, but I have no confidence in it without
testing
across them all.)
This is all I'm asking for with the "works in Lynx" thing. Start with a regular
webpage and build up. You are still on the web, still accessible from all these
browsers. You should at least follow the basic html standards well enough so
they
aren't completely screwed and left behind.
How much do you build up? I say not too much, since before long you'll hit a
wall
where the browser just sucks too much. But that's a separate concern from
graceful
degradation.
Remember, the practical benefit to this isn't working for Lynx users, but for
the
~20% of today's market with noscript installed, or stuck on IE6, or on
underpowered mobile phones, etc.
Or if you take a step up, depending on HTML5 stuff even locks out IE7 and some
IE8, Firefox, and Opera users. But if your site is still built on a solid
foundation, they won't be left behind either.
Cross-post from druntime: Mixing GC and non-GC in D. (AKA, "don't touch GC-references from DTOR, preferably don't use DTOR at all")
Cross-posting after request on the druntime list:
--
Hi,
DISCLAIMER: I'm developing for D1/Tango. It is possible these issues
are already resolved for D2/druntime. If so, I've failed to find any
information about it, please do tell.
Recently, I've been trying to optimize my application by swapping out
some resource allocation (file-descriptors for one) to
reference-counted allocation instead of GC. I've hit some problems.
Problem
===
Basically, the core of all my problems is something expressed in
http://bartoszmilewski.wordpress.com/2009/08/19/the-anatomy-of-reference-counting/
as "An object’s destructor must not access any garbage-collected
objects embedded in it.".
This becomes a real problem for various allocation-schemes, be it
hierarchic allocation, reference counting, or a bunch of other custom
resource-schemes. _It renders the destructor of mostly D useless for
anything but mere C-binding-cleanup._
Consequence
===
For the Reference-Counted example, the only working solution is to
have the counted object malloced, instead of GC-allocated. One could
argue that "correct" programs with reference-counting should do the
memory management completely explicit anyways, and yes, it's largely
true. The struct-dtor of D2 makes the C++ "smartptr"-construct
possible, making refcount-use mostly natural and automatic anyways.
However, it also means, that the refcounted object itself, can never
use GC-allocated structures, such as mostly ANYTHING from the stdlib!
In effect, as soon as you leave the GC behind, you leave over half of
all useful things of D behind.
This is a real bummer. What first attracted me to D, and I believe is
still the one of the key strengths of D, is the possibilities of
hybrid GC/other memory-schemes. It allows the developer to write up
something quick-n-dirty, and then improve in the places where it's
actually needed, such as for open files, or gui-context-handles, or
other expensive/limited resources.
As another indication that is really is a problem: In Tango, this have
lead to the introduction of an additional destructor-type method
"dispose", which is doing AFAICT what the destructor should have done,
but is only invoked for deterministic destruction by "delete" or
scope-guards. IMO, that can only lead to a world of pain and
misunderstandings, having two different "destructors" ran depending on
WHY the object were destroyed.
Proposed Solution
=
Back to the core problem "An object’s destructor must not access any
garbage-collected objects embedded in it.".
As far as I can tell (but I'm no GC expert), this is a direct effect
of the current implementation of the GC, more specifically the loop
starting at
http://www.dsource.org/projects/druntime/browser/trunk/src/gc/gcx.d#L2492.
In this loop, all non-marked objects gets their finalizers run, and
immediately after, they get freed. If I understand the code right,
this freeing is what's actually causing the problems, namely that if
the order in the loop don't match the order of references in the freed
object (which it can't, especially for circular references), it might
destroy a memory-area before calling the next finalizer, attempting to
use the just freed reference.
Wouldn't it instead be possible to split this loop into two separate
loops, the first calling all finalizers, letting them run with all
objects still intact, and then afterwards run a second pass, actually
destroying the objects? AFAICT, this would resolve the entire problem,
allowing for much more mixed-use of allocation strategies as well as
making the destructor much more useful.
Alternate Solution
==
On the druntime-list, Vladimir suggested something similar could be
achieved by simply creating a custom allocator which automatically
adds it's pool to the GC-root. This would solve my problems
satisfactory, and it is probably what I'm going to do for my immediate
problem.
I believe (again, no GC-expert) it may even have the advantage of
relieving some pressure from the GC, in terms of objects it really
has to track.
However, it has the disadvantages that,
* the GC can no longer be used as a "fallback/safety net", putting
extra burden of correctness on the programmer (perhaps a good thing?)
* destructors on "regular" GC-objects still cannot touch related
objects. I.E. consider the following example. Yes, pretty bad design,
but it's non-obvious why it's invalid, and intuitively not expected to
cause segfaults.
class List {
int count;
class Entry {
this { count++; }
~this { count--; }
}
}
--
I strongly believe the language/runtime should not needlessly lay out
"non-obvious" traps like this for the developer. For a C++-convert it
is quite counterintuitive, and even if you know about it, it's tricky
to work-around.
I think both solutions have their merits, but short of serious
performance-issues with the first proposed solution, I think it's
pre
Re: tail const
Simen kjaeraas wrote:
Andrei Alexandrescu wrote:
On 12/4/10 12:23 PM, Simen kjaeraas wrote:
To expound further on this, I have created the attached module.
Critique wanted.
Looks promising. A few comments.
* For TailXxx you need to handle built-in simple types (int, float...)
to return themselves. Also, structs for which hasIndirections returns
false also return themselves.
Done.
* tailconst_t does not obey Phobos' naming convention. I think it's fine
to use TailConst in spite of the apparent ambiguity.
It adds some .'s:
alias SimpleRange!(.TailConst!T) TailConst;
static if ( !is( T == .TailMutable!T ) ) {
this( SimpleRange.TailImmutable r ) {
Not sure if this is a problem.
* You may want to add more stringent checks for tailconst_t (well
TailConst etc) to make sure it's not bogus - has the same size,
compatible members etc.
I've tried, and it seems adding
static assert( T.sizeof == T.TailConst.sizeof );
does not work (no size yet for forward reference).
Checking that all members are the same type and order is easy and
works. Comparing member names bumped me into bug 5079. Likely related
to the above, seeing as both have to do with unfinished types.
I've also considered a template on the form
mixin tailConst!( SimpleRange, SimpleRange!( Tail!T ) );
or
mixin tailConst!( SimpleRange, Tail!T );
which would automagically define aliases. More work for me, perhaps
less work for users.
This could not define constructors, as overloads from inside template
mixins don't work with overloads outside.
Nobody ever commented on this. Figured I'd poke around with a stick
and see if there were any opinions. IOW: bump.
--
Simen
Re: emscripten
"Michael Stover" wrote in message news:mailman.1038.1292443910.21107.digitalmar...@puremagic.com... > If I provide a spreadsheet program via javascript, why should it have to > work in Lynx? It's not a web page. I'm providing absolutely ZERO content. > It is only behavior, just like Excel is only behavior. If I provide the > same functionality, but only if you use Chrome or Firefox, why is that so > horrible? > First of all, I see no good reason to choose JS to make a spreadsheet app in the first place. The browser (not to mention the JS language itself) is providing absolutely ZERO benefit, and the only thing it can do is get in the way. Secondly, I've never said that I saw any problem with requiring something that actually *is* necessary. Wanna make a web-based photo-editing app? Is think it's a stupid and utterly pointless thing to bother doing, but if you're going to do it, then sure, by all means exclude Lynx and require JS or Flash or something. But if you're going to make, say, a mortgage rate calculator, excluding Lynx or requiring JS makes absolutely no sense whatsoever.
Re: Why Ruby?
On 2010-12-14 22:04, Nick Sabalausky wrote: "Jacob Carlborg" wrote in message news:ie8f5f$o6...@digitalmars.com... Probably not, but, for example, Scala allows very compact delegate literals: Array(1, 2, 3, 4, 5).select(_> 3).collect(_ * _) Or more verbose: Array(1, 2, 3, 4, 5).select((x) => x> 3).collect((x, y) => x * y) I'm not 100% sure I that the syntax is correct. I'd be surprised if the first one is correct, because that "collect(_ * _)" would seem highly limited (how would you use the same value twice, or use just the second value, or use them in reverse order?). I guess for anything more complicated you would have to use the => syntax. BTW, I just verified that this works: Array(1, 2, 3, 4, 5).sortWith(_ > _) You can try it out for yourself at: http://www.simplyscala.com/ The second one reminds me of C#'s lambdas and seems like an excellent solution to the question of what to do with all the noise of the extra curly braces, "return" keyword and trailing semicolon. And given that 1. The => isn't currently a valid D token anyway, and 2. The (x) and (x,y) are already being used perfectly fine by the existing delegate literal syntax, I can't imagine there would be any ambiguity with it in D. I'd be absolutely in favor of adding that to D. In fact, I'd love to see it happen. Just require that the part after "=>" is an expression, accept that the more complex delegates that need statements use the existing syntax (which should be fine since it's only the single-expression-and-nothing-else delegates that are seen as verbose in D), and call it a day. I would also love to have that syntax. I also love the syntax I previously suggested in this thread, there are many to choose of. -- /Jacob Carlborg
Re: Fast string search
Thanks for bug report! Code is very new.
Bug manifests itself when substring is in 0 position.
Fix:
diff --git a/volnitsky.h b/volnitsky.h
index a7dbc1f..62d686d 100644
-- a/volnitsky.h
+++ b/volnitsky.h
@@ -26,7 +26,7 @@ const char* volnitsky(const char* S, const char* Se,
const char* SS, con
// step through text
-for (const char* p = S+step; p <= Se-W_size; p+=step) {
+for (const char* p = S+step-W_size; p <= Se-W_size; p+=step) {
Re: emscripten
"Michael Stover" wrote in message news:mailman.1041.1292446362.21107.digitalmar...@puremagic.com... > >With my own computer, there are things I can do to prevent that. With > webapps I'm 100% reliant on someone else: there isn't a damn thing I can > do. > > But what about your group-think lemming mother? > Unfortunately, she leaves the security and accessibility of her data at the mercy of MS's web monkeys. So tell me how exactly that's supposed to be an improvement over just keeping it on her local system? Yes, either way there are possible security risks. But there isn't a chance in hell a webapp can actually be considered better in that regard.
Re: emscripten
On 12/15/10 9:32 PM, Adam D. Ruppe wrote: For a spreadsheet, I'd output the data in an html table. Now all users can at least view the saved document, with no extra effort from you. You are confusing the web application and the data it operates on here – of course, a spreadsheet application should provide some means to export the tables you created with it in an easily accessible format, e.g. HTML or PDF. But this piece of data created by the exporting routines of the web application is not linked to the application itself per se… Although e.g. whether you want to rely on storing and processing your data (at least partly) on some server cluster you have no control over is an entirely different question worth to be discussed in detail, I don't quite see how lack of graceful degradation can be a valid argument against web applications – or have you ever tried running the latest Microsoft Office suite on Windows 3.11? David
Re: emscripten
> Do you complain that Excel doesn't not "degrade gracefully"? No, because it does the right thing! It works in Win7, Win Vista, Win XP. It's files (if you pick the right format when saving as) can be loaded up in Office 2010, Office 2007, and Office 2003, as well as a million other program. Save as csv and it gracefully degrades all the way down to opening in Notepad! Some desktop apps don't do the right thing though, and those ones suck. So I don't have a mp3 lib installed. I should still be able to save as a .wav! Some apps work like that. Some don't. The ones that don't suck. I used Windows 98 for a long time. A *well written* Windows XP program would work perfectly on XP (including themeing support, etc), and also work almost as well on Win 98, just dropping the new XP features, while doing its best everywhere else.
Re: emscripten
>With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. But what about your group-think lemming mother? On Wed, Dec 15, 2010 at 3:36 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... > > On Wed, Dec 15, 2010 at 2:26 PM, retard wrote: > > > >> Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: > >> > >> > The point was that while Javascript is slow, it's getting fast enough > >> > to be useful. Yes, it's not C. It will never be. But the fact that any > >> > sort of realtime calculations are possible in it is a breakthrough > that > >> > will be reflected in actual application code. Javascript was not > >> > designed to be fast, and honestly, it doesn't need to be fast to fill > >> > it's niche. > >> > >> I'm not getting this. WHY we should use Javascript/HTML5 applications > >> instead. I'm perfectly happy with my existing tools. They work nicely. > It > >> takes years to develop these applications on top of HTML5. I simply have > >> no motivation to use web applications. They have several downsides: > >> > >> - you "rent" the app, you don't "own" it anymore > >> > > > > Many would find that a benefit, as updates are automatic, never need to > > install new versions. > > > > It's not uncommon for newer versions to be worse. Look at Acrobat Reader, > iTunes, and Nero. A lot of people don't want to be forced into updates that > make things worse. My Mom uses Hotmail and has a fit every time they decide > to change everything around (which seems to be quite a lot). She'd be far > happier with something that didn't work that way, but she sticks with it > because she's every bit as much of a group-think lemming as everyone else. > > > > > >> => which leads to: advertisements, monthly fees > >> > > > > Again, benefits galore for some folks. Should I pay $80 to buy the > > software > > and find out if I like it, and another $40 two years later to upgrade, or > > pay $4/month and quit whenever I'm done with it? > > > > Or get freeware/FLOSS and pay nothing and have no ads. And there's > ad-supported desktop software too, so with desktop software you can go > either way. Web apps can't go either way, because there's always the > possibility the owner will pull the plug, and even if they don't, the > ownser > will still have server expenses which will have to get paid somehow. > > >> > >> - worse privacy (do I want some Mark SuckerBerg to spy on my personal > >> life for personal gain) > >> > > > > Same issues with applications you install on your computer. Perhaps they > > are worse in that case, since so many people have so many problems with > > malware, spyware, worms and viruses. > > > > With my own computer, there are things I can do to prevent that. With > webapps I'm 100% reliant on someone else: there isn't a damn thing I can > do. > > >> > >> - worse security (a networkless local box IS quite safe, if CIA is > >> raiding your house every week, you're probably doing something wrong, > >> otherwise, buy better locks) > >> > > > > Javascript+browser can be a purely client-machine application too just > > like > > D or Java or C > > > > Yes, but what would be the point? It would be all downsides and no upsides. > If you're going to have a local app it may as well be > D/Java/C/Python/whatever. > > >> > >> - worse performance (at least now and in the next few years) > >> > > > > Yes. But if you take frame rates in games, which is a terrible example > > for > > javascript, the more general truth is that beyond a certain point, > > performance differences are undetectable to the human eye. > > Which the vast majority of JS web apps are nowhere remotely near. > > > At which point, > > the only thing driving your technology choice is developer productivity. > > Which once again is a big vote *against* web-browser-as-a-platform. > > >> > >> - worse usability > >> > > > > Completely disagree. Desktop apps right now have an enormous advantage > in > > how much development-hours have gone into them over web app counterparts. > > This will change, quickly. > > > > I've been hearing that for a long time. Still waiting. In the meantime, the > only changes I've seen have been for the worse. > > >> > >> I know the good sides. No need to mention them. In my opinion the > >> downsides are still more important when making the decision. > >> > > > > Honestly, where do think things will stand 5-10 years from now? > > > > I shudder to even think...Nowhere good considering the directions things > are > moving. > > > >
Re: JSON
On 12/15/10 2:05 PM, Robert Jacques wrote: On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu wrote: On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei I don't think so, each bug seems to still be open and I haven't seen any posts to the phobos list mentioning them. The bug reports do all contain patches though. Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155 Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233 Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236 Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232 This month's release is already in beta, so this probably won't make it now. Would be great to boost the priority bugs for the next release then. Andrei
Re: improvement request - enabling by-value-containers
Jonathan Schmidt-Dominé Wrote: > Kagamin wrote: > > Hmm... never needed to clone a container. Is there a use case for by-value > > containers? > I have implemented the Quine McCluskey algorithm in Ruby, it was really > annoying and difficult to find the bugs. What I understand from description, the algorithm consists of several steps of joining. Did you try to join in place?
Re: emscripten
"Michael Stover" wrote in message news:mailman.1037.1292442333.21107.digitalmar...@puremagic.com... > On Wed, Dec 15, 2010 at 2:26 PM, retard wrote: > >> Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: >> >> > The point was that while Javascript is slow, it's getting fast enough >> > to be useful. Yes, it's not C. It will never be. But the fact that any >> > sort of realtime calculations are possible in it is a breakthrough that >> > will be reflected in actual application code. Javascript was not >> > designed to be fast, and honestly, it doesn't need to be fast to fill >> > it's niche. >> >> I'm not getting this. WHY we should use Javascript/HTML5 applications >> instead. I'm perfectly happy with my existing tools. They work nicely. It >> takes years to develop these applications on top of HTML5. I simply have >> no motivation to use web applications. They have several downsides: >> >> - you "rent" the app, you don't "own" it anymore >> > > Many would find that a benefit, as updates are automatic, never need to > install new versions. > It's not uncommon for newer versions to be worse. Look at Acrobat Reader, iTunes, and Nero. A lot of people don't want to be forced into updates that make things worse. My Mom uses Hotmail and has a fit every time they decide to change everything around (which seems to be quite a lot). She'd be far happier with something that didn't work that way, but she sticks with it because she's every bit as much of a group-think lemming as everyone else. > >> => which leads to: advertisements, monthly fees >> > > Again, benefits galore for some folks. Should I pay $80 to buy the > software > and find out if I like it, and another $40 two years later to upgrade, or > pay $4/month and quit whenever I'm done with it? > Or get freeware/FLOSS and pay nothing and have no ads. And there's ad-supported desktop software too, so with desktop software you can go either way. Web apps can't go either way, because there's always the possibility the owner will pull the plug, and even if they don't, the ownser will still have server expenses which will have to get paid somehow. >> >> - worse privacy (do I want some Mark SuckerBerg to spy on my personal >> life for personal gain) >> > > Same issues with applications you install on your computer. Perhaps they > are worse in that case, since so many people have so many problems with > malware, spyware, worms and viruses. > With my own computer, there are things I can do to prevent that. With webapps I'm 100% reliant on someone else: there isn't a damn thing I can do. >> >> - worse security (a networkless local box IS quite safe, if CIA is >> raiding your house every week, you're probably doing something wrong, >> otherwise, buy better locks) >> > > Javascript+browser can be a purely client-machine application too just > like > D or Java or C > Yes, but what would be the point? It would be all downsides and no upsides. If you're going to have a local app it may as well be D/Java/C/Python/whatever. >> >> - worse performance (at least now and in the next few years) >> > > Yes. But if you take frame rates in games, which is a terrible example > for > javascript, the more general truth is that beyond a certain point, > performance differences are undetectable to the human eye. Which the vast majority of JS web apps are nowhere remotely near. > At which point, > the only thing driving your technology choice is developer productivity. Which once again is a big vote *against* web-browser-as-a-platform. >> >> - worse usability >> > > Completely disagree. Desktop apps right now have an enormous advantage in > how much development-hours have gone into them over web app counterparts. > This will change, quickly. > I've been hearing that for a long time. Still waiting. In the meantime, the only changes I've seen have been for the worse. >> >> I know the good sides. No need to mention them. In my opinion the >> downsides are still more important when making the decision. >> > > Honestly, where do think things will stand 5-10 years from now? > I shudder to even think...Nowhere good considering the directions things are moving.
Re: Paralysis of analysis
On Wed, 15 Dec 2010 15:19:34 -0500, Dmitry Olshansky wrote: On 15.12.2010 22:52, Steven Schveighoffer wrote: On Wed, 15 Dec 2010 14:18:20 -0500, Dmitry Olshansky wrote: Hm, ((T*)malloc(1024*T.sizeof))[0..size]; works. Just needs careful initialization of each field, since they are filled with trash ... And you can even do slicing. Just don't append to them and keep track of the initial reference ;) You can append them. The append code will recognize that it's not a GC block and reallocate. Good to know. I should also note, if you do this: auto x = ((T*)malloc(1024*T.sizeof))[0..size]; x ~= T.init; You have now lost the original reference to the data (because x now points to the GC allocated block), so it will leak! So while appending does work, you have to take care to still keep track of the original data. I'd recommend something like this if it's a temporary: auto x = (cast(T*)malloc(1024*T.sizeof))[0..size]; const origdata = x.ptr; scope(exit) free(origdata); -Steve
Re: emscripten
Do you complain that Excel doesn't not "degrade gracefully"? Why would someone even think to load the app in lynx? Do you load excel files in lynx? On Wed, Dec 15, 2010 at 3:32 PM, Adam D. Ruppe wrote: > Michael Stover wrote: > > If I provide a spreadsheet program via javascript, > > why should it have to work in Lynx? > > It doesn't necessarily have to work, but it should degrade gracefully. If > it goes > all the way down the Lynx gracefully, that means it is most likely usable > by everyone. > > For a spreadsheet, I'd output the data in an html table. Now all users can > at > least view the saved document, with no extra effort from you. >
Re: emscripten
Michael Stover wrote: > If I provide a spreadsheet program via javascript, > why should it have to work in Lynx? It doesn't necessarily have to work, but it should degrade gracefully. If it goes all the way down the Lynx gracefully, that means it is most likely usable by everyone. For a spreadsheet, I'd output the data in an html table. Now all users can at least view the saved document, with no extra effort from you.
Re: How do I do placement delete in D?
On Wed, 15 Dec 2010 12:46:34 -0500, Stanislav Blinov wrote: 15.12.2010 0:05, Craig Black пишет: Thanks Steve. clear seems to be calling the destructor twice. Is this intentional? -Craig AFAIR, it's not 'clear()' that calls destructor twice. Some time ago, there has been discussion on how to properly implement clear(). Initial implementation calls dtor, then calls default ctor to leave the object in a meaningful state for the GC to consume. Therefore, when object is being collected, dtor gets called for a second time. The discussion ended on the proposal of nullifying objec't vtbl instead of calling default ctor, which will obviate the need of a second dtor call, but I think this is not currently implemented. No, the issue is different. Struct dtors are not called when GC memory is collected. I found the issue. I just checked in a fix: http://www.dsource.org/projects/druntime/changeset/451 -Steve
Re: emscripten
>Trying to make an online payment to Visa or check on one of Visa's policies? Are you gonna be able to do that at MasterCard's website? With desktop software stuff like that rarely happens. Basically, websites/webapps have a greater need for compatibility than desktop apps do. Again, we're not talking about *websites*. We're talking about web *apps*. Of course your bank site ought to provide you your account info whether you are on a Mac or Windows and even if you use IE 5.5. But that's not what we're talking about. We're talking about someone making an application that, today or in the past you would have downloaded and installed, and instead making it runnable in a browser. It's not content, it's *behavior*you're there for, and therefore, if they require Chrome and you are a devoted Firefox user, then you can find someone else who provides that behavior in Firefox and use them instead. There's no tie to some particular content provided (like Visa), just like there isn't with desktop apps. Mike On Wed, Dec 15, 2010 at 3:14 PM, Nick Sabalausky wrote: > "David Nadlinger" wrote in message > news:ieb3q0$1n...@digitalmars.com... > > On 12/15/10 8:04 PM, Nick Sabalausky wrote: > >> Are they in 99.9% of the browsers *actually being used now*? > > > > As it was already discussed, this is not as much of an argument as it > > might seem - Windows x86 isn't used on 99.9% of all machines either. > > > > First of all, the percentage of user machines that are Windows is much much > higher than the percentage of browsers being used that are bleeding-edge. > > Secondly, If someones going to make a non-cross-platform desktop app these > days, I'd consider that silly too. Maybe less silly, but only because it's > notably easier to test a page with JS on/off and in multiple browsers than > to test an app on multiple OSes, and because there is Wine. > > Third, it's uncommon to need to use a *specific* non-cross-platform app. > The > vast majority of the time there are alternates available. But it's not > uncommon at all for a website to not have an alternate equivalent. Trying > to > make an online payment to Visa or check on one of Visa's policies? Are you > gonna be able to do that at MasterCard's website? With desktop software > stuff like that rarely happens. Basically, websites/webapps have a greater > need for compatibility than desktop apps do. > > > >
Re: Paralysis of analysis
On 15.12.2010 22:52, Steven Schveighoffer wrote: On Wed, 15 Dec 2010 14:18:20 -0500, Dmitry Olshansky wrote: On 15.12.2010 3:50, Jonathan M Davis wrote: On Tuesday, December 14, 2010 16:35:34 Craig Black wrote: What say you? I feel like the odd man out here since my perspective is so different. I use custom container classes even in C++, partly because I can usually get better performance that way, and because I can customize the the container however I like. So I will probably be doing my own containers if/when I use D. Beyond that, my own personal preferences seem so different that I hesitate to mention them. I use dynamic arrays by far the most out of all container classes. I use them so much that I cringe at the thought of allocating them on the GC heap. My code is very high performance and I would like to keep it that way. Also, my usage of arrays is such that most of them are empty, so it is important to me that the empty arrays are stored efficiently. Using my custom container class, an empty array does not require a heap allocation, and only requires a single pointer to be allocated. Not sure if these requirements are important to anyone else, but I don't mind making my own custom containers if I need to. Dynamic arrays are already on the GC heap... - Jonathan M Davis Hm, ((T*)malloc(1024*T.sizeof))[0..size]; works. Just needs careful initialization of each field, since they are filled with trash ... And you can even do slicing. Just don't append to them and keep track of the initial reference ;) You can append them. The append code will recognize that it's not a GC block and reallocate. Good to know. What you need to do more importantly is depending on the type of T, you may need to register the block as a root in the GC. Otherwise, if T contains GC references, those could be collected prematurely. Right, this is very important! I just checked, and luckily I did this only with plain data structs. -Steve -- Dmitry Olshansky
Re: emscripten
"David Nadlinger" wrote in message news:ieb3q0$1n...@digitalmars.com... > On 12/15/10 8:04 PM, Nick Sabalausky wrote: >> Are they in 99.9% of the browsers *actually being used now*? > > As it was already discussed, this is not as much of an argument as it > might seem - Windows x86 isn't used on 99.9% of all machines either. > First of all, the percentage of user machines that are Windows is much much higher than the percentage of browsers being used that are bleeding-edge. Secondly, If someones going to make a non-cross-platform desktop app these days, I'd consider that silly too. Maybe less silly, but only because it's notably easier to test a page with JS on/off and in multiple browsers than to test an app on multiple OSes, and because there is Wine. Third, it's uncommon to need to use a *specific* non-cross-platform app. The vast majority of the time there are alternates available. But it's not uncommon at all for a website to not have an alternate equivalent. Trying to make an online payment to Visa or check on one of Visa's policies? Are you gonna be able to do that at MasterCard's website? With desktop software stuff like that rarely happens. Basically, websites/webapps have a greater need for compatibility than desktop apps do.
Re: JSON (was: emscripten )
Robert Jacques wrote: > I also used allMembers in my first iteration, but it gives what > I'd consider false positives, so you have to filter the results. Aye. What I did that was good enough for me was to skip any names that started with a _ (which hits _ctor and also a naming convention for "private" variables) and also added a check for a member function toJsonValue. If that member function is available, it is called instead of proceeding inside, letting the struct or class specialize its own output, thus getting around the naming problems. I never used it in practice though, since I just learned to avoid names that cause problems. Not a perfect solution but it worked for me.
Re: emscripten
If I provide a spreadsheet program via javascript, why should it have to work in Lynx? It's not a web page. I'm providing absolutely ZERO content. It is only behavior, just like Excel is only behavior. If I provide the same functionality, but only if you use Chrome or Firefox, why is that so horrible? On Wed, Dec 15, 2010 at 2:50 PM, Nick Sabalausky wrote: > "Michael Stover" wrote in message > news:mailman.1034.1292441124.21107.digitalmar...@puremagic.com... > > >And no, I'm *not* playing semantics games here: "Distributed via the > > web" means exactly what it means > > > > Of course you're playing semantic games. Not being very helpful in the > > discussion. You seem to be arguing that if the content arrived via > "http" > > it must work in lynx or else it "sucks". > > > > Not at all. In fact that blatantly contradicts what I just pointed out. > Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, > like that matters) and yet, like I said, they're obviously not what we're > talking about when we're talking about web apps. > > Secondly, I'm not the one that brought up Lynx. Although if there's > something that clearly doesn't need graphics and such to be useful, then > yes, it absolutely should work on Lynx. Apps obviously shouldn't require > things they don't need: My DB shouldn't require I have a webcam installed. > Grep shouldn't require an email client. Making a backup shouldn't require > OpenGL or a printer. Submitting a form or downloading a PDF shouldn't > require JS or HTML images. Viewing information on an official county > probate > court website shouldn't require Flash (I've actually seen that, and I'd be > very surprised if it doesn't violate multiple government-mandated > accessibility requirements). Etc. > > >
Re: JSON
On Wed, 15 Dec 2010 13:42:39 -0500, Andrei Alexandrescu wrote: On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei I don't think so, each bug seems to still be open and I haven't seen any posts to the phobos list mentioning them. The bug reports do all contain patches though. Issue 5155: http://d.puremagic.com/issues/show_bug.cgi?id=5155 Issue 5233: http://d.puremagic.com/issues/show_bug.cgi?id=5233 Issue 5236: http://d.puremagic.com/issues/show_bug.cgi?id=5236 Issue 5232: http://d.puremagic.com/issues/show_bug.cgi?id=5232
Re: emscripten
"Michael Stover" wrote in message news:mailman.1034.1292441124.21107.digitalmar...@puremagic.com... > >And no, I'm *not* playing semantics games here: "Distributed via the > web" means exactly what it means > > Of course you're playing semantic games. Not being very helpful in the > discussion. You seem to be arguing that if the content arrived via "http" > it must work in lynx or else it "sucks". > Not at all. In fact that blatantly contradicts what I just pointed out. Things like DMD, certain OSes, etc, all arrive via http (or ftp, whatever, like that matters) and yet, like I said, they're obviously not what we're talking about when we're talking about web apps. Secondly, I'm not the one that brought up Lynx. Although if there's something that clearly doesn't need graphics and such to be useful, then yes, it absolutely should work on Lynx. Apps obviously shouldn't require things they don't need: My DB shouldn't require I have a webcam installed. Grep shouldn't require an email client. Making a backup shouldn't require OpenGL or a printer. Submitting a form or downloading a PDF shouldn't require JS or HTML images. Viewing information on an official county probate court website shouldn't require Flash (I've actually seen that, and I'd be very surprised if it doesn't violate multiple government-mandated accessibility requirements). Etc.
Re: Paralysis of analysis
On Wed, 15 Dec 2010 14:18:20 -0500, Dmitry Olshansky wrote: On 15.12.2010 3:50, Jonathan M Davis wrote: On Tuesday, December 14, 2010 16:35:34 Craig Black wrote: What say you? I feel like the odd man out here since my perspective is so different. I use custom container classes even in C++, partly because I can usually get better performance that way, and because I can customize the the container however I like. So I will probably be doing my own containers if/when I use D. Beyond that, my own personal preferences seem so different that I hesitate to mention them. I use dynamic arrays by far the most out of all container classes. I use them so much that I cringe at the thought of allocating them on the GC heap. My code is very high performance and I would like to keep it that way. Also, my usage of arrays is such that most of them are empty, so it is important to me that the empty arrays are stored efficiently. Using my custom container class, an empty array does not require a heap allocation, and only requires a single pointer to be allocated. Not sure if these requirements are important to anyone else, but I don't mind making my own custom containers if I need to. Dynamic arrays are already on the GC heap... - Jonathan M Davis Hm, ((T*)malloc(1024*T.sizeof))[0..size]; works. Just needs careful initialization of each field, since they are filled with trash ... And you can even do slicing. Just don't append to them and keep track of the initial reference ;) You can append them. The append code will recognize that it's not a GC block and reallocate. What you need to do more importantly is depending on the type of T, you may need to register the block as a root in the GC. Otherwise, if T contains GC references, those could be collected prematurely. -Steve
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 13:31:37 -0500, Adam D. Ruppe wrote: Robert Jacques wrote: *snip code* I'm just quickly looking it over, with some brief comments. Your code looks good. You covered everything, and your use of tupleof seems to do a better job than my own use of allMembers! Very cool. I guess I'm actually very brief, but generally it looks nice. I'll try using it in a project sometime (hopefully soon) and may have some meaty comments then, but from the source, I think I'll like it. Thanks. I also used allMembers in my first iteration, but it gives what I'd consider false positives, so you have to filter the results.
Re: emscripten
On Wed, Dec 15, 2010 at 2:26 PM, retard wrote: > Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: > > > The point was that while Javascript is slow, it's getting fast enough > > to be useful. Yes, it's not C. It will never be. But the fact that any > > sort of realtime calculations are possible in it is a breakthrough that > > will be reflected in actual application code. Javascript was not > > designed to be fast, and honestly, it doesn't need to be fast to fill > > it's niche. > > I'm not getting this. WHY we should use Javascript/HTML5 applications > instead. I'm perfectly happy with my existing tools. They work nicely. It > takes years to develop these applications on top of HTML5. I simply have > no motivation to use web applications. They have several downsides: > > - you "rent" the app, you don't "own" it anymore > Many would find that a benefit, as updates are automatic, never need to install new versions. > => which leads to: advertisements, monthly fees > Again, benefits galore for some folks. Should I pay $80 to buy the software and find out if I like it, and another $40 two years later to upgrade, or pay $4/month and quit whenever I'm done with it? - this is especially bad if you're already using free as in beer/ > speech software > gmail is free as in beer and nothing prevents it being open source. > - this is especially bad ethically if you're writing free software > There is no change here. > > - worse privacy (do I want some Mark SuckerBerg to spy on my personal > life for personal gain) > Same issues with applications you install on your computer. Perhaps they are worse in that case, since so many people have so many problems with malware, spyware, worms and viruses. > > - worse security (a networkless local box IS quite safe, if CIA is > raiding your house every week, you're probably doing something wrong, > otherwise, buy better locks) > Javascript+browser can be a purely client-machine application too just like D or Java or C > > - worse performance (at least now and in the next few years) > Yes. But if you take frame rates in games, which is a terrible example for javascript, the more general truth is that beyond a certain point, performance differences are undetectable to the human eye. At which point, the only thing driving your technology choice is developer productivity. Even before that point of undetectability, most people will choose the app that provides more features over the one that performs somewhat better. And for good reason. Something being a little slow vs not being able to do it at all is an easy choice for most people. People on this mailing list are somewhat eccentric in their demands, which is entirely their right, but y'all should at least recognize web apps are and will be successful by and large. > > - worse usability > Completely disagree. Desktop apps right now have an enormous advantage in how much development-hours have gone into them over web app counterparts. This will change, quickly. > > - worse reliability (network problems, server problems) > In theory, yes, and once in a while it is a problem, but I honestly can't remember the last time I had any issues with connectivity. > > I know the good sides. No need to mention them. In my opinion the > downsides are still more important when making the decision. > Honestly, where do think things will stand 5-10 years from now?
Re: New syntax for string mixins
On Wednesday, December 15, 2010 11:27:47 Jacob Carlborg wrote:
> On 2010-12-14 21:44, Nick Sabalausky wrote:
> > "Jacob Carlborg" wrote in message
> > news:ie8i8c$15f...@digitalmars.com...
> >
> >> On 2010-12-14 19:13, Nick Sabalausky wrote:
> >>> "Graham St Jack" wrote in message
> >>> news:ie76ig$b2...@digitalmars.com...
> >>>
> What you are suggesting here seems to be a way to dramatically reduce
> the
> complexity of code that generates source-code and mixes it in. I think
> something like that is needed before this mind-bogglingly powerful
> feature
> of D can realise its potential.
> >>>
> >>> I think a decent string-template library could probably come very close
> >>> to
> >>> the proposal without needing any language changes at all:
> >>>
> >>> string get_set(T, string name)()
> >>> {
> >>>
> >>>return
> >>>q{
> >>>
> >>>@type _...@name;
> >>>
> >>>@type @name ()
> >>>{
> >>>
> >>>return _...@name;
> >>>
> >>>}
> >>>
> >>>@type @name (@type @name)
> >>>{
> >>>
> >>>return _...@name = @name;
> >>>
> >>>}
> >>>
> >>>}.replace( ["@type": T.stringof, "@name": name] );
> >>>
> >>> }
> >>>
> >>> class Foo
> >>> {
> >>>
> >>>mixin(get_set!(int, "bar")());
> >>>
> >>> }
> >>>
> >>> There are definitely some things about the proposal that are better
> >>> than with this, but I just wanted to point out that the value of the
> >>> proposal should probably be evaluated against something roughly like
> >>> the above rather
> >>> than something that does a bunch of procedural string splicing.
> >>
> >> The whole point of the idea was to get rid of the strings and the mixin
> >> expression (as it looks like to day).
> >
> > While I'm not necessarily opposed to the idea of getting rid of the
> > strings, I guess I don't really see what improvement your proposal
> > provides other than not having to manually specify the mapping of
> > "replace what identifier with what data".
> >
> > Getting rid of the "mixin" I see as a separate issue. We could just as
> >
> > easily say that given the function "string get_set(...)":
> > @get_set("int", "bar");
> > or
> > @get_set int bar;
> >
> > ...Is shorthand for, or is even the new syntax for:
> > mixin(get_set("int", "bar"));
>
> That was my idea as well, that
>
> @get_set("int", "bar");
>
> could be translated into
>
> mixin(get_set("int", "bar")); just like
>
> just like scope statements are translated into try/catch/finally.
Honestly, I don't see much gain in using @ rather than mixin(). It's a little
less typing, but that's it. And it precludes stuff like mixin("lhs " ~ op ~ "
rhs") like happens all the time in overloaded operator functions.
- Jonathan M Davis
Re: New syntax for string mixins
On 2010-12-14 21:44, Nick Sabalausky wrote:
"Jacob Carlborg" wrote in message
news:ie8i8c$15f...@digitalmars.com...
On 2010-12-14 19:13, Nick Sabalausky wrote:
"Graham St Jack" wrote in message
news:ie76ig$b2...@digitalmars.com...
What you are suggesting here seems to be a way to dramatically reduce
the
complexity of code that generates source-code and mixes it in. I think
something like that is needed before this mind-bogglingly powerful
feature
of D can realise its potential.
I think a decent string-template library could probably come very close
to
the proposal without needing any language changes at all:
string get_set(T, string name)()
{
return
q{
@type _...@name;
@type @name ()
{
return _...@name;
}
@type @name (@type @name)
{
return _...@name = @name;
}
}.replace( ["@type": T.stringof, "@name": name] );
}
class Foo
{
mixin(get_set!(int, "bar")());
}
There are definitely some things about the proposal that are better than
with this, but I just wanted to point out that the value of the proposal
should probably be evaluated against something roughly like the above
rather
than something that does a bunch of procedural string splicing.
The whole point of the idea was to get rid of the strings and the mixin
expression (as it looks like to day).
While I'm not necessarily opposed to the idea of getting rid of the strings,
I guess I don't really see what improvement your proposal provides other
than not having to manually specify the mapping of "replace what identifier
with what data".
Getting rid of the "mixin" I see as a separate issue. We could just as
easily say that given the function "string get_set(...)":
@get_set("int", "bar");
or
@get_set int bar;
...Is shorthand for, or is even the new syntax for:
mixin(get_set("int", "bar"));
That was my idea as well, that
@get_set("int", "bar");
could be translated into
mixin(get_set("int", "bar")); just like
just like scope statements are translated into try/catch/finally.
--
/Jacob Carlborg
Re: emscripten
"Adam D. Ruppe" wrote in message news:ieb2ng$2u3...@digitalmars.com... > Nick Sabalausky wrote: >> that's *proof* of how horrid JS is > > I often feel Google is re-discovering DOS' capabilities and going on about > how > great it is. Got it in graphics and input, and files too. > Yea, I feel like I'm one of the few people in the software world that was actually into software throughout the whole 90's, and actually used things like the Apple II (Apple's only good product line ever, IMNSHO). Things go in circles, and it's so frustrating to see things veer off into a brink wall while people like us are left screaming "WTF are you thinking?!" to a deaf audience, only to *eventually* see some of those same drunkards finally begin to get a tiny glint of clarity, at which point we're just shaking our heads going "See, I fucking *told* you so", which, again is ignored by the idiots who think they've invented exactly what we've been fruitlessly preaching all along. > HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a > filesystem > with only a root directory! > I don't know how I feel about that: I'd hate to see HTML5 end up repeating Flash's SuperCookies. >> I'm sure as hell not going to be one of >> those "This site best viewed with X browser" assholes. > > I might be one of those people, though I don't come out and say it, my > sites do > tend to be best viewed with X browser. > > But the important difference is it still *works* in Y and Z browser. It > just won't > have rounded corners, etc. Well, yea, that's just cosmetic irrelevancies. But if something's built for chrome, and then runs on other browsers like a GameBoy-powered streaming-HD-video server, and breaks entirely with JS off (there's a lot of good reasons to have JS off), then that's rather a different story.
Re: emscripten
Wed, 15 Dec 2010 13:18:16 -0500, Nick Sabalausky wrote: > "Andrew Wiley" wrote in message > news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com... >> On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe >> wrote: >>> >>> And in those rare cases where you are doing a lot of client side work, >>> it is so >>> brutally slow that if you start piling other runtimes on top of it, >>> you'll >>> often >>> be left with an unusable mess anyway! >> >> >> Unless you're using the beta of the next IE, the beta of the next >> Opera, or >> the current version of Chrome, in which case you'd find that >> client-side work is becoming more and more feasible. Now, it's not >> there yet, but when a >> C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get >> 30FPS in >> Google Chrome, I start thinking that performance probably won't be >> nearly as >> bad as browsers move forward. >> >> > A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in > *software* rendering mode), and was frequently able to get framerates in > the hundreds on sub-500MHz machines (using hardware rendering - with the > old, old, old 3dfx cards), manages to get *only* 30FPS in JS on a > multi-GHz multi-core machine using what is clearly hardware rendering > (on a modern graphics card), and I'm supposed to think that means JS is > fast? If anything, that's *proof* of how horrid JS is - it turns a > multi-GHz multi-core into a Pentium ~100MHz. What a joke! Some points: - IIRC the game was further optimized since the first release. The requirements went down a bit. Especially the SIMD optimizations allowed much lower MHz requirements with software rendering. Nowadays the SIMD instructions give even better throughput. - Compilers have improved a lot. E.g. auto-vectorization. Requirements went down a bit again. - the Jake2 version also runs faster because of faster JVMs and better OpenGL libraries - OTOH resolutions have gone up... but if the game uses hardware accelerated opengl canvas, using Javascript instead of C doesn't have much effect - overall I think the CPU requirements have gone down even though higher resolution and expensive graphical effects are more common these days. Indeed Quake II used to work very fast on Pentium II class hardware with Nvidia TNT cards. I think I got over 100 fps @ 1280x1024 over 10 years ago. Getting 30 FPS on average now IS a bad joke. The (graphics) hardware gets 100% faster every 12-18 months. Even if you make the game twice as fast as now, hardcore fps gamers wouldn't find the rate acceptable for modern network gaming. Hardcore fps gamers won't also play 13 yo games anymore. I admit that JavaScript is getting faster and faster. However, at some point the language will hit the performance wall. Luajit is one of the fastest dynamic languages out there. It's still drastically slower than statically typed languages. It probably shows has fast JavaScript can possibly get in raw computational tasks. This is all ok for "casual gaming", but if you only get 30 FPS when running a 13 yo game, it means you're 15-16 years behind the state of the art. OTOH slow software rendered flash applets were already used as a platform for casual gaming, HTML5 doesn't change the situation that much. Maybe the greatest difference is that HTML5 also runs quite fast on Linux. This HTML5 hype also helps them in marketing. After all, it's the same old shit in new package. >> [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...] > > Yea, *eventually* HTML5 will *improve* a few things...That hardly counts > as "The web's not a shitty platform!". It's just 15-16 years behind the state of the art. Not much!
Re: emscripten
On 12/15/10 8:04 PM, Nick Sabalausky wrote: Are they in 99.9% of the browsers *actually being used now*? As it was already discussed, this is not as much of an argument as it might seem – Windows x86 isn't used on 99.9% of all machines either… David
Re: emscripten
>And no, I'm *not* playing semantics games here: "Distributed via the web" means exactly what it means Of course you're playing semantic games. Not being very helpful in the discussion. You seem to be arguing that if the content arrived via "http" it must work in lynx or else it "sucks". Perhaps I will just rename it to "ws" and then you can have some new expectations that don't cloud your judgement so. On Wed, Dec 15, 2010 at 1:51 PM, Adam D. Ruppe wrote: > Nick Sabalausky wrote: > > that's *proof* of how horrid JS is > > I often feel Google is re-discovering DOS' capabilities and going on about > how > great it is. Got it in graphics and input, and files too. > > HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a > filesystem > with only a root directory! > > I wonder if it even works to store interesting data. When I was working on > the > DWS/AJAX viewer (Which I still intend to finish if I get a decent break > from > work... that I don't spend flamewarring on the newsgroup), I tried to get a > binary > string sent down, manipulated, and finally displayed as an image. > > But: > > var img = new Image(binaryData); // didn't work > > Some browsers supported a img.src = "data://" + encodedBinaryData, but not > all of > them did, and the limit was obscenely small anyway. > > I ultimately just served it from the server and referenced it via url. But > I had > that option since there was a server app available... what would the local > storage do? > > > Blargh. > > > > I'm sure as hell not going to be one of > > those "This site best viewed with X browser" assholes. > > I might be one of those people, though I don't come out and say it, my > sites do > tend to be best viewed with X browser. > > But the important difference is it still *works* in Y and Z browser. It > just won't > have rounded corners, etc. >
Re: emscripten
Wed, 15 Dec 2010 12:40:50 -0600, Andrew Wiley wrote: > The point was that while Javascript is slow, it's getting fast enough > to be useful. Yes, it's not C. It will never be. But the fact that any > sort of realtime calculations are possible in it is a breakthrough that > will be reflected in actual application code. Javascript was not > designed to be fast, and honestly, it doesn't need to be fast to fill > it's niche. I'm not getting this. WHY we should use Javascript/HTML5 applications instead. I'm perfectly happy with my existing tools. They work nicely. It takes years to develop these applications on top of HTML5. I simply have no motivation to use web applications. They have several downsides: - you "rent" the app, you don't "own" it anymore => which leads to: advertisements, monthly fees - this is especially bad if you're already using free as in beer/ speech software - this is especially bad ethically if you're writing free software - worse privacy (do I want some Mark SuckerBerg to spy on my personal life for personal gain) - worse security (a networkless local box IS quite safe, if CIA is raiding your house every week, you're probably doing something wrong, otherwise, buy better locks) - worse performance (at least now and in the next few years) - worse usability - worse reliability (network problems, server problems) I know the good sides. No need to mention them. In my opinion the downsides are still more important when making the decision.
Re: Paralysis of analysis
On 15.12.2010 3:50, Jonathan M Davis wrote: On Tuesday, December 14, 2010 16:35:34 Craig Black wrote: What say you? I feel like the odd man out here since my perspective is so different. I use custom container classes even in C++, partly because I can usually get better performance that way, and because I can customize the the container however I like. So I will probably be doing my own containers if/when I use D. Beyond that, my own personal preferences seem so different that I hesitate to mention them. I use dynamic arrays by far the most out of all container classes. I use them so much that I cringe at the thought of allocating them on the GC heap. My code is very high performance and I would like to keep it that way. Also, my usage of arrays is such that most of them are empty, so it is important to me that the empty arrays are stored efficiently. Using my custom container class, an empty array does not require a heap allocation, and only requires a single pointer to be allocated. Not sure if these requirements are important to anyone else, but I don't mind making my own custom containers if I need to. Dynamic arrays are already on the GC heap... - Jonathan M Davis Hm, ((T*)malloc(1024*T.sizeof))[0..size]; works. Just needs careful initialization of each field, since they are filled with trash ... And you can even do slicing. Just don't append to them and keep track of the initial reference ;) -- Dmitry Olshansky
Re: Reducing template constraint verbosity? [was Re: Slides from my ACCU Silicon Valley talk]
On 12/15/10 7:57 PM, Jonathan M Davis wrote:
By the way, what does IFTI stand for?
Implicit Function Template Instantiation, which allows you to do »void
foo(T)(T bar) {}; foo(5);« without manually specifying the template
parameter.
David
Re: Why Ruby?
On Wed, 15 Dec 2010 02:53:40 -0500, Nick Sabalausky wrote: > "lurker" wrote in message > news:ie8rc3$27l...@digitalmars.com... >> Nick Sabalausky Wrote: >> >>> "piotrek" wrote in message >>> news:ie8fu9$ej...@digitalmars.com... >>> > On Mon, 13 Dec 2010 09:49:50 -0600, Andrei Alexandrescu wrote: >>> >> By the way, I couldn't stop cringing at the distasteful, >>> >> male-centric sexual jokes that the talk is peppered with. Wonder if >>> >> there was any woman in the audience, and how she might have felt. >>> >> And this is not a ghetto rant - it's the keynote of a major Ruby >>> >> conference! (And I'm definitely not a prude.) Am I alone in >>> >> thinking that this is not what our metier should evolve into? >>> >> >>> >> >>> >> Andrei >>> > >>> > You're definitely not. No matter how strong pressure is, I stand and >>> > fight against common acceptance for female humiliation. It's so sad >>> > to me how many think they're real men while treating women as a >>> > things they can freely abuse. >>> > >>> > >>> Didja hear the one about the blonde who couldn't find her pencil? >> >> I have a bad sense of humor, but what is this if I'm trolling? > > Heh. It's me being an ass :) > > But seriously, I'm not flaming anyone here, and really taking a > round-about way to point out that there's too much "inventing things to > be offended about" going on in the world. I still haven't looked at the > video, so maybe some of the things really were worse than the example > Andrei mentioned or the joke I referenced above, but *if* these things > are the sorts of things that piotrek and Andrei find "offensive to > women", then I'd have to call a big "bullshit, this is just inventing > blatant assumptions and then getting offended by them". Firstly I apologize Andrei if I put him in bad light after hijacking his sub-thread and then using it to add some personal opinion. Secondly I was referring to bigger picture of society and not only this video. And still I don't agree to "tolerate"* behavior which is based on so called "freedom". Because all you do has its consequence and interacts with "freedom" of other people and vice versa. Of course appropriate action should be used not exaggerated ones. And I had a peaceful intercommunication on my mind when speaking about fighting ;) I can say as a Christian that respect for dignity goes along with love. But your choice. And in the world the weak ones are abused all the time. I couldn't live pretending I don't see it. So one way is to give my opinion. Not don't giving a shit. Cheers Piotrek
Re: emscripten
"Andrew Wiley" wrote in message news:mailman.1030.1292438460.21107.digitalmar...@puremagic.com... > On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky wrote: >> >> A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in >> *software* rendering mode), and was frequently able to get framerates in >> the >> hundreds on sub-500MHz machines (using hardware rendering - with the old, >> old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz >> multi-core machine using what is clearly hardware rendering (on a modern >> graphics card), and I'm supposed to think that means JS is fast? If >> anything, that's *proof* of how horrid JS is - it turns a multi-GHz >> multi-core into a Pentium ~100MHz. What a joke! >> > > The point was that while Javascript is slow, it's getting fast enough to > be > useful. Yes, it's not C. It will never be. But the fact that any sort of > realtime calculations are possible in it is a breakthrough that will be > reflected in actual application code. > Javascript was not designed to be fast, and honestly, it doesn't need to > be > fast to fill it's niche. > >> > [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...] >> >> Yea, *eventually* HTML5 will *improve* a few things...That hardly counts >> as >> "The web's not a shitty platform!". >> > > Well, there was a list of reasons why it was a shitty platform, and I > showed > that it's not as shitty as it seems. Honestly, I agree that it's a shitty > platform in general, but it's also not nearly as bad as many people think > it > is, and a lot of effort is going into reducing its relative shittiness. > Fair enough. But I still think it would be far better for people to put their efforts into developing/pushing an alternate that's actually decent on a fundamental level than to blow all that effort on polishing a turd. > > These aren't things coming > *eventually* to each browser, they're things that browser developers are > adding *now*. > Are they in 99.9% of the browsers *actually being used now*? No, they're not. Deployment to user machines doesn't happen instantaneously, nor should it. You can talk about auto-update, but IMO anything that *forces* auto-updates is bad, bad, bad, bad, bad. (Optional auto-update is fine, of course.)
Re: Paralysis of analysis -- the value/ref dilemma
On Wed, 15 Dec 2010 11:57:32 -0600
Andrei Alexandrescu wrote:
> On 12/15/10 11:05 AM, spir wrote:
> > What I'm trying to fight is beeing forced to implement semantics
> > values as concrete ref elements. This is very bad, a kind of
> > conceptual distortion (the author of XL calls this semantic mismatch)
> > that leads to much confusion.
> [snip example]
>
> > Conceptually, we absolutely need both.
> > Again the ref/value semantic duality is independant from data types.
> > If the language provides one kind only, we have to hack, to cheat
> > with it.
>
> Both are good. The question is which should be the "default" one and
> what should be the "other" one.
>
> Your example is from a class of examples that basically say: a mutable
> reference object in a struct with value semantics is trouble. That is:
>
> struct Widget // value type
> {
> ...
> Array!Color colorMap; // oops, undue aliasing
> }
>
> That is correct. There are two solutions I envision:
I agree this is also an issue, but this is not the one I had in mind (sorry,
for unclear expression).
> 1. Define a Value wrapper in std.container or std.typecons:
>
> struct Widget // value type
> {
> ...
> Value!(Array!Color) colorMap; // clones upon copying
> }
>
> 2. Define this(this)
>
> struct Widget // value type
> {
> ...
> Array!Color colorMap; // manually cloned upon copying
> this(this) {
> colorMap = colorMap.clone;
> }
> }
>
> Note that if Widget is a class there is no such problem. The entire
> issue applies to designing value types.
Actually, that is not what I meant. The actual "nature" (class/struct) of
Widget is not the problem I tried to point. Rather to have colorMap's type
defined as a class when its meaning (in the model) is of plain value (often to
avoid useless copy); or conversely (eg to avoid cost of instanciation on the
heap).
Ideally, I would like to have ref vs value distinction orthogonal to the whole
type system, meaning "entity with identity" vs "plain data". For this, the
language must
(1) properly cope with implemention issues (read: code efficiency),
(2) provide a "ref-ing" syntax similar to "pointing".
I won't dream of the latter, but I guess the first feature can well be done in
D. In requires the compiler detecting when a value parameter is not touched in
a func body, then passing it by ref behind the stage. This would allow defining
conceptual values as instances of value types without fearing inefficiency.
For the converse issue, I have no idea.
> > [...]
> I don't understand this part.
Not that important [a bit off-topic].
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Reducing template constraint verbosity? [was Re: Slides from my ACCU Silicon Valley talk]
On Wednesday, December 15, 2010 05:16:29 Steven Schveighoffer wrote:
> On Wed, 15 Dec 2010 04:34:53 -0500, Daniel Murphy
>
> wrote:
> > "Patrick Down" wrote in message
> > news:ie8kei$1gd...@digitalmars.com...
> >
> >> Would it help to allow 'else' and 'else if' on the template constraints?
> >>
> >> void foo(R)(R r) if(isRandomAccessRange!R)
> >> {...}
> >> else if(isInputRange!R)
> >> {...}
> >>
> >> This could basically be translated into two specializations like this:
> >>
> >> void foo(R)(R r) if(isRandomAccessRange!R) {...}
> >> void foo(R)(R r) if(isInputRange!R && !isRandomAccessRange!R) {...}
> >
> > You can sorta already do this...
> >
> > template foo(R)
> > {
> >
> > static if (isRandomAccessRange!R)
> >
> > foo(R r) {}
> >
> > else static if (isInputRange!R)
> >
> > foo(R r) {}
> >
> > else
> >
> > static assert(0, "R must be at least an input range");
> >
> > }
>
> The compiler doesn't treat this the same:
>
> 1. no ifti
> 2. if no branches accept the R type, it tries another template.
By the way, what does IFTI stand for?
- Jonathan M Davis
Re: improvement request - enabling by-value-containers
Kagamin wrote: > Hmm... never needed to clone a container. Is there a use case for by-value > containers? I have implemented the Quine McCluskey algorithm in Ruby, it was really annoying and difficult to find the bugs.
Re: emscripten
Nick Sabalausky wrote: > that's *proof* of how horrid JS is I often feel Google is re-discovering DOS' capabilities and going on about how great it is. Got it in graphics and input, and files too. HTML5 local storage is a bunch of key/item pairs. Wooo, it's like a filesystem with only a root directory! I wonder if it even works to store interesting data. When I was working on the DWS/AJAX viewer (Which I still intend to finish if I get a decent break from work... that I don't spend flamewarring on the newsgroup), I tried to get a binary string sent down, manipulated, and finally displayed as an image. But: var img = new Image(binaryData); // didn't work Some browsers supported a img.src = "data://" + encodedBinaryData, but not all of them did, and the limit was obscenely small anyway. I ultimately just served it from the server and referenced it via url. But I had that option since there was a server app available... what would the local storage do? Blargh. > I'm sure as hell not going to be one of > those "This site best viewed with X browser" assholes. I might be one of those people, though I don't come out and say it, my sites do tend to be best viewed with X browser. But the important difference is it still *works* in Y and Z browser. It just won't have rounded corners, etc.
Re: JSON
On 12/15/10 11:49 AM, Robert Jacques wrote: [Algebraic] Are all bugfixes that your work depends on rolled into the upcoming dmd release? Andrei
Re: emscripten
On Wed, Dec 15, 2010 at 12:18 PM, Nick Sabalausky wrote: > > A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in > *software* rendering mode), and was frequently able to get framerates in > the > hundreds on sub-500MHz machines (using hardware rendering - with the old, > old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz > multi-core machine using what is clearly hardware rendering (on a modern > graphics card), and I'm supposed to think that means JS is fast? If > anything, that's *proof* of how horrid JS is - it turns a multi-GHz > multi-core into a Pentium ~100MHz. What a joke! > The point was that while Javascript is slow, it's getting fast enough to be useful. Yes, it's not C. It will never be. But the fact that any sort of realtime calculations are possible in it is a breakthrough that will be reflected in actual application code. Javascript was not designed to be fast, and honestly, it doesn't need to be fast to fill it's niche. > > [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...] > > Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as > "The web's not a shitty platform!". > Well, there was a list of reasons why it was a shitty platform, and I showed that it's not as shitty as it seems. Honestly, I agree that it's a shitty platform in general, but it's also not nearly as bad as many people think it is, and a lot of effort is going into reducing its relative shittiness. > > And what percentage of web users use Chrome? Less than 99%? Well then it > doesn't make a damn bit of difference how great Chrome supposedly is, I'm > not going to design my pages to require it, end of story, and I'm sure as > hell not going to be one of those "This site best viewed with X browser" > assholes. > Thus my explicit and repeated mentions of Opera, Firefox, and IE9 supporting the same features. This isn't a Chrome only thing, and competition alone is insuring that these features aren't Chrome-only. These aren't things coming *eventually* to each browser, they're things that browser developers are adding *now*.
Re: improvement request - enabling by-value-containers
> A partial (but maybe better) solution to this problem is to introduce > "linear types" in D, ad then let the compiler allocate a container on the > stack as an automatic optimization where possible: > http://en.wikipedia.org/wiki/Linear_types Well, then you would have a lot of null-ptrs when using the by-reference- containers, not very intuitive. What should it be good for?
Re: emscripten
"Michael Stover" wrote in message news:mailman.1018.1292422650.21107.digitalmar...@puremagic.com... > And that's the problem - we're talking about applications that happen to > be > distributed via the web, not a "website". Ahh, I see, so it's just "distributed via the web". Here are some applications that *are*, in fact, distrubuted via the web: - DMD - Eclipse - GIMP - Avisynth / VirtualDub - Linux / BSD Those are distributed via the web and using them doesn't require one damn bit of in-browser code execution. Hell, they doesn't even require a browser at all. And no, I'm *not* playing semantics games here: "Distributed via the web" means exactly what it means. So obviously we *are* talking about websites that act as apps, *not* merely apps distributed via the web. > Everyone's demands that it work > in lynx, FF2, with javascript turned off, etc are ludicrous. You don't > get > to make such demands of applications. Of course I get to. See, here I am demanding it. What can you possibly mean by I "don't get to make such demands of applications"? Of course I get to. > Some applications are Windows only. And Unix users *don't* use those apps (wine notwithstanding). Are you goint to complain about Unix users who refuse to use Windows apps or desire apps to be cross-platform? > Some don't follow platform standards. And I avoid using those programs. See, here I am making demands that you didn't think I could make. > Some require 1GB to work effectively. Even *I* have 1GB RAM. And some things *shouldn't* require 1GB RAM: Like a text-entry box. > None let you require it work without running code, etc. Strawman: Nobody ever said anything about not running any code at all. Web apps can work perfectly fine running code on the server.
Re: JSON (was: emscripten )
Vladimir Panteleev wrote: > Umm, I just wrote my own, it's way simpler than what you described. Ah indeed, that is simple! Very nice.
Re: JSON (was: emscripten )
Robert Jacques wrote: > *snip code* I'm just quickly looking it over, with some brief comments. Your code looks good. You covered everything, and your use of tupleof seems to do a better job than my own use of allMembers! Very cool. I guess I'm actually very brief, but generally it looks nice. I'll try using it in a project sometime (hopefully soon) and may have some meaty comments then, but from the source, I think I'll like it.
Re: improvement request - enabling by-value-containers
On Dec 16, 10 02:24, KennyTM~ wrote: On Dec 15, 10 14:23, bearophile wrote: Michel Fortin: I have to echo a similar concern with by-reference containers from my experience of Cocoa. It's really too easy to have two references to the same container without realizing it. A partial (but maybe better) solution to this problem is to introduce "linear types" in D, ad then let the compiler allocate a container on the stack as an automatic optimization where possible: http://en.wikipedia.org/wiki/Linear_types Bye, bearophile std.typecons.Unqiue ? (BTW, I meant 'Unique' :) )
Re: improvement request - enabling by-value-containers
On Dec 15, 10 14:23, bearophile wrote: Michel Fortin: I have to echo a similar concern with by-reference containers from my experience of Cocoa. It's really too easy to have two references to the same container without realizing it. A partial (but maybe better) solution to this problem is to introduce "linear types" in D, ad then let the compiler allocate a container on the stack as an automatic optimization where possible: http://en.wikipedia.org/wiki/Linear_types Bye, bearophile std.typecons.Unqiue ?
Re: emscripten
"Andrew Wiley" wrote in message news:mailman.1026.1292433894.21107.digitalmar...@puremagic.com... > On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe > wrote: >> >> And in those rare cases where you are doing a lot of client side work, it >> is so >> brutally slow that if you start piling other runtimes on top of it, >> you'll >> often >> be left with an unusable mess anyway! > > > Unless you're using the beta of the next IE, the beta of the next Opera, > or > the current version of Chrome, in which case you'd find that client-side > work is becoming more and more feasible. Now, it's not there yet, but when > a > C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS > in > Google Chrome, I start thinking that performance probably won't be nearly > as > bad as browsers move forward. > A game that was designed to run on a 90-133MHz 16-24MB RAM machine (in *software* rendering mode), and was frequently able to get framerates in the hundreds on sub-500MHz machines (using hardware rendering - with the old, old, old 3dfx cards), manages to get *only* 30FPS in JS on a multi-GHz multi-core machine using what is clearly hardware rendering (on a modern graphics card), and I'm supposed to think that means JS is fast? If anything, that's *proof* of how horrid JS is - it turns a multi-GHz multi-core into a Pentium ~100MHz. What a joke! > [HTML5, HTML5, HTML5, Chrome, HTML5, HTML5...] Yea, *eventually* HTML5 will *improve* a few things...That hardly counts as "The web's not a shitty platform!". And what percentage of web users use Chrome? Less than 99%? Well then it doesn't make a damn bit of difference how great Chrome supposedly is, I'm not going to design my pages to require it, end of story, and I'm sure as hell not going to be one of those "This site best viewed with X browser" assholes.
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 16:38:16 +0200, Adam D. Ruppe wrote: I'm curious what you did in your code. Is it a custom module or did you build off the std.json too? Umm, I just wrote my own, it's way simpler than what you described. Also it's in D1. See attached :P -- Best regards, Vladimirmailto:vladi...@thecybershadow.net Json.d Description: Binary data
Re: JSON
On 12/15/10 11:49 AM, Robert Jacques wrote:
[JSON]
Apologies for not making the time to review this; I'm very interested in
the topic but I have 121 emails waiting for attention in my inbox, and
each requires a fair amount of work.
Notes:
* Does anyone have a suggestion of a good way to attach methods to an
Algebraic type? And if we can, should we?
This is a very good challenge. Ideally Algebraic would define a method
if and only if all of its possible types define a method with (a) same
name, (b) covariant return types (i.e. return types have a CommonType),
(c) contravariant parameter types (we don't have ContravariantCommonType
in std.traits, but it should be doable). Consider:
class Widget {
long foo(int);
}
class Gadget {
int foo(long);
}
auto a = Algebraic!(Widget, Gadget)(new Widget);
long x = a.foo(42); // should work
x = a.foo(x); // shouldn't compile
That would be awes, and is in fact implementing an optimization called
type casing.
Andrei
Re: Choosing Go vs. D
Well, you could simply say, Go is good for quick and parallelized stream- manipulation. D is good for everything else, because it supports OOP, Meta- programming, genericity, overloading etc.
Re: emscripten
On Wed, 15 Dec 2010 12:27:48 +0200, Andrej Mitrovic
wrote:
On 12/14/10, Vladimir Panteleev wrote:
if (resource == "/getfoo")
{
struct FooResult { int n; string s; }
return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
}
Funny thing about that commented out code. I've tried returning
something like that once from a function:
return { int n = 42; string s = "bar"; }
So basically a struct that has it's members default-initialized with
some values. Unfortunately D thought I was returning a delegate
instead, so I can't use this syntax.
The commented-out "code" is the resulting JSON :)
--
Best regards,
Vladimirmailto:vladi...@thecybershadow.net
Re: Paralysis of analysis -- the value/ref dilemma
On 12/15/10 11:05 AM, spir wrote:
What I'm trying to fight is beeing forced to implement semantics
values as concrete ref elements. This is very bad, a kind of
conceptual distortion (the author of XL calls this semantic mismatch)
that leads to much confusion.
[snip example]
Conceptually, we absolutely need both.
Again the ref/value semantic duality is independant from data types.
If the language provides one kind only, we have to hack, to cheat
with it.
Both are good. The question is which should be the "default" one and
what should be the "other" one.
Your example is from a class of examples that basically say: a mutable
reference object in a struct with value semantics is trouble. That is:
struct Widget // value type
{
...
Array!Color colorMap; // oops, undue aliasing
}
That is correct. There are two solutions I envision:
1. Define a Value wrapper in std.container or std.typecons:
struct Widget // value type
{
...
Value!(Array!Color) colorMap; // clones upon copying
}
2. Define this(this)
struct Widget // value type
{
...
Array!Color colorMap; // manually cloned upon copying
this(this) {
colorMap = colorMap.clone;
}
}
Note that if Widget is a class there is no such problem. The entire
issue applies to designing value types.
There is a special case in non-OO-only cisconstances: sometimes an
element is passed as parameter while it is conceptually the "object"
(in common sense) on which an operation applies (~ OO receiver). In
OO, it would be passed by ref precisely to allow it beeing changed,
even if it is a plain value (this prevents creating a new value at
every tiny chenge, as opposed to immutability). But this relevant
distinction between object of an operation (what) and true parameters
(how) does not exist in plain function-based style: func(object,
param1, param12); So that we have to pass the object by ref when the
operation is precisely here to modify it. But conceptually it is not
a parameter.
I don't understand this part.
Andrei
Re: JSON (was: emscripten )
On Wed, 15 Dec 2010 09:38:16 -0500, Adam D. Ruppe
wrote:
Vladimir Panteleev Wrote:
if (resource == "/getfoo")
{
struct FooResult { int n; string s; }
return toJSON(FooResult(42, "bar")); // {"n":42,"s":"bar"}
}
What kind of code did you use there? My app does something
similar using wrappers of std.json.
JSONValue toJsonValue(T)(T a) {
JSONValue val;
static if(is(T == JSONValue)) {
val = a;
} else static if(__traits(compiles, a.makeJsonValue())) {
val = a.makeJsonValue();
} else static if(isIntegral!(T)) {
val.type = JSON_TYPE.INTEGER;
val.integer = to!long(a);
[..]
And it goes right through a variety of types, including
structs where it does __traits(allMembers), and ultimately
settles for to!string if nothing else fits.
My program also reads json, but I had some trouble with std.json,
so I had to fork it there. It has a helper function jsonValueToVariant
(which just
became fully usable in dmd 2.050,
shortening my code a lot, thanks phobos/dmd devs!) which
pulls it into a std.variant for easy using later.
The trouble I had was std.json.parseJSON claims to be able
to handle arbitrary input ranges, but when I actually instantiated
it on plain old string, it refused to compile.
I made it work by switching it to just normal strings in my private
fork.
What's really cool about these templates is it enables automatic calling
of
functions from the outside. You write a function like:
struct User { ... }
User getUserInfo(int id) { }
And then this is accessible, through template magic, as:
/app/get-user-info?id=1
Returns a full HTML document with the info
/app/get-user-info?id=1&format=json
Returns the User struct converted to json
/app/get-user-info?id=1&format=xml
The struct as a kind of xml (I didn't spend much time on this so it
still sucks)
And more. Way cool.
Anyway, I thought about committing some of my json changes back to
std.json, but
removing the range capability goes against the grain there, and adding
the
templates seems pointless since everyone says std.json is going to be
trashed
anyway. I thought I might have actually been the only one using it!
I'm curious what you did in your code. Is it a custom module or did you
build off
the std.json too?
Hi Adam,
I've been working on a replacement for std.json. I posted a preview to the
phobos list, but I haven't gotten any feedback yet, as its not very high
priority.
Here is my original post:
I have been working on a re-write of std.json. The purpose was to fix
implementation bugs, better conform to the spec, provide a lightweight
tokenizer (Sean) and to use an Algebraic type (Andrei) for JSON values. In
the progress of doing this, I made my parser 2x faster and updated/fixed a
bunch of issues with VariantN in order to fully support Algebraic types.
Both of these libraries are at a solid beta level, so I'd like to get some
feedback, and provide a patch for those being held back by the problems
with Algebraic. The code and docs are available at:
https://jshare.johnshopkins.edu/rjacque2/public_html/. These files were
written against DMD 2.050 and both depend on some patches currently in
bugzilla (see the top of each file or below)
Summary of Variant changes:
* Depends on Issue 5155's patch
* VariantN now properly supports types defined using "This".
* Additional template constraints and acceptance of implicit converters in
opAssign and ctor. i.e. if an Algebraic type supports reals, you can now
assign an int to it.
* Updated to using opBinary/opBinaryRight/opOpAssign. This adds right
support to several functions and is now generated via compile time
reflection + mixins: i.e. Algebraic types of user defined types should
work, etc.
* Added opIn support, though it currently on works for AAs.
* Added opIndexOpAssign support.
* Added opDispatch as an alternative indexing method. This allows Variants
of type Variant[string] to behave like prototype structs: i.e. var.x = 5;
instead of var["x"] = 5;
Notes:
* There's an bugzilla issue requesting opCall support in Variant. While I
can see the usefulness, syntactically this clashes with the ctor. Should
this issue be closed or should a method be used as an opCall surrogate?
* Could someone explain to me the meaning/intension of "Future additions
to Algebraic will allow compile-time checking that all possible types are
handled by user code, eliminating a large class of errors." Is this
something akin to final switch support?
Summary of JSON changes:
* Depends on the Variant improvements.
* Depends on Issue 5233's patch
* Depends on Issue 5236's patch
* Issue 5232's patch is also recommended
* The integer type was removed: JSON doesn't differentiate between
floating and integral numbers. Internally, reals are used and on systems
with 80-bit support, this encompasses all integral types.
* UTF escape cha
Re: How do I do placement delete in D?
15.12.2010 0:05, Craig Black пишет: Thanks Steve. clear seems to be calling the destructor twice. Is this intentional? -Craig AFAIR, it's not 'clear()' that calls destructor twice. Some time ago, there has been discussion on how to properly implement clear(). Initial implementation calls dtor, then calls default ctor to leave the object in a meaningful state for the GC to consume. Therefore, when object is being collected, dtor gets called for a second time. The discussion ended on the proposal of nullifying objec't vtbl instead of calling default ctor, which will obviate the need of a second dtor call, but I think this is not currently implemented.
Re: emscripten
On Wed, Dec 15, 2010 at 11:24 AM, Andrew Wiley wrote: > On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe > wrote: >> >> And in those rare cases where you are doing a lot of client side work, it >> is so >> brutally slow that if you start piling other runtimes on top of it, you'll >> often >> be left with an unusable mess anyway! > > > Unless you're using the beta of the next IE, the beta of the next Opera, or > the current version of Chrome, in which case you'd find that client-side > work is becoming more and more feasible. Now, it's not there yet, but when a > C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in > Google Chrome, I start thinking that performance probably won't be nearly as > bad as browsers move forward. > > You don't have to like it, but there's a huge push in web development > towards doing more work on the client, and now that browsers are catching > up, it's going to change the way the web works. > > As for the rest: > a) No real time networking > HTML 5 WebSockets, as you said > > b) Cross domain communication requires ugly, inefficient hacks, or a proxy > on your server. > This is the one thing you've listed that's not going to change because it > poses a security risk. > > > c) No sounds (without flash anyway). > Included in HTML 5. > > d) Graphics, even if you grant the canvas element, are a joke. The latency > is > brutal. Take that deviant art thing from earlier in the thread. Flick your > mouse, > and watch the lines slowly catch up to you! Using X11 with a remote server > is > faster than that. > In Chrome (even the version a year or so old that is installed on the lab > computer I'm using right now), there is no latency whatsoever. That's a > simple matter of javascript performance, which is dramatically improving. > > > e) Input requires a lot of magic. Some keys have the same identifiers, some > of the > time, meaning just checking for keypress requires dozens of lines of code, > and > still doesn't work right! Checking for multiple keys or mouse buttons hit > at once > is very poor. > This is where frameworks can help. Now that Javascript performance is > barrelling ahead, frameworks start looking much more attractive. I've used > GWT (Java->Javascript) in the past, and input handling feels exactly like it > does in SWT or Swing (the leading Java UI frameworks). > > > f) Very little state across loads (though html5 is adding something for > this, if > it ever gets broad penetration), mentioned mainly for completeness, since > javascript variables do work for must things, but your persistent database > still > has to be on the server. > As you said, HTML5. My internet was down this morning, but I was still able > to read the batch of mail in GMail that I downloaded last night because > GMail is already taking advantage of Google Gears, which provides similar > functionality. I get the same thing with a few other web applications. > > > g) No threading. I recently tried making a javascript -> d caller. In D, > this > would be trivial: opDispatch means no code needs to be written, and if it > runs in > a different thread from the rest of the UI, it can make sync calls to the > server > without freezing everything up, thus letting it be written in a linear > style. > HTML5 adds WebWorkers, which handle exactly this use case (among others). > I should also note that every HTML5 feature I mentioned here except WebSockets is also supported in Firefox 3.5. IE9 supports everything but WebSockets and WebWorkers. (Apparently there's some trouble with the WebSockets specification at the moment)
Re: type classes for selection of template variant
> D does not need any new language feature: interfaces are perfect > for that. No, interfaces imply overhead at runtime and they are only supported by classes.
Re: Slides from my ACCU Silicon Valley talk
"Lars T. Kyllingstad" wrote: > And if someone *really* wants to put the "i" in there, they can just > define it in their own app: > > enum i = Complex!double(0, 1); > auto z = 0.998 + 2.72e-2*i; > > -Lars > Looks very nice.
Re: emscripten
On Wed, Dec 15, 2010 at 9:37 AM, Adam D. Ruppe wrote: > > And in those rare cases where you are doing a lot of client side work, it > is so > brutally slow that if you start piling other runtimes on top of it, you'll > often > be left with an unusable mess anyway! Unless you're using the beta of the next IE, the beta of the next Opera, or the current version of Chrome, in which case you'd find that client-side work is becoming more and more feasible. Now, it's not there yet, but when a C-ported-to-Java-compiled-to-Javascript version of Quake 2 can get 30FPS in Google Chrome, I start thinking that performance probably won't be nearly as bad as browsers move forward. You don't have to like it, but there's a huge push in web development towards doing more work on the client, and now that browsers are catching up, it's going to change the way the web works. As for the rest: a) No real time networking HTML 5 WebSockets, as you said b) Cross domain communication requires ugly, inefficient hacks, or a proxy on your server. This is the one thing you've listed that's not going to change because it poses a security risk. c) No sounds (without flash anyway). Included in HTML 5. d) Graphics, even if you grant the canvas element, are a joke. The latency is brutal. Take that deviant art thing from earlier in the thread. Flick your mouse, and watch the lines slowly catch up to you! Using X11 with a remote server is faster than that. In Chrome (even the version a year or so old that is installed on the lab computer I'm using right now), there is no latency whatsoever. That's a simple matter of javascript performance, which is dramatically improving. e) Input requires a lot of magic. Some keys have the same identifiers, some of the time, meaning just checking for keypress requires dozens of lines of code, and still doesn't work right! Checking for multiple keys or mouse buttons hit at once is very poor. This is where frameworks can help. Now that Javascript performance is barrelling ahead, frameworks start looking much more attractive. I've used GWT (Java->Javascript) in the past, and input handling feels exactly like it does in SWT or Swing (the leading Java UI frameworks). f) Very little state across loads (though html5 is adding something for this, if it ever gets broad penetration), mentioned mainly for completeness, since javascript variables do work for must things, but your persistent database still has to be on the server. As you said, HTML5. My internet was down this morning, but I was still able to read the batch of mail in GMail that I downloaded last night because GMail is already taking advantage of Google Gears, which provides similar functionality. I get the same thing with a few other web applications. g) No threading. I recently tried making a javascript -> d caller. In D, this would be trivial: opDispatch means no code needs to be written, and if it runs in a different thread from the rest of the UI, it can make sync calls to the server without freezing everything up, thus letting it be written in a linear style. HTML5 adds WebWorkers, which handle exactly this use case (among others).
Re: Paralysis of analysis -- the value/ref dilemma
On Wed, 15 Dec 2010 09:56:36 -0600
Andrei Alexandrescu wrote:
> Optimization (or pessimization) is a concern, but not my primary one. My
> concern is: most of the time, do you want to work on a container or on a
> copy of the container? Consider this path-of-least-resistance code:
>
> void fun(Container!int c) {
> ...
> c[5] += 42;
> ...
> }
>
> Question is, what's the most encountered activity? Should fun operate on
> whatever container it was passed, or on a copy of it? Based on extensive
> experience with the STL, I can say that in the overwhelming majority of
> cases you want the function to mess with the container, or look without
> touch (by means of const). It is so overwhelming, any code reviewer in
> an STL-based environment will raise a flag when seeing the C++
> equivalent to the code above - ironically, even if fun actually does
> need a copy of its input! (The common idiom is to pass the container by
> constant reference and then create a copy of it inside fun, which is
> suboptimal.)
I do agree.
When a container is passed as parameter
* either it is a value in meaning and should be left unchanged (--> so that the
compiler can pass it as "constant reference")
* or it means an entity with identity, it makes sense to change it, and it
should be implemented as a ref.
What I'm trying to fight is beeing forced to implement semantics values as
concrete ref elements. This is very bad, a kind of conceptual distortion (the
author of XL calls this semantic mismatch) that leads to much confusion.
Example of semantic distinction:
Take a palette of predefined colors (red, green,..) used to draw visual
widgets. In the simple case, colors are plain information (=values), and the
palette (a collection) as well. In this case, every widget holds its own subset
of colors used for each part of itself. Meaning copies. Chenging a given color
assigned to a widget should & does not affect others.
Now, imagine this palette can be edited "live" by the user, meaning redefining
the components of re, green,... This time, the semantics may well be that such
changes should aaffect all widgets, including already defined ones. For this,
the palette must be implemented as an "entity", and each as well. But the
reason for this is that the palette does not mean the same thing at all:
instead of information about an aspect (color) of every widget, we have now a
kind of container of color _sources_. Instead of color values, the widget
fields point to kinds of paint pots; these fields should not be called "color".
[It is not always that simple to find real-world metaphors helping us and
correctly understand what we have to model and write into programs. A program's
world is not at all reality, not even similar to it, even in the (minority of)
cases where it models reality. In this case, "color" is misleading.]
In the first case, palette must be a value, in the second case it must be a
ref. There is no way to escape the dilemma about having value or ref
collections. Conceptually, we absolutely need both. Again the ref/value
semantic duality is independant from data types. If the language provides one
kind only, we have to hack, to cheat with it.
There is a special case in non-OO-only cisconstances: sometimes an element is
passed as parameter while it is conceptually the "object" (in common sense) on
which an operation applies (~ OO receiver). In OO, it would be passed by ref
precisely to allow it beeing changed, even if it is a plain value (this
prevents creating a new value at every tiny chenge, as opposed to
immutability). But this relevant distinction between object of an operation
(what) and true parameters (how) does not exist in plain function-based style:
func(object, param1, param12);
So that we have to pass the object by ref when the operation is precisely here
to modify it. But conceptually it is not a parameter.
> In contrast, most of the time you want to work on a copy of a string, so
> strings are commonly not containers. (This is nicely effected by string
> being defined as arrays of immutable characters.) However, you sometimes
> do need to mutate a string, which is why char[] is useful on occasion.
I agree with this as well. Do does the right thing for strings.
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
Re: Slides from my ACCU Silicon Valley talk
On 12/15/2010 08:34 AM, Lars T. Kyllingstad wrote: And if someone *really* wants to put the "i" in there, they can just define it in their own app: enum i = Complex!double(0, 1); auto z = 0.998 + 2.72e-2*i; -Lars or Complex!"0.998 + 2.72e-2i"
Re: Why Ruby?
On 12/15/10, Stephan Soller wrote:
>
> So, _if_ we can figure out a way to do some nice chaining of such calls
> we can get:
>
> [1, 2, 3, 4, 5].filter!((e){ return e > 3; })
> .map!((e){ return e*e; });
>
> Or if you don't like delegates and don't mind obvious compile time black
> magic:
>
> [1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");
>
You might use pipe! as an alternative:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
auto result = pipe!( filter!("a>3"), map!("a * a") )(arr);
writeln(result);
}
But I can't seem to do the same with delegates:
import std.algorithm;
import std.functional;
import std.stdio;
void main()
{
int[] arr = [1, 2, 3, 4, 5];
pipe!( filter!( (e){ return e > 3; } ),
map!( (e){ return e*e; } ) )(arr);
}
chain.d(9): Error: expression template filter(Range) is not a valid
template value argument
chain.d(9): Error: expression template map(Range) is not a valid template
value argument
Re: Why Ruby?
On 14.12.2010 20:03, Jacob Carlborg wrote:
On 2010-12-14 19:33, Stephan Soller wrote:
I think it's a matter of consistency. In Ruby blocks are used all the
time for pretty much everything. In D this isn't the case because
usually templates are used for stuff where blocks are used in Ruby
(e.g.
map, group and find in std.algorithm).
I think that the templates that take a string as a predicate is just an
ugly hack because D has a too verbose delegate syntax.
I absolutely agree with that. However I don't have a better idea how to
write it. Delegate syntax is already fairly compact in D.
For example code as this isn't very uncommon in Ruby:
[1, 2, 3, 4, 5].select{|e| e > 3}.collect{|e| e*e}
Of course this is a simplified example. Usually the collection would
contain some objects and the blocks would filter for a method call (like
"e.even?"). However I built a small D1 struct that implements a select
and collect function. With the unified function call synatax for array
with code should actually work:
[1, 2, 3, 4, 5].select((int e){ return e > 3; })
.collect((int e){ return e*e; });
It's already fairly compact. The main overhead is the parameter type and
the return statement. I don't believe this can be reduced any more
without breaking consistency of the language.
Probably not, but, for example, Scala allows very compact delegate
literals:
Array(1, 2, 3, 4, 5).select(_ > 3).collect(_ * _)
Or more verbose:
Array(1, 2, 3, 4, 5).select((x) => x > 3).collect((x, y) => x * y)
I'm not 100% sure I that the syntax is correct.
Delegates are way more verbose in other languages like PHP and
JavaScript (more or less the same syntax in both languages). Despite
that it's no problem to use it and in case of jQuery it's used very
often. I think the main reason why delegates are not used like that in D
is performance. I'm really not sure about it but I suspect that
delegates are less effective than code directly generated by a template
like map!(). I don't know how efficient templates can integrate
delegates so I just suspect that this is a performance problem.
Happy programming
Stephan Soller
PHP has a very verbose delegate syntax with explicit closures, one of
the many reasons I don't use PHP. JavaScript has quite similar syntax as
D but the "function" keyword is required, I try to use CoffeeScript
(compiles to javascript), which has a lot nicer delegate syntax, as
often I can.
D(dmd) needs to be able to inline delegates.
I'm not so much concerned about verbose delegate syntax. Personally I
don't mind using the current delegate syntax with templates like map!.
However I'm concerned about performance and parameter order. Does
someone know how delegates within templates are handled? I looked at the
source of std.algorithm and std.functional but I'm still not sure what
actually happens if you call something like
auto ary = [1, 2, 3];
map!((e){ return e*e; })(ary);
I can't test this code right now since I don't have a D2 compiler
installed at this computer but the std.algorithm source contains unit
tests with delegates.
If that now works with uniform function call syntax it could be written
like that:
auto ary = [1, 2, 3];
ary.map!((e){ return e*e; });
I don't know if chaining of such calls is possible but the above syntax
is already pretty good. Sure, it's not perfect and the "return" still is
some overhead, but I don't think it needs work. What's more important
(at least for me) is the chaining ability and how performant such
delegates actually are. From what I understood from std.functional it
wraps string expressions in delegates anyway so using
ary.map!("a*a");
is not more efficient. Please correct me if I'm wrong! The
std.functional code is definitely above my understanding.
So, _if_ we can figure out a way to do some nice chaining of such calls
we can get:
[1, 2, 3, 4, 5].filter!((e){ return e > 3; })
.map!((e){ return e*e; });
Or if you don't like delegates and don't mind obvious compile time black
magic:
[1, 2, 3, 4, 5].filter!("a > 3").map!("a * a");
I think if chaining would work like that D would already be pretty close
to the expressive power of Ruby. It's just that this kind of programming
is very dependent on the ability of built in collections and libraries
that allow such a programming style.
Happy programming
Stephan Soller
Re: Paralysis of analysis -- the value/ref dilemma
On 12/15/10 8:34 AM, spir wrote:
On Tue, 14 Dec 2010 13:53:39 -0600 Andrei
Alexandrescu wrote:
Coming from an STL background I was also very comfortable with the
notion of value. Walter pointed to me that in the STL what you
worry about most of the time is to _undo_ the propensity of objects
getting copied at the drop of a hat. For example, think of the
common n00b error of passing containers by value.
So since we have the opportunity to decide now for eternity the
right thing, I think reference semantics works great with
containers.
The issue for me in your reasoning is that what you are here talking
about, and what your choice is based on, is _not_ reference
_semantics_, but something like "indirection efficiency". This is
optimization that clearly belongs to implementation and has nothing
to do with semantics.
Optimization (or pessimization) is a concern, but not my primary one. My
concern is: most of the time, do you want to work on a container or on a
copy of the container? Consider this path-of-least-resistance code:
void fun(Container!int c) {
...
c[5] += 42;
...
}
Question is, what's the most encountered activity? Should fun operate on
whatever container it was passed, or on a copy of it? Based on extensive
experience with the STL, I can say that in the overwhelming majority of
cases you want the function to mess with the container, or look without
touch (by means of const). It is so overwhelming, any code reviewer in
an STL-based environment will raise a flag when seeing the C++
equivalent to the code above - ironically, even if fun actually does
need a copy of its input! (The common idiom is to pass the container by
constant reference and then create a copy of it inside fun, which is
suboptimal.)
In contrast, most of the time you want to work on a copy of a string, so
strings are commonly not containers. (This is nicely effected by string
being defined as arrays of immutable characters.) However, you sometimes
do need to mutate a string, which is why char[] is useful on occasion.
Andrei
Re: type classes for selection of template variant
On Wed, 15 Dec 2010 07:58:36 -0500, spir wrote:
Hello,
see http://en.wikipedia.org/wiki/Type_class
I have tried several times to express the idea of using intervaces
(only) for template case selection. Instead of a combination of really
penible & hardly readible is() expressions and adhoc functions like
isRandomAccessRange. (No chance in these trials ;-)
Just discovered this idea is actually the same as 'type classes'
introduced in Haskell (not that I'm a fan of functional programming,
just stepped on the article by chance).
D does not need any new language feature: interfaces are perfect for
that.
Maybe the syntax could be slightly extended to allow expressing negative
constraints, like the following (defining an interface for types that
support '==', but not comp)
interface EqualityOnly : Equality !: Comparable {}
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
No new syntax is required: templates can already test whether two types
are similar in a 'duck' sense today, thanks to compile time reflection.
Re: write, toString, formatValue & range interface
On Wed, 15 Dec 2010 04:48:43 -0500, spir wrote: On Tue, 14 Dec 2010 09:35:20 -0500 "Robert Jacques" wrote: Having recently run into this without knowing it, Which one? (This issue causes 3 distinct bugs.) A struct + opDispatch combination resulted in a compile time error for me. Of course, since the opDispatch routine returned itself, I figure an infinite loop would have occurred if it did compile. Right now, I've added template constraints, but it is a suboptimal solution to the problem.
Re: emscripten
All of your complaints are about specific choices of the developers, not the technology. Right now, javascript and web apps are being written (for the most part) by young, inexperienced, often graphically-oriented individuals. Soon, more experience developers will join the scene and start writing useful apps that aren't just eye-candy. >Any my emails are *my* emails, stored on my local box. If I want to back it up, just copy the file. If I want a search that actually works, I can just grep the file, and so on. Just better in every way. The vast majority of people appreciate that they just get all that for free and without bother in gmail, hotmail, yahoo, etc. -Mike On Wed, Dec 15, 2010 at 9:47 AM, Adam D. Ruppe wrote: > Nick Sabalausky wrote: > > Text editors that rely on JavaScript are abominations, period. > > Any widget that does sucks IMO. I've had to use javascript replacements of > the > standard tag too, and wow it blows. > > Wait for its animation to start up. Wait for its animation to finish. Click > an > option it didn't work, sorry my browser isn't good enough. > > Usually I just abandon the site, but sometimes I can't. So switch to > firefox 3. > Wait for the animation to start up. Wait for it to finish. Click the thing. > Wait > for it to animate again. Oops, I got the wrong option, I'll just hit the > down > arrow sorry, didn't work. > > Aargghh! > > "but but look at the super cool animations jquery is amazing! and i can > style this > thing better than the built in so nyah" > > Gah. > > > > Look, look -> There's my cake, and I'm eating it! > > This is one thing I love about running mutt in screen. If I have access to > my home > box at all (directly or ssh) it works well. If I left a message half read, > when I > come back to it, it is still half read! No need to hunt it down again among > the > read messages, no need to scroll back to my original position. The screen > is > *exactly* as I left it. > > Any my emails are *my* emails, stored on my local box. If I want to back it > up, > just copy the file. If I want a search that actually works, I can just grep > the > file, and so on. Just better in every way. >
Re: Why Ruby?
On 14.12.2010 19:49, Simen kjaeraas wrote:
Stephan Soller wrote:
[1, 2, 3, 4, 5].select((int e){ return e > 3; })
.collect((int e){ return e*e; });
It's already fairly compact. The main overhead is the parameter type
and the return statement. I don't believe this can be reduced any more
without breaking consistency of the language.
The delegates can be passed by alias parameter, and then be written
without the parameter type:
@property void bar(alias t)() {
t(3);
}
void main() {
bar!((e){writeln(e);});
}
Hm, nice trick, thanks Simen. Looks interesting and more general to use.
Will try that for my next D project.
Happy programming
Stephan Soller
Re: Slides from my ACCU Silicon Valley talk
On Wed, 15 Dec 2010 14:34:47 + (UTC) "Lars T. Kyllingstad" wrote: > And if someone *really* wants to put the "i" in there, they can just > define it in their own app: > > enum i = Complex!double(0, 1); > auto z = 0.998 + 2.72e-2*i; +++ Denis -- -- -- -- -- -- -- vit esse estrany ☣ spir.wikidot.com
