On Saturday, 20 October 2018 at 15:10:38 UTC, Nathan S. wrote:
are there more zero-initializations that can be optimized in
std.experimental.allocator?
I looked and identified low-hanging fruit in
std.mutation.initializeAll & moveEmplace and in
std.typecons.RefCounted (PR #6698), an
On Saturday, 20 October 2018 at 15:10:38 UTC, Nathan S. wrote:
Other opportunities would rely on being able to identify if
it's ever more efficient to write `memset(&x, 0,
typeof(x).sizeof)` instead of `x = typeof(x).init` which seems
like the kind of optimization that belon
-initializations that can be optimized in
std.experimental.allocator?
I looked and identified low-hanging fruit in
std.mutation.initializeAll & moveEmplace and in
std.typecons.RefCounted (PR #6698), and in
std.conv.emplaceInitializer (PR #6461). Other opportunities would
rely on being able to iden
Now that
https://github.com/dlang/phobos/pull/6411
has been merged and DMD stable soon has the new
__traits(isZeroInit, T)
found here
https://dlang.org/changelog/2.083.0.html#isZeroInit
are there more zero-initializations that can be optimized in
std.experimental.allocator?
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does h
On Tuesday, 16 October 2018 at 22:59:18 UTC, Soulsbane wrote:
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya
wrote:
Just updated Atom editor and noticed D files read as plain
.txt and no D bindings in list of programs. Maybe someone
should bring that to Atom's devs atte
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does h
On Tuesday, 16 October 2018 at 17:48:42 UTC, Jabari Zakiya wrote:
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya
wrote:
Just updated Atom editor and noticed D files read as plain
.txt and no D bindings in list of programs. Maybe someone
should bring that to Atom's devs atte
On Tuesday, 16 October 2018 at 02:34:47 UTC, Jabari Zakiya wrote:
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should
bring that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does h
Just updated Atom editor and noticed D files read as plain .txt
and no D bindings in list of programs. Maybe someone should bring
that to Atom's devs attention.
Interesting, since my main editor, KDE's Kate, does have D file
syntax highlighting.
On Sun, 2018-10-07 at 10:51 +, rjframe via Digitalmars-d wrote:
[…]
>
> I don't use SCons, but took a quick look; my current guess is that the
> problem is the chocolatey installation of dmd and the rest in AppVeyor;
> chocolatey doesn't install DMD in %SYSTEMROOT% a
On Tue, 02 Oct 2018 06:51:10 +0100, Russel Winder wrote:
> It turns out there are a number problems with the SCons tests running on
> Windows, many of them associated with the D support.
>
> https://github.com/SCons/scons/issues/3205
>
> As you will see I am choosing not
Hi,
I know there are a number of people out there who use SCons to build D
codes.
I know there are a number of those people who work on Windows.
Your help is being asked for.
All the work I have done for D support in SCons has been based entirely
on Debian Sid, but tested on Fedora Rawhide
On Tuesday, 25 September 2018 at 14:28:48 UTC, FeepingCreature
wrote:
Maybe stick the info in -v or -deps?
Actually, -deps is the perfect place for it. It needs to
recursively evaluate modules anyways, so it'll see an import even
if it was only used from a template. And it doesn'
because the
metaprogramming capabilities of the language are not limited
in terms of system calls.
Back in the naive olden days, Microsoft released ActiveX,
where a web page could load executable objects (!) from the
internet and run them in the browser.
It quickly became apparent that this
in terms of system calls.
Back in the naive olden days, Microsoft released ActiveX,
where a web page could load executable objects (!) from the
internet and run them in the browser.
It quickly became apparent that this was a disaster, as lots
of people on the internet aren't to be tr
On Friday, 21 September 2018 at 18:20:21 UTC, Adam D. Ruppe wrote:
You don't need an API call to do that. You just provide the
icon in a resource to the linker or a separate resource thing.
Some C++ environments do it via pragmas, or you can do it
traditionally in a makefile/build command
On 9/21/2018 7:46 AM, Steven Schveighoffer wrote:
I can see the marketing now, "D finds infinite loops in compile-time code way
faster than Jai!".
We need you over in marketing!
On 9/21/2018 9:29 AM, welkam wrote:
Jai compiler perform parsing and lexing in different thread so its kinda multi
threaded. Its possible to do the same with D front end. We can start here but
there are plenty of low hanging fruits in compiler you just need to run profiler
to find them
D was
On Friday, 21 September 2018 at 13:37:58 UTC, aliak wrote:
Si si, but i believe the loadExecutableIcon actually calls
windows APIs to set an icon on an executable, and they'd
probably @system which means I don't think that could be done
in D.
You don't need an API call to do
On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
And is there anyway to get even near the performance of Jai
when it comes to compilations
I watched the same video today. What a coincidence.
In Jai example 80 000 lines of "code" include comments and empty
lines. Sin
On Fri, Sep 21, 2018 at 07:58:56AM +, mate via Digitalmars-d wrote:
[...]
> I realize that with build instructions written in unrestricted
> language it is easier to create a dependency on something else than
> the compiler, such as the OS. Maybe they plan to solve this probl
> The more people you have on your team, the more you appreciate the
> restrictions. If you are working on a personal project alone, you are
> in control and have full knowledge of the entire codebase, so
> restrictions are a hindrance. When you are collaborating with someone
> you
On Friday, 21 September 2018 at 13:28:47 UTC, aliak wrote:
Sure, all true, but from what I've seen of Jai, it's not a
simple language, and it does a decent amount of compile time
stuff, but who knows, maybe the code is simple indeed. I
remember a demo where he ran a game at compile time and was
On 9/21/18 10:19 AM, Nicholas Wilson wrote:
On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov [ZombineDev]
wrote:
I have been watching Jonathan Blow's Jai for a while myself. There are
many interesting ideas there, and many of them are what made me like D
so much in the first
On Friday, 21 September 2018 at 09:21:34 UTC, Petar Kirov
[ZombineDev] wrote:
I have been watching Jonathan Blow's Jai for a while myself.
There are many interesting ideas there, and many of them are
what made me like D so much in the first place. It's very
important to note that
D so much in the first place. It's very
important to note that the speed claims he has been making are
all a matter of developer discipline. You can have an infinite
loop executed at compile-time in both D and Jai. There's
nothing magical Jai can do about that - the infinite loop i
On Friday, 21 September 2018 at 05:39:35 UTC, Vladimir Panteleev
wrote:
On Friday, 21 September 2018 at 05:11:32 UTC, mate wrote:
Note that the build can be done at compile time because the
metaprogramming capabilities of the language are not limited
in terms of system calls.
Good luck
in D is
very fast.
I was going to say this too, ie how much of that Jai code is
run at compile-time, how much is uninstantiated templates that
is just skipped over like D does, and how much is templates
instantiated many times? Lines of code is not a good enough
measure with those programming
On Friday, 21 September 2018 at 07:37:14 UTC, Walter Bright wrote:
On 9/21/2018 12:19 AM, mate wrote:
It depends on the developer not doing anything stupid
Aye, there's the rub!
The evolution of programming language discussions from
"sufficiently smart compiler" to "sufficiently smart progra
personal project alone,
you are in control and have full knowledge of the entire
codebase, so restrictions are a hindrance. When you are
collaborating with someone you know only by name from across the
globe, being able to reason what their code might or may not do
is considerably helpful.
On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
Alo!
I have been watching Jonathan Blow's Jai for a while myself.
There are many interesting ideas there, and many of them are what
made me like D so much in the first place. It's very important to
note that the speed
On Friday, 21 September 2018 at 07:19:41 UTC, mate wrote:
Reproducible builds are out too, as the produced object file
is no longer purely a function of the source code and compiler
version.
It depends on the developer not doing anything stupid in the
build instructions, be it compiler
yself what is best.
I agree that one would need to realize that compiling a program
could potentially be harmful, and that could be a significant
change in one’s habits.
On Friday, 21 September 2018 at 06:02:26 UTC, mate wrote:
I am actually not sure if there really are no limitations to
Jai’s CTFE, in its current state.
What I like with unrestricted CTFE is that it makes something
that was completely safe a security problem.
ation, testing
etc. Like a C project!
There is a shift from imperative to declarative for build recipes
in all other modern languages and Jai has made (yet another)
wrong choice.
On 9/21/2018 12:19 AM, mate wrote:
It depends on the developer not doing anything stupid
Aye, there's the rub!
On Friday, 21 September 2018 at 06:34:47 UTC, Vladimir Panteleev
wrote:
The problem with putting it in the compiler is that it
invalidates many contracts (and, thus, use cases) about what
invoking the compiler can do. This means you can't bisect or
reduce (as with Dustmite) the source
On Friday, 21 September 2018 at 06:30:40 UTC, Walter Bright wrote:
On 9/20/2018 10:11 PM, mate wrote:
Note that the build can be done at compile time because the
metaprogramming capabilities of the language are not limited
in terms of system calls.
Back in the naive olden days, Microsoft
On 9/20/2018 10:11 PM, mate wrote:
Note that the build can be done at compile time because the metaprogramming
capabilities of the language are not limited in terms of system calls.
Back in the naive olden days, Microsoft released ActiveX, where a web page could
load executable objects
On Friday, 21 September 2018 at 05:39:35 UTC, Vladimir Panteleev
wrote:
On Friday, 21 September 2018 at 05:11:32 UTC, mate wrote:
Note that the build can be done at compile time because the
metaprogramming capabilities of the language are not limited
in terms of system calls.
Good luck
On Friday, 21 September 2018 at 05:11:32 UTC, mate wrote:
Note that the build can be done at compile time because the
metaprogramming capabilities of the language are not limited in
terms of system calls.
Good luck bisecting that code base when any version of it did
anything even mildly
o the compiler.
3. You can embed your buildscript into one of your project's
existing source files, instead of putting it in a dedicated
buildscript file.
I understand that the build tool is the compiler itself,
presumably providing some functions/hooks for the build script,
which
On 9/20/2018 7:44 PM, Nick Sabalausky (Abscissa) wrote:
3. You can embed your buildscript into one of your project's existing source
files, instead of putting it in a dedicated buildscript file.
(We can do that in D too, by utilizing version identifiers, but we don't because
its
a good thing, but it's also a bare minimum expectation in ANY
language that isn't C or C++. Yawn.)
2. He created a standard (and presumably mandatory) build tool to go
along with his language, but is avoiding *calling* it a build
tool...even though it's clearly just a build tool t
On Friday, 21 September 2018 at 00:47:27 UTC, Adam D. Ruppe wrote:
Of course, D can also take ages to compile one line of code. It
all depends on that that line is doing... ctfe and templates
are slow. C or Java style code compiling in D is very fast.
I was going to say this too, ie how much
On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
he can now compile an 80,000 line game in about 1.5 seconds on
a laptop
D can compile similar amounts of code in half the time.
For example, the entire D1 runtime and standard library can be
built (compiled and linked!) in 0.6
On Thursday, 20 September 2018 at 23:13:38 UTC, aliak wrote:
Alo!
I just watched this talk from Jonathan Blow [0] about his
programming language called Jai, and he can now compile an
80,000 line game in about 1.5 seconds on a laptop (of course I
have no idea what laptop he's using), un
Alo!
I just watched this talk from Jonathan Blow [0] about his
programming language called Jai, and he can now compile an 80,000
line game in about 1.5 seconds on a laptop (of course I have no
idea what laptop he's using), under 1 second on a desktop.
And he claims it's h
On Tuesday, 18 September 2018 at 23:01:46 UTC, Per Nordlöw wrote:
On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote:
I just remember that D's GC has NO_SCAN [1] attribute!
I thought D libraries like Mir and Lubeck only had to care
about when to call GC.addRange after allocations that c
On Tuesday, 18 September 2018 at 14:23:44 UTC, 9il wrote:
I just remember that D's GC has NO_SCAN [1] attribute!
I thought D libraries like Mir and Lubeck only had to care about
when to call GC.addRange after allocations that contain pointers
to GC-backed storage and GC.removeRange before the
. The actual TypeInfo object is generated
by the compiler [2]. __arrayAlloc (called by _d_newarray*) then
sets BlkAttr.NO_SCAN depending on what's in TypeInfo.flags. [3]
[1]:
https://github.com/dlang/druntime/blob/542b680f2c2e09e7f4b494898437c61216583fa5/src/rt/lifetime.d#L966-L1014
[
On Tuesday, 18 September 2018 at 17:21:17 UTC, 9il wrote:
On Tuesday, 18 September 2018 at 16:29:30 UTC, Vladimir Thanks!
Is there is information about how GC set flags for `new` on the
site?
Today my English is so bad =/ sorry
sure? That doesn't sound right.
I know this is the case for void[] - even though you can't put
pointers in it, it could hold "anything", so the GC strays on
the safe side and assumes it has pointers.
There was (is?) a problem with e.g. std.file.read("a") ~
std.fil
. For example, are
Slice!(double*, 2) should never be scanned by GC, but it will
be in GC heap until something refers it.
Not sure if this is what you mean or not, but the D GC already
doesn't scan types which do not contain references. This was
added in D 1.000, see TypeInfo.flags&1
even though you can't put
pointers in it, it could hold "anything", so the GC strays on the
safe side and assumes it has pointers.
There was (is?) a problem with e.g. std.file.read("a") ~
std.file.read("b") - even though read marked the memory as
ample, are
Slice!(double*, 2) should never be scanned by GC, but it will
be in GC heap until something refers it.
Let me know if you have ideas how to further improve memory
management and required API in Mir and Lubeck.
[1]
https://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN
Best,
ut it will
be in GC heap until something refers it.
Not sure if this is what you mean or not, but the D GC already
doesn't scan types which do not contain references. This was
added in D 1.000, see TypeInfo.flags&1. NO_SCAN is a way to
further override that.
If you mean that Slice i
ut it will
be in GC heap until something refers it.
Let me know if you have ideas how to further improve memory
management and required API in Mir and Lubeck.
[1]
https://dlang.org/phobos/core_memory.html#.GC.BlkAttr.NO_SCAN
Best,
Ilya
Can you elaborate on why this is the case?
I just remember that D's GC has NO_SCAN [1] attribute!
This will be added by default when for Mir allocations if type
representation tuple has not references. For example, are
Slice!(double*, 2) should never be scanned by GC, but it will be
in GC heap until something refers it.
Let me
If you can not access the dll files that are present in the
computer. This error occur when the dll file is not installed in
your system then download https://unfitpc.com/zlib1-dll and run
all the files.
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
Why the hell do exceptions give error in the library rather
than the user code?
D exceptions can provide context in two ways:
- Stack trace, for which you need to compile with debug symbols
enabled (-g).
- A file name and
On Friday, 14 September 2018 at 16:40:01 UTC, Josphe Brigmo wrote:
This is the only kind of error I get
Compile with -g.
On Friday, 14 September 2018 at 16:43:04 UTC, Josphe Brigmo wrote:
It is because you are throwing inside your code. When the throw
is from the library, it gives something like this:
std.exception.ErrnoException@std/stdio.d(430): Cannot open file
`/doesntexist' in mode `w' (Permiss
On Friday, 14 September 2018 at 15:52:20 UTC, Neia Neutuladh
wrote:
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo
wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is
pointing to code in a
On Friday, 14 September 2018 at 15:40:46 UTC, Jonathan Marler
wrote:
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo
wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is
pointing to code in a
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is pointing
to code in a library which tells me absolutely nothing about
where the error
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote:
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is pointing
to code in a library which tells me absolutely nothing about
where the error
std.file.FileException@C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(3153):
It is very annoying when the only error info I have is pointing
to code in a library which tells me absolutely nothing about
where the error occurs in the in the user code(which is what
matters).
Surely the
In C++ programming you can call any kind of array it may be
associative or dissociative one, and, with declaration fo the
array, you can easily input mad output with a string and it can
be integer or float format. And you can take some help from
https://hpsupports.co/hp-support-assistant/ to
On Saturday, 8 September 2018 at 14:20:10 UTC, Laeeth Isharc
wrote:
Religions have believers but not supporters - in fact saying
you are a supporter says you are not a member of that faith or
community.
If you are a supporter of Jesus Christ's efforts, then you most
certainly are a chri
nts. For speed units work, and for correctness,
> >> graphemes work.
> >
> > I think that it's pretty clear that code points are objectively
> > the worst level to be the default. Unfortunately, changing it
> > to _anything_ else is not going to be an easy
speed units work, and for correctness,
> >> graphemes work.
> >
> > I think that it's pretty clear that code points are objectively
> > the worst level to be the default. Unfortunately, changing it
> > to _anything_ else is not going to be an easy feat at th
expert in all fields. I
think the problem was that it was discovered too late.
There are very valid reasons not to talk about auto-decoding
again:
- it's too late to remove because breakage
- attempts at removing it were _already_ tried
- it has been debated to DEATH
- there is an easy work-a
nsure that Phobos in general
doesn't rely on it (i.e. in general, it can deal with ranges of
char, wchar, dchar, or graphemes correctly rather than assuming
that all ranges of characters are ranges of dchar), then maybe
we can figure something out. Unfortunately, while some work has
been do
like to point out that Swift spend a lot of time reworking how
string are handled.
If my memory serves me well, they have reworked strings from
version 2 to 3 and finalized it in version 4.
Swift 4 includes a faster, easier to use String implementation
that retains Unicode correctness and
nsure that Phobos in general
doesn't rely on it (i.e. in general, it can deal with ranges of
char, wchar, dchar, or graphemes correctly rather than assuming
that all ranges of characters are ranges of dchar), then maybe
we can figure something out. Unfortunately, while some work has
been do
ork, and for correctness, graphemes work.
I think that it's pretty clear that code points are objectively the worst
level to be the default. Unfortunately, changing it to _anything_ else is
not going to be an easy feat at this point. But if we can first ensure that
Phobos in general doesn&#x
";
> auto x = a ~ c ~ a;
> auto y = b ~ c ~ b;
>
> writeln(a.length); // 2 wtf
> writeln(b.length); // 3 wtf
> writeln(x.length); // 7 wtf
> writeln(y.length); // 9 wtf
[...]
This is an unfair comparison. In the Swift version you used
.count, but here you used .length,
gt; > auto b = "á";
> > > auto c = "\u200B";
> > > auto x = a ~ c ~ a;
> > > auto y = b ~ c ~ b;
> > >
> > > writeln(a.length); // 2 wtf
> > > writeln(b.length); // 3 wtf
> > > writeln(x.length); // 7 wtf
> &g
";
> auto x = a ~ c ~ a;
> auto y = b ~ c ~ b;
>
> writeln(a.length); // 2 wtf
> writeln(b.length); // 3 wtf
> writeln(x.length); // 7 wtf
> writeln(y.length); // 9 wtf
[...]
This is an unfair comparison. In the Swift version you used
.count, but here you used .length,
a;
> > auto y = b ~ c ~ b;
> >
> > writeln(a.length); // 2 wtf
> > writeln(b.length); // 3 wtf
> > writeln(x.length); // 7 wtf
> > writeln(y.length); // 9 wtf
[...]
This is an unfair comparison. In the Swift version you used .count, but
here you used .length, which is
On Thu, Sep 6, 2018 at 4:45 PM Dukc via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
> > // D
> > auto a = "á";
> > auto b = "á";
> > auto c = "\u200B";
> > auto x = a ~ c ~ a;
> > auto y = b ~ c ~ b;
> >
> > writeln(a.length);
On Thursday, 6 September 2018 at 14:42:14 UTC, Chris wrote:
Usually a sign to move on...
You have said that at least 10 times in this very thread.
Doomsayers are as old as D. It will be doing OK.
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
Hehe, it's already a bit laughable that correctness is not
preferred.
// Swift
let a = "á"
let b = "á"
let c = "\u{200B}" // zero width space
let x = a + c + a
let y = b + c + b
print(a.count) // 1
print(b.count) // 1
print(x.count)
On Thursday, 6 September 2018 at 14:30:38 UTC, Guillaume Piolat
wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an expert in all fields. I
think the problem was that it was
On Thursday, 6 September 2018 at 14:17:28 UTC, aliak wrote:
// D
auto a = "á";
auto b = "á";
auto c = "\u200B";
auto x = a ~ c ~ a;
auto y = b ~ c ~ b;
writeln(a.length); // 2 wtf
writeln(b.length); // 3 wtf
writeln(x.length); // 7 wtf
writeln(y.length); // 9 wtf
writeln(a == b); // false wtf
range (100% compatible). Then people will just
update their code to use the range...
This should be possible to achieve using automated
source-to-source translation in most cases.
On 07/09/2018 2:30 AM, Guillaume Piolat wrote:
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong, because,
you know, you cannot be an expert in all fields. I think the problem
was that it was discovered too late.
There
On Thursday, 6 September 2018 at 13:30:11 UTC, Chris wrote:
And autodecode is a good example of experts getting it wrong,
because, you know, you cannot be an expert in all fields. I
think the problem was that it was discovered too late.
There are very valid reasons not to talk about auto
On Wednesday, 5 September 2018 at 22:00:27 UTC, H. S. Teoh wrote:
Because grapheme decoding is SLOW, and most of the time you
don't even need it anyway. SLOW as in, it will easily add a
factor of 3-5 (if not worse!) to your string processing time,
which will make your natively-compiled D
On Thursday, 6 September 2018 at 11:01:55 UTC, Guillaume Piolat
wrote:
So Unicode in D works EXACTLY as expected, yet people in this
thread act as if the house is on fire.
Expected by who? The Unicode expert or the user?
D dying because of auto-decoding? Who can possibly think that
in
On Thursday, 6 September 2018 at 11:01:55 UTC, Guillaume Piolat
wrote:
Let me break that to you: core developer are language experts.
The rest of us are users, that yes it doesn't make us
necessarily qualified to design a language.
Who?
know that `string` is both a range of code points and an array
of code units. And you need to know that `.length` belongs to
the array side, not the range side. Once you know that (and
more), things start making sense in D.
You'll need some basic knowledge of Unicode, if you deal with
stri
e license. But on top of that, D
also requires an auto-decoding license. You need to know that `string`
is both a range of code points and an array of code units. And you need
to know that `.length` belongs to the array side, not the range side.
Once you know that (and more), things start making
On Thursday, 6 September 2018 at 11:19:14 UTC, Chris wrote:
One problem imo is that they mixed the terms up: "Grapheme: A
minimally distinctive unit of writing in the context of a
particular writing system." In linguistics a grapheme is not a
single character like "á" or
On Thursday, 6 September 2018 at 10:44:45 UTC, Joakim wrote:
[snip]
You're not being fair here, Chris. I just saw this SO question
that I think exemplifies how most programmers react to Unicode:
"Trying to understand the subtleties of modern Unicode is
making my head hurt. In
CodePoint.array; // type is `dchar[]`
writefln("%d", firstCP.length); // prints 1
dstring second = "á";
writefln("%d", second.length); // prints 1 (That was easy!)
// DMD64 D Compiler v2.081.2
}
So Unicode in D works EXACTLY as expected, yet people in thi
er v2.081.2
}
And this has what to do with autodecoding?
Nothing. I was just pointing out how awkward some basic things
can be. autodecoding just adds to it in the sense that it's a
useless overhead but will keep string handling in a limbo
forever and ever and ever.
TBH, it l
on happens along the way.)
That's when you enter the 'á' as 'a' followed by U+0301
(combining acute accent). So Python's `len` counts in code
points, like D's std.range does (auto-decoding).
To avoid this you have to normalize and recompose any decomposed
ch
1 - 100 of 21172 matches
Mail list logo
