Re: Question regarding Base64 decoding
A bug.
Re: FunctionTypeOf behaves unexpectedly for function pointers?
On Saturday, 30 July 2016 at 12:54:32 UTC, Basile B. wrote: func is a pointer to a function but FunctionTypeOf extracts the target type. So the correct assertion is static assert(is(FunctionTypeOf!func* == typeof(func))); I can't believe that it worked for delegates because the same happens. It extracts the target type, i.e it discards the information saying that it's a member function: import std.traits; void function() fun; void delegate() dlg; static assert(is(FunctionTypeOf!fun* == typeof(fun))); static assert(is(FunctionTypeOf!dlg* == typeof(fun))); Ah, that makes sense. Thank you!
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Sunday, 31 July 2016 at 18:57:50 UTC, Jack Stouffer wrote: Next question: what's the fastest hashing implementation that will provide the least collisions? Is there a hash implementation that's perfered for AAs? There's no hashing function that would be specifically better for associative arrays, it's a hashing function either way. The primary things that should affect what your hashing function looks like should be what your inputs - keys for an AA - look like. djb2 is my go-to for string hashing because it's conceptually simple, efficient, and effective for most use cases. http://www.cse.yorku.ca/~oz/hash.html Every hashing function will produce collisions. As long as you handle them, and as long as they aren't inordinately frequent, you'll be fine.
Indexing with an arbitrary type
Hi everybody,
I have a question and a half on templates and ranges, this time.
Say, I have two functions:
auto f1(T, S)(T t, S s) if(isIntegral!T && isRandomAccessRange!S)
{
return s[t];
}
auto f2(T, S)(T t, RandomAccessFinite!S raf) if(isIntegral!T)
{
return raf[t];
}
and a
class myClass : RandomAccessFinite!ubyte {...}
which implements all the methods needed by the RandomAccessFinite
interface.
then, I could use this in my main by just
void main()
{
myClass mC = new myClass();
writeln(f2(1, mC));
writeln(f1(1, mC));
ubyte[] arr = [0, 42, 2, 3, 4];
writeln(f1(1, arr));
//writeln(f2(1, arr)); //this fails and is the first part of
the question.
}
so, the first question is, why the method using the
RandomAccessFinite interface fails on using an array? Did I miss
a method, which is not supported by an array?
But the main question is about the other part, about the
constraint to the first parameter to my functions.
It seems strange to me to use "isIntegral" here, as this is some
kind of unrelated for something used as an index.
Is there anything more appropriate to check? What kind of
interface/trait has an index to fulfill?
Re: Why Does Dscanner Warn About a Missing toHash if opEquals is Defined?
On Monday, 1 August 2016 at 10:35:29 UTC, pineapple wrote: Every hashing function will produce collisions. Not totally true: when the hash map content is static (i.e known at compile time) there are probabilities that a perfect hashing function exists. But these kind of functions are a bit special because each byte of the value maps to another byte. See the gnu tool "gperf" for example.
Re: Indexing with an arbitrary type
On Monday, August 01, 2016 11:06:54 Alex via Digitalmars-d-learn wrote:
> Hi everybody,
> I have a question and a half on templates and ranges, this time.
> Say, I have two functions:
>
> auto f1(T, S)(T t, S s) if(isIntegral!T && isRandomAccessRange!S)
> {
> return s[t];
> }
>
> auto f2(T, S)(T t, RandomAccessFinite!S raf) if(isIntegral!T)
> {
> return raf[t];
> }
>
> and a
> class myClass : RandomAccessFinite!ubyte {...}
> which implements all the methods needed by the RandomAccessFinite
> interface.
>
> then, I could use this in my main by just
>
> void main()
> {
> myClass mC = new myClass();
> writeln(f2(1, mC));
> writeln(f1(1, mC));
>
> ubyte[] arr = [0, 42, 2, 3, 4];
> writeln(f1(1, arr));
> //writeln(f2(1, arr)); //this fails and is the first part of
> the question.
> }
>
> so, the first question is, why the method using the
> RandomAccessFinite interface fails on using an array? Did I miss
> a method, which is not supported by an array?
An array does not implement RandomAccessFinite, which is an interface that
you created. So, a function that takes a RandomAccessFinite is not going to
accept an array. A dynamic array will match isRandomAccessRange, but that
has nothing to do with interfaces.
> But the main question is about the other part, about the
> constraint to the first parameter to my functions.
> It seems strange to me to use "isIntegral" here, as this is some
> kind of unrelated for something used as an index.
> Is there anything more appropriate to check? What kind of
> interface/trait has an index to fulfill?
What's strange? If you want to accept any integer type, then isIntegral!T
would do it. A _better_ thing to do would be to make it so that it's just
size_t and not templatize the type, since indices really should be size_t
normally (and if the system is 32-bit, then isIntegral!T will accept long
and ulong, whereas size_t is uint, and if you pass a long, you'll get a
compilation error for arrays, since they take size_t for indexing; it won't
matter for 64-bit though, since size_t is ulong there). So,
auto f1(R)(size_t index, R range)
if(isRandomAccessRange!R)
{
return range[index];
}
would be better, but aside from the 32-bit issues, isIntegral will work.
- Jonathan M Davis
Re: Indexing with an arbitrary type
On Monday, 1 August 2016 at 13:52:56 UTC, Jonathan M Davis wrote:
An array does not implement RandomAccessFinite, which is an
interface that you created. So, a function that takes a
RandomAccessFinite is not going to accept an array. A dynamic
array will match isRandomAccessRange, but that has nothing to
do with interfaces.
It's ok for me to say, that some types do not implement an
interface to show some abilities, even if the interface, which
has to be implemented to show the same abilities is
given/known/public/exposed... etc...
So, I think this part is ok now, I think...
But the main question is about the other part, about the
constraint to the first parameter to my functions.
It seems strange to me to use "isIntegral" here, as this is
some
kind of unrelated for something used as an index.
Is there anything more appropriate to check? What kind of
interface/trait has an index to fulfill?
What's strange? If you want to accept any integer type, then
isIntegral!T would do it. A _better_ thing to do would be to
make it so that it's just size_t and not templatize the type,
since indices really should be size_t normally (and if the
system is 32-bit, then isIntegral!T will accept long and ulong,
whereas size_t is uint, and if you pass a long, you'll get a
compilation error for arrays, since they take size_t for
indexing; it won't matter for 64-bit though, since size_t is
ulong there). So,
auto f1(R)(size_t index, R range)
if(isRandomAccessRange!R)
{
return range[index];
}
would be better, but aside from the 32-bit issues, isIntegral
will work.
- Jonathan M Davis
This goes in a different direction I want to. I don't have
anything against simplification to size_t, indeed I have it in
this way currently. But what I want is something like the
following:
having
alias MyIndex = int
and
MyIndex s = MyInd(1);
writeln(f1(s, arr)); //gives 42, as expected
Now, I want to define a
struct S
{
int index;
??? what else ??? // alias index this; doesn't help
}
and still being able to have
alias MyIndex = S
and nothing else should be changed.
Re: Indexing with an arbitrary type
On Monday, August 01, 2016 14:46:03 Alex via Digitalmars-d-learn wrote:
> On Monday, 1 August 2016 at 13:52:56 UTC, Jonathan M Davis wrote:
> > An array does not implement RandomAccessFinite, which is an
> > interface that you created. So, a function that takes a
> > RandomAccessFinite is not going to accept an array. A dynamic
> > array will match isRandomAccessRange, but that has nothing to
> > do with interfaces.
>
> It's ok for me to say, that some types do not implement an
> interface to show some abilities, even if the interface, which
> has to be implemented to show the same abilities is
> given/known/public/exposed... etc...
> So, I think this part is ok now, I think...
I'm afraid that I don't know what you're talking about, but if what you have
is working, then great. But while arrays can pass template constraints, they
can't implement interfaces, so what you had before didn't really seem like
it was going to work.
> >> But the main question is about the other part, about the
> >> constraint to the first parameter to my functions.
> >> It seems strange to me to use "isIntegral" here, as this is
> >> some
> >> kind of unrelated for something used as an index.
> >> Is there anything more appropriate to check? What kind of
> >> interface/trait has an index to fulfill?
> >
> > What's strange? If you want to accept any integer type, then
> > isIntegral!T would do it. A _better_ thing to do would be to
> > make it so that it's just size_t and not templatize the type,
> > since indices really should be size_t normally (and if the
> > system is 32-bit, then isIntegral!T will accept long and ulong,
> > whereas size_t is uint, and if you pass a long, you'll get a
> > compilation error for arrays, since they take size_t for
> > indexing; it won't matter for 64-bit though, since size_t is
> > ulong there). So,
> >
> > auto f1(R)(size_t index, R range)
> >
> > if(isRandomAccessRange!R)
> >
> > {
> >
> > return range[index];
> >
> > }
> >
> > would be better, but aside from the 32-bit issues, isIntegral
> > will work.
> >
> > - Jonathan M Davis
>
> This goes in a different direction I want to. I don't have
> anything against simplification to size_t, indeed I have it in
> this way currently. But what I want is something like the
> following:
>
> having
> alias MyIndex = int
> and
> MyIndex s = MyInd(1);
> writeln(f1(s, arr)); //gives 42, as expected
>
> Now, I want to define a
> struct S
> {
> int index;
> ??? what else ??? // alias index this; doesn't help
> }
> and still being able to have
> alias MyIndex = S
> and nothing else should be changed.
If you want a template constraint that checks that a type works with the
index operator on a type, and you're not restricting it to something like
size_t, then you're just going to have to check whether the expression is
going to compile. Also, that is incompatible with random access ranges.
Random access ranges are expected to work with size_t, and while
isRandomAccessRange isn't currently quite that restrictive, it does check
that r[1] compiles, so the index operator is going to have to accept
integers at minimum. If you want a completely generic index operator, and
you want a template constraint for it, you're pretty much going to have to
test that it compiles. e.g.
auto fun(I, T)(I index, T obj)
if(__traits(compiles, obj[index]))
{
return obj[index];
}
or if you want a reusable template, you can do something like
template isIndexable(I, T)
{
enum isIndexable = __traits(compiles, T.init[I.init]);
}
auto fun(I, T)(I index, T obj)
if(isIndexable!(I, T))
{
return obj[index];
}
Personally, I think that having code that accepts any type that can be
indexable with any type isn't a particularly good idea, because odds are, it
won't actually work, because those different types will work quite
differently (e.g. associative arrays are indexable with stuff other than
size_t, but they're really not interchangeable with dynamic arrays or static
arrays, which use size_t). And anything that wants to be interchangeable
with a dynamic array or be usable as a random access range should be using
size_t to index. But if you actually have code where it makes sense to deal
with types that can take all kinds of random stuff as indices, then
something like I posted above should work.
- Jonathan M Davis
Re: Indexing with an arbitrary type
On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis wrote:
If you want a template constraint that checks that a type works
with the index operator on a type, and you're not restricting
it to something like size_t, then you're just going to have to
check whether the expression is going to compile. Also, that is
incompatible with random access ranges. Random access ranges
are expected to work with size_t, and while isRandomAccessRange
isn't currently quite that restrictive, it does check that r[1]
compiles, so the index operator is going to have to accept
integers at minimum. If you want a completely generic index
operator, and you want a template constraint for it, you're
pretty much going to have to test that it compiles. e.g.
auto fun(I, T)(I index, T obj)
if(__traits(compiles, obj[index]))
{
return obj[index];
}
or if you want a reusable template, you can do something like
template isIndexable(I, T)
{
enum isIndexable = __traits(compiles, T.init[I.init]);
}
auto fun(I, T)(I index, T obj)
if(isIndexable!(I, T))
{
return obj[index];
}
Personally, I think that having code that accepts any type that
can be indexable with any type isn't a particularly good idea,
because odds are, it won't actually work, because those
different types will work quite differently (e.g. associative
arrays are indexable with stuff other than size_t, but they're
really not interchangeable with dynamic arrays or static
arrays, which use size_t). And anything that wants to be
interchangeable with a dynamic array or be usable as a random
access range should be using size_t to index. But if you
This is exactly what my question is about. I don't think, that it
doesn't make sense (and isn't a good idea) to index with an
arbitrary type, too.
So, how I can define/design a type, which is not an int/size_t,
but has one to be able to index with it?
And if the __compiles trait is the way to go with... well then
that's just how it is...
Re: Indexing with an arbitrary type
On Monday, August 01, 2016 15:25:59 Alex via Digitalmars-d-learn wrote:
> On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis wrote:
> > If you want a template constraint that checks that a type works
> > with the index operator on a type, and you're not restricting
> > it to something like size_t, then you're just going to have to
> > check whether the expression is going to compile. Also, that is
> > incompatible with random access ranges. Random access ranges
> > are expected to work with size_t, and while isRandomAccessRange
> > isn't currently quite that restrictive, it does check that r[1]
> > compiles, so the index operator is going to have to accept
> > integers at minimum. If you want a completely generic index
> > operator, and you want a template constraint for it, you're
> > pretty much going to have to test that it compiles. e.g.
> >
> > auto fun(I, T)(I index, T obj)
> > if(__traits(compiles, obj[index]))
> > {
> > return obj[index];
> > }
> >
> > or if you want a reusable template, you can do something like
> >
> > template isIndexable(I, T)
> > {
> > enum isIndexable = __traits(compiles, T.init[I.init]);
> > }
> >
> > auto fun(I, T)(I index, T obj)
> >
> > if(isIndexable!(I, T))
> > {
> > return obj[index];
> > }
> >
> > Personally, I think that having code that accepts any type that
> > can be indexable with any type isn't a particularly good idea,
> > because odds are, it won't actually work, because those
> >
> > different types will work quite differently (e.g. associative
> > arrays are indexable with stuff other than size_t, but they're
> > really not interchangeable with dynamic arrays or static
> > arrays, which use size_t). And anything that wants to be
> > interchangeable with a dynamic array or be usable as a random
> > access range should be using size_t to index. But if you
>
> This is exactly what my question is about. I don't think, that it
> doesn't make sense (and isn't a good idea) to index with an
> arbitrary type, too.
The issue is that the semantics have to be sufficiently similar across the
types that the code will work. And if your code is doing much beyond
indexing, it probably won't. But if it does in your case, then great.
> So, how I can define/design a type, which is not an int/size_t,
> but has one to be able to index with it?
>
> And if the __compiles trait is the way to go with... well then
> that's just how it is...
You're pretty much going to have to go with some form of
__traits(compiles, ...) to test the code that the code that you want to code
compiles. That's ultimately what a lot of traits do. And if what you're
looking to test is that obj[index] works where obj and index are arbitrary
types, what else would you be testing for anyway? You'd only need to test
for more beyond that if you were trying to further restrict the types
involved and/or to require that some other set of operations compiled in
addition to indexing.
- Jonathan M Davis
Struct dtor on ref variable
struct Test{
int x;
this(int v){
x = v;
writeln(x.to!string ~ " Created");
}
~this(){
writeln(x.to!string ~ " Destroyed");
}
void opOpAssign(string op, Type)(ref Type s){
x = s.x;
}
}
void showme(Type)(ref Type t){
writeln(t.x);
}
void main(){
auto t = Test(1);
auto t2 = Test(2);
showme(t);
showme(t2);
t = t2;
}
Prints:
1 Created
2 Created
1
2
1 Destroyed
2 Destroyed
2 Destroyed
this line:
t = t2
Causes the dtor to be called.
Why?
I expected nothing to happen because "ref" its a simple pointer,
right?
Or I am missing something here?
Re: Struct dtor on ref variable
On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve
Re: Indexing with an arbitrary type
On Monday, 1 August 2016 at 15:51:58 UTC, Jonathan M Davis wrote:
On Monday, August 01, 2016 15:25:59 Alex via
Digitalmars-d-learn wrote:
On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis
wrote:
> If you want a template constraint that checks that a type
> works with the index operator on a type, and you're not
> restricting it to something like size_t, then you're just
> going to have to check whether the expression is going to
> compile. Also, that is incompatible with random access
> ranges. Random access ranges are expected to work with
> size_t, and while isRandomAccessRange isn't currently quite
> that restrictive, it does check that r[1] compiles, so the
> index operator is going to have to accept integers at
> minimum. If you want a completely generic index operator,
> and you want a template constraint for it, you're pretty
> much going to have to test that it compiles. e.g.
>
> auto fun(I, T)(I index, T obj)
> if(__traits(compiles, obj[index]))
> {
> return obj[index];
> }
>
> or if you want a reusable template, you can do something like
>
> template isIndexable(I, T)
> {
> enum isIndexable = __traits(compiles, T.init[I.init]);
> }
>
> auto fun(I, T)(I index, T obj)
>
> if(isIndexable!(I, T))
> {
> return obj[index];
> }
>
> Personally, I think that having code that accepts any type
> that can be indexable with any type isn't a particularly
> good idea, because odds are, it won't actually work, because
> those
>
> different types will work quite differently (e.g.
> associative arrays are indexable with stuff other than
> size_t, but they're really not interchangeable with dynamic
> arrays or static arrays, which use size_t). And anything
> that wants to be interchangeable with a dynamic array or be
> usable as a random access range should be using size_t to
> index. But if you
This is exactly what my question is about. I don't think, that
it doesn't make sense (and isn't a good idea) to index with an
arbitrary type, too.
The issue is that the semantics have to be sufficiently similar
across the types that the code will work. And if your code is
doing much beyond indexing, it probably won't. But if it does
in your case, then great.
So, how I can define/design a type, which is not an
int/size_t, but has one to be able to index with it?
And if the __compiles trait is the way to go with... well then
that's just how it is...
You're pretty much going to have to go with some form of
__traits(compiles, ...) to test the code that the code that you
want to code
compiles. That's ultimately what a lot of traits do. And if
what you're
looking to test is that obj[index] works where obj and index
are arbitrary
types, what else would you be testing for anyway? You'd only
need to test
for more beyond that if you were trying to further restrict the
types
involved and/or to require that some other set of operations
compiled in
addition to indexing.
- Jonathan M Davis
Got it... Thanks :)
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer wrote: On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve Same thing: (Remembered now of DPaste) (and I understand your concern :P) https://dpaste.dzfl.pl/af512b5f6288
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer wrote: On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve Sorry, silly me, forgot to remove the "string op" now its ok :)
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:14:31 UTC, Patric wrote: On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer wrote: On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve Same thing: (Remembered now of DPaste) (and I understand your concern :P) https://dpaste.dzfl.pl/af512b5f6288 You've implemented opAssign incorrectly. See: https://dlang.org/spec/operatoroverloading.html#assignment
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:17:02 UTC, Patric wrote: On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer wrote: On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve Sorry, silly me, forgot to remove the "string op" now its ok :) Well, you beat me to it :)
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:18:32 UTC, Patric wrote: But still. If it was the case of "+=" wasn´t wrong to call the dtor since is a ref var? No. It was working as expected. You never implemented opAssign, so default assignment was being used. There was no ref variable.
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:21:16 UTC, Mike Parker wrote: On Monday, 1 August 2016 at 16:18:32 UTC, Patric wrote: But still. If it was the case of "+=" wasn´t wrong to call the dtor since is a ref var? No. It was working as expected. You never implemented opAssign, so default assignment was being used. There was no ref variable. Iep, I realized this by now. Thanks anyway :)
Re: Struct dtor on ref variable
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer wrote: On 8/1/16 12:01 PM, Patric wrote: I expected nothing to happen because "ref" its a simple pointer, right? Or I am missing something here? You want opAssign, not opOpAssign. opOpAssign is for things like +=. Your code had me worried for a while :) -Steve But still. If it was the case of "+=" wasn´t wrong to call the dtor since is a ref var?
[OT] Re: Why D isn't the next "big thing" already
On Sunday, 31 July 2016 at 18:15:49 UTC, Gorge Jingale wrote: On Sunday, 31 July 2016 at 10:11:46 UTC, LaTeigne wrote: On Saturday, 30 July 2016 at 12:24:55 UTC, ketmar wrote: On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote: it you think that you know the things better than somebody who actually *lived* there in those times... well, keep thinking that. also, don't forget to teach physics to physicians, medicine to medics, and so on. i'm pretty sure that you will have a great success as a stupidiest comic they ever seen in their life. also, don't bother answering me, i won't see it anyway. https://forums.embarcadero.com/thread.jspa?messageID=831486 Again an evidence of your super ego. You think that your own experiences stand for everybody while it's actually representing anything byt you, which is quite near from the nil. He clearly suffers from NPD. I believe this is due to ignorance of experience. With such little real world experience one conjures up their own fabricated sense of reality that revolves around themselves. Such people lack the ability to understand others experiences and write them off because they do not coincide with their own. It's a form of the god complex, yet clearly these people are not god and generally not even that intelligent, experienced in life , etc, or happen just to be good at one thing which they treat as the only thing that matters; which is illogical and insane but very convenient for them. No his condition is not NPD. The other day he said publicly on IRC what it's but I don't remember the exact name. But it's serious, e.g you can find it in the DSM-5, with a specific code, designation etc. Let's close this discussion for real this time. I'm sorry for the trolling but at a time i wanted to be right for this stupid story of academic license...
Re: Question regarding Base64 decoding
On Monday, 1 August 2016 at 08:53:30 UTC, Kagamin wrote: A bug. ... which should be filled at Bugzilla and/or fixed. Thanks! :)
Re: FP magic in std.math.pow
On Sunday, 31 July 2016 at 22:45:16 UTC, Stefan Koch wrote:
On Sunday, 31 July 2016 at 22:38:59 UTC, Seb wrote:
Consider this short program:
void main()
{
alias S = float;
S s1 = 0x1.24c92ep+5;
S s2 = -0x1.1c71c8p+0;
[...]
It's an anoying feature.
The reason this is not implemented in dmd is that pow does not
map to a simple cpu instruction on x86.
I will have another shot at fixing this once the CTFE stuff is
in.
It's about 1000 instructions with std.math.pow.
Yeah any improvement of the FP magic in DMD would be highly
appreciated ;-)
prolog and epilog code
Can one add code that executes before the GC and any memory is normally allocated(even static) and after all of it was suppose to be released? A sort of static this for the whole app. I would like to monitor the memory of the app to make sure that the total memory before and after is equal. I use my own memory routines but would like something where I can write out the information after all destructors have been called. I have malloc and free wrapped and simply add the total memory used and released. These, of course, should be the same *after* program termination. But, I can't wait that long ;)
Re: Autodecode in the wild and An Awful Hack to std.regex
On Thursday, 28 July 2016 at 21:02:59 UTC, John Carter wrote: On Thursday, 28 July 2016 at 15:48:58 UTC, Seb wrote: [...] Eh. I hoped that somewhere in that explosion of discussion on the topic the problem had been solved and I had just missed it and merely had to use that. Also this idea is a bit immature for a DIP... I haven't look at the regex code beyond the the stack trace it died on. ie. * Would this even be a Good Idea for a dip or is it better solve by another existing means? * I only inspected and changed one occurrence of decode (the one that broke) is there any other route in the regex engine that could throw a UTFException? * Would adding an additional template parameter with default break existing code? Or would I have to provide a shim? I suggest you talk to Dmitry, who wrote std.regex, as he will be motivated to look into this.
Re: LDC with ARM backend
On Thursday, 21 July 2016 at 13:13:39 UTC, Claude wrote: On Thursday, 21 July 2016 at 10:30:55 UTC, Andrea Fontana wrote: On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote: I can build a "Hello world" program on ARM GNU/Linux, with druntime and phobos. I'll write a doc page about that. It's a good idea :) Done: https://wiki.dlang.org/LDC_cross-compilation_for_ARM_GNU/Linux I based it totally on Kai's previous page for LDC on Android. It lacks the build for druntime/phobos unit-tests. Sorry, I didn't see this thread till now, or I could have saved you some time by telling you not to apply the llvm patch on non-Android linux. Note that you don't have to compile llvm yourself at all, as long as the system llvm has the ARM backend built in, as it often does.
