On Saturday, 28 May 2016 at 04:31:22 UTC, Manu wrote:
On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d
wrote:
I've been working on RCStr (endearingly pronounced "Our
Sister"),
Ah, I totally skipped over this thread...
Wow... this really doesn't work in any accent I'm close to,
On 27 May 2016 at 02:11, Andrei Alexandrescu via Digitalmars-d
wrote:
> I've been working on RCStr (endearingly pronounced "Our Sister"),
Ah, I totally skipped over this thread...
Wow... this really doesn't work in any accent I'm close to, but I can
hear it if I imagine you saying it ;)
If I sai
On 27 May 2016 at 23:32, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/27/16 7:07 AM, Marc Schütz wrote:
>>
>> On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
>>>
>>> RFC: what primitives should RCStr have?
>>
>>
>> It should _safely_ convert to `const(char)[]`.
>
>
> Th
On 28 May 2016 at 10:16, Adam D. Ruppe via Digitalmars-d
wrote:
> On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote:
>>
>> not if [] would be ref-counted too ;-)
>
>
> That would be kinda horrible. Right now, slicing is virtually free and
> compatible with all kinds of backing schemes. If it becam
On Friday, May 27, 2016 23:42:24 Seb via Digitalmars-d wrote:
> So what about the convention to explicitely declare a
> `.transient` enum member on a range, if the front element value
> can change?
Honestly, I don't think that supporting transient ranges is worth it. Every
single range-based funct
On 05/27/2016 06:19 PM, qznc wrote:
manual find: 118 ±24
qznc find: 109 ±13 <--- using the sentinel trick
Chris find: 142 ±27
It is normal that the numbers of the other tests change, since those are
relative to the fastest one in each run. When qznc find 'wins' more
often, the others get mor
On Fri, May 27, 2016 at 04:41:09PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 05/27/2016 03:43 PM, H. S. Teoh via Digitalmars-d wrote:
> > That's what we've been trying to say all along!
>
> If that's the case things are pretty dire, autodecoding or not. --
> Andrei
Like it or not,
On 05/27/2016 06:09 PM, tsbockman wrote:
On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 05:02 PM, Era Scarecrow wrote:
With the current state of things, I'll just take your word on it.
Reasoning is simple - yes we could safely convert to const(char)[] but
t
On Friday, 27 May 2016 at 22:09:48 UTC, tsbockman wrote:
But conversions to scope const(char)[] could be made safe,
right? (If scope were ever fully implemented, that is.)
Indeed, and I really think we should spend more effort on making
this work. Not as much as Rust spends on it, but a lil mo
On Friday, 27 May 2016 at 21:51:59 UTC, Seb wrote:
not if [] would be ref-counted too ;-)
That would be kinda horrible. Right now, slicing is virtually
free and compatible with all kinds of backing schemes. If it
became refcounted, it'd:
1) have to keep a pointer to the refcount structure w
A couple of weeks ago on the next/shift convenience wrapper
discussion [1], there was a nice discussion about transient
ranges. It didn't come to a conclusion, so let's revie it. I just
cite the best three quotes from the thread as a summary:
jmdavis:
The reality of the matter is that ranges
On 5/27/2016 11:27 AM, Andrei Alexandrescu wrote:
On 5/27/16 1:11 PM, Walter Bright wrote:
They mean code units.
Always valid or potentially invalid as well? -- Andrei
Some years ago I would have said always valid. Experience, however, says that
Unicode is often dirty and code should be tol
On Friday, 27 May 2016 at 22:12:57 UTC, Minas Mina wrote:
Those should be the same though, i.e compare the same. In order
to do that, there is normalization. What is does is to _expand_
the single codepoint Ä into A + ¨
Unless I'm mistaken, this depends on the form used. For example,
in NFKC
On Friday, 27 May 2016 at 18:21:06 UTC, Andrei Alexandrescu wrote:
What you want to do here for indexed access is to match the
last element first. If no match, continue etc. If there's a
match, enter an inner loop where you don't need to check for
the end of the haystack. -- Andrei
Another pl
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length
== 2
Would normalization make len
On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 05:02 PM, Era Scarecrow wrote:
With the current state of things, I'll just take your word
on it.
Reasoning is simple - yes we could safely convert to
const(char)[] but that means effectively all refcounting is
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
No, this is not the point of normalization.
What is? -- Andrei
1) A grapheme may include several combining characters (such as
diacritics) whose order is not supposed to be sem
On Friday, 27 May 2016 at 20:42:13 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length
== 2
Would normalization make len
On Friday, 27 May 2016 at 21:25:50 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 05:02 PM, Era Scarecrow wrote:
With the current state of things, I'll just take your word
on it.
Reasoning is simple - yes we could safely convert to
const(char)[] but that means effectively all refcounting is
On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote:
I have to correct myself. A manual loop is faster, I couldn't
believe it either, so I benchmarked the same function with
`foreach` and `for`. Turns out that `for` is _way_ faster.
Just about the only reason I could think of for this to happe
On 05/27/2016 05:02 PM, Era Scarecrow wrote:
With the current state of things, I'll just take your word on it.
Reasoning is simple - yes we could safely convert to const(char)[] but
that means effectively all refcounting is lost for that string. So we
can convert but in an explicit manner,
On Friday, 27 May 2016 at 20:50:52 UTC, Andrei Alexandrescu wrote:
On 05/27/2016 04:39 PM, qznc wrote:
Now added Chris' algo to the benchmark:
std find:155 ±33
manual find: 112 ±19
qznc find: 122 ±18 <--- improved find
Chris find: 133 ±20 <--- findStringS_
Does any of these feature s
On Friday, 27 May 2016 at 13:32:30 UTC, Andrei Alexandrescu wrote:
On 5/27/16 7:07 AM, Marc Schütz wrote:
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu
wrote:
RFC: what primitives should RCStr have?
It should _safely_ convert to `const(char)[]`.
That is not possible, sorry.
On 05/27/2016 04:39 PM, qznc wrote:
Now added Chris' algo to the benchmark:
std find:155 ±33
manual find: 112 ±19
qznc find: 122 ±18 <--- improved find
Chris find: 133 ±20 <--- findStringS_
Does any of these feature simultaneously:
* check the last element first
* consequently stop e
On 05/27/2016 03:39 PM, Dmitry Olshansky wrote:
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length == 2
Would normalization make length 1? -- Andrei
No, this is not the point of normalization.
Wha
On 05/27/2016 03:35 PM, Pete wrote:
If anyone calls, Jack and I will be over at stack overflow gleefully
closing down the derailers there.
Thanks for that. Not sure what your moniker is there, but I noticed a
good number of solid answers to D questions on SO.
Regarding the title, it was actu
On 05/27/2016 03:43 PM, H. S. Teoh via Digitalmars-d wrote:
That's what we've been trying to say all along!
If that's the case things are pretty dire, autodecoding or not. -- Andrei
Now added Chris' algo to the benchmark:
std find:155 ±33
manual find: 112 ±19
qznc find: 122 ±18 <--- improved find
Chris find: 133 ±20 <--- findStringS_
https://github.com/dlang/phobos/pull/4372
What do you all think? Fortunately we're not breaking "any" code because
well we're in experimental! :o) -- Andrei
On Friday, 27 May 2016 at 19:35:58 UTC, Pete wrote:
read the subject line slowly Jack
Sorry about that. I use the web interface and everything is
grouped together even if it doesn't have the same subject line,
so I didn't see that you changed it.
On Fri, May 27, 2016 at 07:53:30PM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Friday, 27 May 2016 at 19:30:53 UTC, Andrei Alexandrescu wrote:
> > It seems code points are kind of useless because they don't really
> > mean anything, would that be accurate? -- Andrei
>
> It might help to thi
On 5/27/16 3:30 PM, Andrei Alexandrescu wrote:
On 5/27/16 3:10 PM, ag0aep6g wrote:
I don't think there is value in distinguishing by language. The point of
Unicode is that you shouldn't need to do that.
It seems code points are kind of useless because they don't really mean
anything, would tha
On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote:
The improved `std find` comes very close to the manual function
above now, sometimes it's even faster or at least as fast.
std findtook 12573666
manual find took 7418454
my std find took 6903854 <===
findStringS
On Friday, 27 May 2016 at 19:30:53 UTC, Andrei Alexandrescu wrote:
It seems code points are kind of useless because they don't
really mean anything, would that be accurate? -- Andrei
It might help to think of code points as being a kind of byte
code for a text-representing VM.
It's not meani
On Fri, May 27, 2016 at 03:30:53PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/27/16 3:10 PM, ag0aep6g wrote:
> > I don't think there is value in distinguishing by language. The
> > point of Unicode is that you shouldn't need to do that.
>
> It seems code points are kind of useless
On Fri, May 27, 2016 at 02:42:27PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 5/27/16 12:40 PM, H. S. Teoh via Digitalmars-d wrote:
> > Exactly. And we just keep getting stuck on this point. It seems that
> > the message just isn't getting through. The unfounded assumption
> > contin
On 05/27/2016 09:30 PM, Andrei Alexandrescu wrote:
It seems code points are kind of useless because they don't really mean
anything, would that be accurate? -- Andrei
I think so, yeah.
Due to combining characters, code points are similar to code units: a
Unicode thing that you need to know ab
On 27-May-2016 21:11, Andrei Alexandrescu wrote:
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length == 2
Would normalization make length 1? -- Andrei
No, this is not the point of normalization.
--
Dmitry Olshansky
and tag it OT.<<
read the subject line slowly Jack
..but I appreciate your witty use of the word derail.
If anyone calls, Jack and I will be over at stack overflow
gleefully closing down the derailers there.
On Friday, 27 May 2016 at 17:37:20 UTC, Jack Stouffer wrote:
On Friday, 27 May 20
On 5/27/16 1:11 PM, Walter Bright wrote:
The std.string algorithms I wrote all work much better (i.e. faster)
without autodecoding, while maintaining proper Unicode support.
Violent agreement is occurring here. We have plenty of those and need
more. -- Andrei
On Friday, 27 May 2016 at 19:17:44 UTC, Chris wrote:
Oops, I've been found out. :-) Thanks. You're right of course,
and I've already noticed that bug as it fails on not found. I
got the bounds wrong.
I had the same "bug" when I wrote my search function on the
project at work. I also found out
On 5/27/16 3:10 PM, ag0aep6g wrote:
I don't think there is value in distinguishing by language. The point of
Unicode is that you shouldn't need to do that.
It seems code points are kind of useless because they don't really mean
anything, would that be accurate? -- Andrei
Oops, I've been found out. :-) Thanks. You're right of course,
and I've already noticed that bug as it fails on not found. I got
the bounds wrong.
On 05/27/2016 08:42 PM, Andrei Alexandrescu wrote:
Which languages are covered by code points, and which languages require
graphemes consisting of multiple code points? How does normalization
play into this? -- Andrei
I don't think there is value in distinguishing by language. The point of
Uni
On 2016-05-27 15:12, Atila Neves wrote:
I get an SSL warning for that link.
Hmm, here's the code inline:
module red;
import std.stdio;
import core.sys.posix.sys.mman : mprotect, PROT_NONE, PROT_READ,
PROT_WRITE, PROT_EXEC;
import core.stdc.errno : errno;
import core.stdc.string : memmove,
On 5/27/16 12:40 PM, H. S. Teoh via Digitalmars-d wrote:
Exactly. And we just keep getting stuck on this point. It seems that the
message just isn't getting through. The unfounded assumption continues
to be made that iterating by code point is somehow "correct" by
definition and nobody can challe
On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote:
On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote:
This outperforms both `manual_find` and the improved `std find`
string findStringS_Manual(string haystack, string needle)
{
if (needle.length > haystack.length)
On 5/27/16 1:11 PM, Walter Bright wrote:
They mean code units.
Always valid or potentially invalid as well? -- Andrei
On Sunday, 24 January 2016 at 02:51:43 UTC, Jonathan M Davis
wrote:
Regardless, I for one, hope that we never have named arguments.
Whops.
https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d
:D
On 5/27/16 10:41 AM, Chris wrote:
The improved `std find` comes very close to the manual function above
now, sometimes it's even faster or at least as fast.
What you want to do here for indexed access is to match the last element
first. If no match, continue etc. If there's a match, enter an i
On Friday, 27 May 2016 at 18:11:22 UTC, Andrei Alexandrescu wrote:
Would normalization make length 1? -- Andrei
In some, but not all cases.
On 5/27/16 10:15 AM, Chris wrote:
It has happened to me that characters like "é" return length == 2
Would normalization make length 1? -- Andrei
On Friday, 27 May 2016 at 17:08:33 UTC, Pete wrote:
...
Please don't derail this conversation. If you have a complaint
please make it in a separate thread and tag it OT.
On Friday, 27 May 2016 at 14:41:29 UTC, Chris wrote:
The improved `std find` comes very close to the manual function
above now, sometimes it's even faster or at least as fast.
I think it really depends on the use case. The manual algorithm
is really naive and std-find is slightly more advanced
On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote:
I think it's clear that `std find` is vry slow. If anyone
wants to test my function, please do so. I don't want to spread
wrong data, but this is what I get at the moment (ldc latest
version).
If you want to see find (current or my impr
On 5/26/2016 9:00 AM, Andrei Alexandrescu wrote:
My thesis: the D1 design decision to represent strings as char[] was disastrous
and probably one of the largest weaknesses of D1. The decision in D2 to use
immutable(char)[] for strings is a vast improvement but still has a number of
issues.
The
I post this only as a warning to others.
Imagine being the kind of person who isn't certain he could
actually get Hello World past the D compiler -but (and?) sees
the subject "Our Sister" and immediately thinks:
"oh, Alexandrescu must be referring to his sister who is a doctor
and did the art
On 5/27/16 11:35 AM, Joakim wrote:
On Friday, 27 May 2016 at 14:34:03 UTC, Jesse Phillips wrote:
On Thursday, 26 May 2016 at 15:53:34 UTC, Seb wrote:
We already have
http://wiki.dlang.org/User:Vladimir_Panteleev/Website_staging so
it's not a matter of implementation, just everyone agreeing that
On Fri, May 27, 2016 at 03:47:32PM +0200, ag0aep6g via Digitalmars-d wrote:
> On 05/27/2016 03:32 PM, Andrei Alexandrescu wrote:
> > > > However the following do require autodecoding:
> > > >
> > > > s.walkLength
> > > > s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation
> > > > s.count!(c
On Friday, 27 May 2016 at 14:34:03 UTC, Jesse Phillips wrote:
On Thursday, 26 May 2016 at 15:53:34 UTC, Seb wrote:
We already have
http://wiki.dlang.org/User:Vladimir_Panteleev/Website_staging
so it's not a matter of implementation, just everyone
agreeing that it's what we want to do
Would t
On Friday, 27 May 2016 at 14:06:09 UTC, Chris wrote:
This outperforms both `manual_find` and the improved `std find`
string findStringS_Manual(string haystack, string needle)
{
if (needle.length > haystack.length)
return haystack[$..$];
outer:
fo
On Thursday, 26 May 2016 at 15:53:34 UTC, Seb wrote:
We already have
http://wiki.dlang.org/User:Vladimir_Panteleev/Website_staging
so it's not a matter of implementation, just everyone agreeing
that it's what we want to do
Would this mean the website always reflects Phobos HEAD? Is that
what
On Friday, 27 May 2016 at 13:47:32 UTC, ag0aep6g wrote:
Misunderstanding. All examples work properly today because of
autodecoding. -- Andrei
They only work "properly" if you define "properly" as "in terms
of code points". But working in terms of code points is usually
wrong. If you want to c
On Friday, 27 May 2016 at 09:47:08 UTC, Johan Engelen wrote:
On Thursday, 26 May 2016 at 21:45:56 UTC, Seb wrote:
1) Afaik the LDC community moved over to Gitter/Github for
most of their communication and I guess for them just Annouce
or Develop would be fine.
I think the LDC forum has its
On Friday, 27 May 2016 at 13:29:00 UTC, Andrei Alexandrescu wrote:
On 5/27/16 8:28 AM, Chris wrote:
This is surprising. It should be easy to construct examples
where brute force search performs arbitrarily poor, e.g.
searching for "aaa...aab" in a long string with only "a"s.
I will look
On 05/27/2016 03:32 PM, Andrei Alexandrescu wrote:
However the following do require autodecoding:
s.walkLength
s.count!(c => !"!()-;:,.?".canFind(c)) // non-punctuation
s.count!(c => c >= 32) // non-control characters
Currently the standard library operates at code point level even
though insid
On 5/27/16 5:10 AM, ixid wrote:
That's far too many categories
Yes, we should add exactly one. -- Andrei
On 5/27/16 6:26 AM, Kagamin wrote:
As I understand, design rationale
behind strings being plain arrays of code units is that it's impractical
for the string to smarter than array of code units - it just won't cut
it, while plain array provides simple and easy to understand
implementation of strin
On 5/27/16 6:56 AM, Marc Schütz wrote:
It is not, which has been shown by various posts in this thread.
Couldn't quite find strong arguments. Could you please be more explicit
on which you found most convincing? -- Andrei
On 5/27/16 7:07 AM, Marc Schütz wrote:
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu wrote:
RFC: what primitives should RCStr have?
It should _safely_ convert to `const(char)[]`.
That is not possible, sorry. -- Andrei
On 5/27/16 7:19 AM, Chris wrote:
On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu wrote:
[snip]
I would agree only with the amendment "...if used naively", which is
important. Knowledge of how autodecoding works is a prerequisite for
writing fast string code in D. Also, little code
On 5/27/16 8:28 AM, Chris wrote:
I've played around with some algorithms and kept them as simple as
possible, but I've found that a linear brute force for-loop always beats
them (it's the extra decision(s), I suppose). It looks nice in theory,
but in hardware reality a stupid loop is more efficie
On Thursday, 26 May 2016 at 20:03:50 UTC, Jacob Carlborg wrote:
On 2016-05-25 23:38, Atila Neves wrote:
[...]
Interesting, yes. Crazy, not enough :). Here's an example of
replacing functions and replacing methods on individual objects
[1].
[...]
I get an SSL warning for that link.
Atil
On Monday, 23 May 2016 at 22:19:18 UTC, Andrei Alexandrescu wrote:
On 05/23/2016 03:11 PM, qznc wrote:
Conventional wisdom has it that find() is brute force and
that's that, but probably it's time to destroy. Selectively
using advanced searching algorithms for the appropriate inputs
is very D
On Friday, 27 May 2016 at 10:04:14 UTC, Nick Treleaven wrote:
On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote:
To elaborate: neither `scope` nor reference counting can ever
protect you against explicit premature destruction of a
still-referenced owner. But there is a slightly differ
On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
[snip]
I would agree only with the amendment "...if used naively",
which is important. Knowledge of how autodecoding works is a
prerequisite for writing fast string code in D. Also, little
code should deal with one code uni
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu
wrote:
RFC: what primitives should RCStr have?
It should _safely_ convert to `const(char)[]`.
On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
This might be a good time to discuss this a tad further. I'd
appreciate if the debate stayed on point going forward. Thanks!
My thesis: the D1 design decision to represent strings as
char[] was disastrous and probably one of
On Thursday, 26 May 2016 at 18:53:35 UTC, Iakh wrote:
void g() @nogc
{
catch scope(void);
int[N] arr = [/*...*/];
arr[].sort!((a, b) => a > b);
}
This compiles just fine and doesn't allocate:
void g() @nogc
{
int[2] arr = [5,4];
arr[].sort!((a, b) => a > b);
}
On Thursday, 26 May 2016 at 16:00:54 UTC, Andrei Alexandrescu
wrote:
11. Indexing an array produces different results than
autodecoding,
another glaring special case.
This is a direct consequence of the fact that string is
immutable(char)[] and not a specific type. That error predates
autode
On Thursday, 26 May 2016 at 17:32:33 UTC, Jack Stouffer wrote:
*bikeshedding*: How about RCString, because the convention for
D names is to be explicit most of the time.
+1
On Thursday, 26 May 2016 at 16:11:22 UTC, Andrei Alexandrescu
wrote:
* Fast: use the small string optimization and various other
layout and algorithms to make it a good choice for high
performance strings
For inspiration see:
- Vladimir recommends `tempCString`
- Nikolay has https://bitbucket
On Thursday, 26 May 2016 at 08:29:41 UTC, Marc Schütz wrote:
On Wednesday, 25 May 2016 at 19:47:06 UTC, Nick Treleaven wrote:
On 24/05/2016 14:48, Nick Treleaven wrote:
@safe unittest
{
RCArray!int arr;
+ arr.length = 1;
ref r = arr[0];
arr.destroy; // refcount drops to ze
On Thursday, 26 May 2016 at 21:45:56 UTC, Seb wrote:
1) Afaik the LDC community moved over to Gitter/Github for most
of their communication and I guess for them just Annouce or
Develop would be fine.
I think the LDC forum has its purpose, and I do not want it gone!
Traffic is low, but that'
On Friday, 27 May 2016 at 09:10:08 UTC, ixid wrote:
On Thursday, 26 May 2016 at 17:07:54 UTC, Seb wrote:
I think we all agree that general is having to much traffic
and according to CyberShadow [1] this again is just an
approval issue, however I expect this a bit controversial, so
please no OT
On Thursday, 26 May 2016 at 17:07:54 UTC, Seb wrote:
I think we all agree that general is having to much traffic and
according to CyberShadow [1] this again is just an approval
issue, however I expect this a bit controversial, so please no
OT! Only other category proposals.
Proposed categorie
https://issues.dlang.org/show_bug.cgi?id=15951
https://issues.dlang.org/show_bug.cgi?id=11817
https://issues.dlang.org/show_bug.cgi?id=11331
What I gather from the discussions is that the current spec says
that:
```
struct S {
char[100] arr = void;
}
S a;
S b;
assert(a == b);
```
That lan
On Thursday, 26 May 2016 at 20:10:57 UTC, ikod wrote:
Will it not hang in the loop if you send it SIGINT?
Looks like not, but is strange for me.
Yes, I had the same feeling the first time I came across that.
I remember why we had to use that loop in C: when we were using
gdb to do some debugg
On Friday, 27 May 2016 at 06:07:36 UTC, Joakim wrote:
On Friday, 27 May 2016 at 00:21:37 UTC, Mike Parker wrote:
I would like to see a forum for third-party libraries. I had a
forum for Derelict at DSource until the site died, then
maintained one at Lunarpages until it got hacked. I'm not
eage
89 matches
Mail list logo
