On Monday, 24 August 2015 at 15:09:14 UTC, Michal Minich wrote:
What are the advantages of current design.
One advantage of the current design is you can statically
determine if something is an infinite range by seeing if empty is
a constant false. With your change, you could never be sure
I'm thinking about ranges I can think of similar design of the
input range, but with different pros and cons. Obviously not
for/in D. Currently ranges has 3 primitive operations, and they
can be translated from foreach like:
for (auto __r = range; !__r.empty; __r.popFront())
{
auto e =
On Mon, Aug 24, 2015 at 03:16:10PM +, Adam D. Ruppe via Digitalmars-d-learn
wrote:
On Monday, 24 August 2015 at 15:09:14 UTC, Michal Minich wrote:
What are the advantages of current design.
One advantage of the current design is you can statically determine if
something is an infinite
I saw https://issues.dlang.org/show_bug.cgi?id=14956 .
questions:
- is std.basic_string released into the wild?
- where do I find std.basic_string?
- does std.vector exist? That would allow me to get rid of some
C++ clue code (build an C-like interface, copy data etc)...
Putting
extern(C++)
On Monday, 24 August 2015 at 09:18:14 UTC, Robert M. Münch wrote:
On 2015-08-23 20:13:38 +, Vladimir Panteleev said:
Not really sure what's going on there... If I could reproduce
it, I'd try building DMD manually - if it still occurred,
build DMD 2.067.1 from source and add debugging
On Monday, 24 August 2015 at 01:01:13 UTC, John Colvin wrote:
enum A = 1;
enum B = C; //Error
static if(A)
enum C = 0;
enum D = C; //OK
Is order supposed to matter here?
No.
On Monday, 24 August 2015 at 15:16:12 UTC, Adam D. Ruppe wrote:
One advantage of the current design is you can statically
determine if something is an infinite range by seeing if empty
is a constant false.
That is important aspect! By having this information at compile
or runtime, you can
On Monday, 24 August 2015 at 15:23:09 UTC, H. S. Teoh wrote:
It's also useful in parsing algorithms to look at the current
item in the input without also consuming it.
I design I outlined the 'front' property could still be called
multiple times. It is the 'empty' property that would be
Looking at the random access range, if the indexing must be done
just by numeric value, or also by other type, like string
(typically used for dictionaries) or also custom object?
On 8/24/15 11:09 AM, Michal Minich wrote:
I'm thinking about ranges I can think of similar design of the input
range, but with different pros and cons. Obviously not for/in D.
Currently ranges has 3 primitive operations, and they can be translated
from foreach like:
for (auto __r = range;
On Monday, 24 August 2015 at 17:17:16 UTC, Steven Schveighoffer
wrote:
3) it is not possible to ask a range if it's empty more
times per
iteration of one item
This isn't very composable. If I call a function that consumes
some number of items from a range, that function needs to
forward the
On Monday, 24 August 2015 at 09:50:41 UTC, yawniek wrote:
On Friday, 21 August 2015 at 21:08:25 UTC, Laeeth Isharc wrote:
I guess this kind of thing will do:
upRangeHighs.each!((ref a)=(++histogram[a][0]));
int[] arr = [5,1,2,2,3,4,5,5,5];
int[int] histo;
arr.each!( a =
auto names =
Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf
Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe
Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split;
foreach (ref name; names)
try:
auto names1 = names.map!( a = replace(a, _, ));
...not sure how to do it in-place though.
Joel wrote:
auto names =
Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf
Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe
Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split;
On 2015-08-24 07:58, Joel wrote:
auto names =
Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf
Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe
Pe Final_Tsadi Tsadi Qof Resh Shin Tav.split;
foreach (ref name; names)
On 2015-08-22 21:14, nims wrote:
Using Orange all I got was a lot of compiler errors.
Seems I completely overlooked interfaces. I'll see if I can add support
for them.
--
/Jacob Carlborg
On Sun, 23 Aug 2015 16:00:16 +, Tony wrote:
Thanks for the replies. It compiles OK with just. However, it isn't
linking:
/usr/bin/ld: cannot find -lcurl
I do have some versions of libcurl on my system:
/usr/lib/x86_64-linux-gnu/libcurl.so.3
On Monday, 24 August 2015 at 06:13:50 UTC, Jacob Carlborg wrote:
On 2015-08-24 07:58, Joel wrote:
auto names =
Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod
Final_Kaf
Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh
Ayin Final_Pe
Pe Final_Tsadi Tsadi
On Monday, 24 August 2015 at 09:13:56 UTC, Robert M. Münch wrote:
On 2015-08-23 16:23:57 +, John Colvin said:
almost certainly a consequence of the recent switchover to the
dmd frontend being written in D. Have you tried building the
latest Digger git HEAD first? If that doesn't work I
On Monday, 24 August 2015 at 06:17:02 UTC, ted wrote:
try:
auto names1 = names.map!( a = replace(a, _, ));
...not sure how to do it in-place though.
Joel wrote:
auto names =
Alef Bet Gimel Dalet He Vav Zayen Het Tet Yod Final_Kaf
Kaf Lamed Final_Mem Mem Final_Nun Nun Samekh Ayin Final_Pe
On Friday, 21 August 2015 at 17:05:56 UTC, John Colvin wrote:
On Friday, 21 August 2015 at 14:35:53 UTC, Chris wrote:
On Friday, 21 August 2015 at 12:59:09 UTC, John Colvin wrote:
[...]
Wouldn't it be easier to have a library function that can
empty the mailbox immediately? It's a waste of
On Friday, 21 August 2015 at 21:08:25 UTC, Laeeth Isharc wrote:
I guess this kind of thing will do:
upRangeHighs.each!((ref a)=(++histogram[a][0]));
int[] arr = [5,1,2,2,3,4,5,5,5];
int[int] histo;
arr.each!( a = ++histo[a] );
writeln(histo);
this works
On 2015-08-23 16:23:57 +, John Colvin said:
almost certainly a consequence of the recent switchover to the dmd
frontend being written in D. Have you tried building the latest Digger
git HEAD first? If that doesn't work I suggest reporting it here for
Vladimir (CyberShadow) to look at:
On Monday, 24 August 2015 at 09:26:40 UTC, Edwin van Leeuwen
wrote:
On Saturday, 22 August 2015 at 19:14:16 UTC, nims wrote:
Painlessjson indeed does not support interfaces/subclasses at
the moment. There was some discussion about it here:
https://github.com/BlackEdder/painlessjson/issues/8 ,
On Saturday, 22 August 2015 at 19:14:16 UTC, nims wrote:
I think interfaces are very powerful and I heavily use them.
The only problem I have with them is that
serializing/deserializing them to XML or JSON doesn't seem to
work. So far I got to try Orange and painlessjson. Using Orange
all I
On 2015-08-23 20:13:38 +, Vladimir Panteleev said:
Not really sure what's going on there... If I could reproduce it, I'd
try building DMD manually - if it still occurred, build DMD 2.067.1
from source and add debugging printfs to see why it's not finding
verstr.h.
I'm not building
On 2015-08-24 11:01:47 +, John Colvin said:
Is this from a clean clone of Digger, either with --recursive or having
done git submodule update --init ? What version of DMD are you using to
build it?
Hi, no it was not. Doing a git submodule update --init fixed this
problem. After this,
On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote:
For Python and native code, D is a great fit, perhaps more so
that Rust, except that Rust is getting more mind share,
probably because it is new.
I'm of the opinion that Rust's popularity will quickly die when
people realize
On Sun, 2015-08-23 at 19:42 +, via Digitalmars-d-learn wrote:
[…]
Yes, of course it is, but given it's typical use context I find
it odd that they didn't go more towards higher level constructs.
For me Go displaces Python where more speed is required, though I
wish it was more
. Of course systems like Numba change the Python performance
game, which undermines D's potential in the Python-verse, as it
does C and C++. Currently I am investigating
Python/Numba/Chapel as the way of doing performance computing.
Anyone who just uses Python/NumPy/SciPy is probably not doing
I happened to notice that among my libcurl*s
libcurl-gnutls.so.3
libcurl-gnutls.so.4
libcurl-gnutls.so.4.3.0
libcurl.so.3
libcurl.so.4
libcurl.so.4.3.0
none were just libcurl.so. So I made a link for libcurl.so to the
latest version and now I am getting the same link errors I got
after
On Monday, 24 August 2015 at 06:28:34 UTC, Yazan D wrote:
On Sun, 23 Aug 2015 16:00:16 +, Tony wrote:
Thanks for the replies. It compiles OK with just. However, it
isn't linking:
/usr/bin/ld: cannot find -lcurl
I do have some versions of libcurl on my system:
On Sunday, 23 August 2015 at 16:20:04 UTC, Gerald Jansen wrote:
On Sunday, 23 August 2015 at 16:00:19 UTC, Tony wrote:
/usr/bin/ld: cannot find -lcurl
Just the other day I had a similar problem (compiling vibenews,
ld complained of missing -levent and -lssl), which I managed to
solve simply
http://www.nytimes.com/2015/08/23/magazine/the-creative-apocalypse-that-wasnt.html
Interesting article as it corrects misconceptions of a few years
back by looking at the data. This is based on tools from EMSI,
who are a D shop.
Congratulations to EMSI, and it would be great to hear more
On Monday, 24 August 2015 at 21:57:41 UTC, rsw0x wrote:
On Monday, 24 August 2015 at 21:20:39 UTC, Russel Winder wrote:
For Python and native code, D is a great fit, perhaps more so
that Rust, except that Rust is getting more mind share,
probably because it is new.
I'm of the opinion that
35 matches
Mail list logo
