On Thursday, 13 October 2016 at 22:12:42 UTC, Guillaume Piolat
wrote:
On Thursday, 13 October 2016 at 19:06:26 UTC, Karabuta wrote:
I agree, something friendly and familiar would be called for.
Instead we have weird float-rounding programs.
The goal of such program should be to push the read
Hello,
can someone look at this quite simple bug in dmd please?
https://issues.dlang.org/show_bug.cgi?id=16590
I cannot release non-opensource libraries without this.
On Saturday, 15 October 2016 at 06:51:44 UTC, Satoshi wrote:
Hello,
can someone look at this quite simple bug in dmd please?
https://issues.dlang.org/show_bug.cgi?id=16590
I cannot release non-opensource libraries without this.
You mean auto ref right ?
please attach a small test-case.
You ca
On Friday, 14 October 2016 at 13:17:39 UTC, Andrei Alexandrescu
wrote:
s/Sadly/Fortunately because now we have smart graduate students
looking for cool projects/
...like reimplementing the whole DMDFE for nothing. this tool
would be useless without full-featured template and CTFE support
(as
On Friday, 14 October 2016 at 15:42:22 UTC, David Nadlinger wrote:
On Friday, 14 October 2016 at 13:07:10 UTC, Johan Engelen wrote:
On Friday, 14 October 2016 at 12:55:17 UTC, Guillaume Piolat
wrote:
- this pointer is aligned to N bytes
- this pointer doesn't alias with this pointer
Do you m
https://issues.dlang.org/show_bug.cgi?id=8507
Thanks!
Andrei
The module aims to provide portable interface to virtual memory
management unit of the OS. Some common recipes such as locking memory
and allocating executable memory should be easily accessible.
In general the task is next to impossible and therefore capabilities of
the current OS are capture
On Tuesday, 11 October 2016 at 01:37:55 UTC, Martin Nowak wrote:
Whatever makes more sense. From my very limited understanding
.msi installers are natively understood installers in Windows,
and the weapon of choice for robust and more professional
installers.
If innosetup is just another NSIS l
On Wednesday, 12 October 2016 at 06:39:05 UTC, Thomas Mader wrote:
On Tuesday, 11 October 2016 at 06:09:03 UTC, Thomas Mader wrote:
I worked with NSIS and InnoSetup. InnoSetup is much cleaner
and easier.
At work we switched from NSIS to InnoSetup and we create MSI
packages from NSIS and InnoSet
Is there a way to check if a pointer is supposed to point to
non-GC allocated memory? I presume not. This is needed to prevent
unnecessary calls to `GC.addRange` in containers with elements of
a type that in turn is a container-like struct with non-GC
allocated memory.
If not, maybe we could
On Saturday, 15 October 2016 at 00:50:08 UTC, Stefan Koch wrote:
On Friday, 14 October 2016 at 20:47:39 UTC, Stefan Koch wrote:
On Thursday, 13 October 2016 at 21:49:22 UTC, safety0ff wrote:
Bad benchmark! Bad! -- Andrei
Also, I suspect a benchmark with a larger loop body might not
benefit a
Oooops, I should not post after drinking 2 glasses of
Châteauneuf-du-pape. That function does exactly the contrary of
what popFront does. This one is conversion from dchar to
multibyte not multibyte to dchar as you did.
Sorry for the inconvenience.
Digital Mars C++ bug reports can be filed here:
http://bugzilla.digitalmars.com/issues/
It's awfully slow.
On 10/15/2016 12:22 PM, Nordlöw wrote:
Is there a way to check if a pointer is supposed to point to non-GC
allocated memory? I presume not. This is needed to prevent unnecessary
calls to `GC.addRange` in containers with elements of a type that in
turn is a container-like struct with non-GC alloca
On 10/15/2016 12:42 PM, Patrick Schluter wrote:
Sorry if I do not participate on the testing as I don't have a proper
compilation environment here at home.
https://ldc.acomirei.ru
Andrei
On Saturday, 15 October 2016 at 17:11:28 UTC, Andrei Alexandrescu
wrote:
Seems there'd be quite some annotational overhead.
In the case of a C++-style vector it's just a matter of changing
E* _ptr;// non-GC-allocated store pointer
to
@nogc E* _ptr; // GC-allo
On Saturday, 15 October 2016 at 17:19:53 UTC, Nordlöw wrote:
E* _ptr;// non-GC-allocated store pointer
to
@nogc E* _ptr; // GC-allocated store pointer
should, of course, be
E* _ptr;// GC-allocated store pointer
to
@nogc E* _ptr;
On 10/15/2016 07:19 PM, Nordlöw wrote:
and then updating the relevant trait, such as `hasIndirections` or/and
`hasAliasing`, to respect this attribute.
How would those traits have to updated? An indirection is an indirection
no matter if it points to GC memory or not. Maybe we'd need a new tra
On Saturday, 15 October 2016 at 16:22:35 UTC, Nordlöw wrote:
Is there a way to check if a pointer is supposed to point to
non-GC allocated memory? I presume not. This is needed to
prevent unnecessary calls to `GC.addRange` in containers with
elements of a type that in turn is a container-like s
On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
To be honest I find this system way more useful that the
function attribute @nogc.
My trait is here
(https://github.com/BBasile/iz/blob/master/import/iz/memory.d#L145) but it's quite similar to the one used in EMSI containers (with d
It can also be written like this producing smaller code.
But it the cost of slower decoding.
dchar myFront(ref char[] str) pure
{
dchar c = cast(dchar) str.ptr[0];
if (c & 128)
{
if (c & 64)
{
int idx = 0;
int l = charWidthTab.ptr[c - 192];
On Saturday, 15 October 2016 at 18:03:54 UTC, Nordlöw wrote:
On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
To be honest I find this system way more useful that the
function attribute @nogc.
My trait is here
(https://github.com/BBasile/iz/blob/master/import/iz/memory.d#L145) but
On Saturday, 15 October 2016 at 18:40:11 UTC, Uplink_Coder wrote:
It can also be written like this producing smaller code.
But it the cost of slower decoding.
dchar myFront(ref char[] str) pure
{
dchar c = cast(dchar) str.ptr[0];
if (c & 128)
{
if (c & 64)
{
At least with that lookup table below, you can detect isolated
continuation bytes (192 and 193) and invalid codes (above 244).
__gshared static immutable ubyte[] charWidthTab = [
1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter
wrote:
At least with that lookup table below, you can detect isolated
continuation bytes (192 and 193) and invalid codes (above 244).
192 and 193 can never appear in a UTF-8 text, they are overlongs
not continuation bytes. Continua
On Saturday, 15 October 2016 at 19:00:12 UTC, Patrick Schluter
wrote:
Just a question. Do encoding errors not have to be detected or
is validity of the string guaranteed?
AFAIK they have to be detected, otherwise it would be a
regression.
On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
I agree. We are several people to do it already. I've started
to during last spring (see
https://forum.dlang.org/post/ficbsdfokvbvslatm...@forum.dlang.org).
So far I use "@NoGc" and "@TellGcRange" added.
Why does the template argu
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter
wrote:
At least with that lookup table below, you can detect isolated
continuation bytes (192 and 193) and invalid codes (above 244).
__gshared static immutable ubyte[] charWidthTab = [
1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2
On Friday, 14 October 2016 at 21:18:45 UTC, Karabuta wrote:
The "!" is more trouble than good (IMO for the majority).
@Adam Roupe did a talk at previous DConf which he testifies to
this.
Couldn't be me, I don't think I ever talked about it... and I'm
actually pro-!. It is a perfectly fine sy
On 10/16/2016 11:36 AM, Ilya Yaroshenko wrote:
> Hi,
>
> Extern precompiled Mir GLAS requires additional API changes.
> Reduced example:
>
> ```d
> struct S(T)
> {
> size_t len;
> T ptr;
> }
>
> auto foo(S!(const(double)*) sl)
> {
> }
>
> S!(double*) a;
> const S!(double*) b;
>
> foo(a); /
On Saturday, 15 October 2016 at 00:11:35 UTC, deadalnix wrote:
His argument about indices was also weak as it tells more about
the need to use size_t rather than 32 bits indices when doing
indices computation.
Yeah I found that part of the talk interesting but overall
unconvincing. Just using
On Sunday, 16 October 2016 at 10:05:37 UTC, Patrick Schluter
wrote:
On Sunday, 16 October 2016 at 08:43:23 UTC, Uplink_Coder wrote:
On Sunday, 16 October 2016 at 07:59:16 UTC, Patrick Schluter
wrote:
This looks quite slow.
We already have a correct version in utf.decodeImpl.
The goal here was
On Sunday, 16 October 2016 at 08:36:17 UTC, Ilya Yaroshenko wrote:
Hi,
Extern precompiled Mir GLAS requires additional API changes.
Reduced example:
```d
struct S(T)
{
size_t len;
T ptr;
}
auto foo(S!(const(double)*) sl)
{
}
S!(double*) a;
const S!(double*) b;
foo(a); // fails
foo(b); //
I was thinking it would be handy if tuples had a way to access a field
by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
The get method takes the field name and the type of the presumed field,
and it returns the value
On 10/16/16 3:58 PM, Andrei Alexandrescu wrote:
I was thinking it would be handy if tuples had a way to access a field
by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
I swear I've seen a pull request merged that add
On Sunday, 16 October 2016 at 16:07:19 UTC, Nick Treleaven wrote:
// Chain functions together to round a string parsed as a real
number
alias roundString = pipe!(to!real, std.math.round, to!string);
In fact if we're just printing the rounded numbers, we can drop
to!string and inline roundStri
On Thursday, 13 October 2016 at 19:06:26 UTC, Karabuta wrote:
// Replace anything that looks like a real
// number with the rounded equivalent.
stdin
.byLine
.map!(l => l.replaceAll!(c => c.hit.round)
(reFloatingPoint))
.each!wri
On 10/16/2016 11:07 AM, Dmitry Olshansky wrote:
On 10/16/16 3:58 PM, Andrei Alexandrescu wrote:
I was thinking it would be handy if tuples had a way to access a field
by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
On Sunday, 16 October 2016 at 13:17:09 UTC, Nicholas Wilson wrote:
On Sunday, 16 October 2016 at 08:36:17 UTC, Ilya Yaroshenko
wrote:
Hi,
Extern precompiled Mir GLAS requires additional API changes.
Reduced example:
```d
struct S(T)
{
size_t len;
T ptr;
}
auto foo(S!(const(double)*) sl)
{
On Sunday, 16 October 2016 at 10:05:37 UTC, Patrick Schluter
wrote:
Next step will be to loop for length 2,3,4, with or without
your table.
Ok now the looped version which doesn't need the lookup table.
This one assembles in 72 lines of assembly (25 lines only for the
exception code).
dch
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu
wrote:
I was thinking it would be handy if tuples had a way to access
a field by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
That would mean that tup
On Saturday, 15 October 2016 at 10:17:09 UTC, Matthias Bentrup
wrote:
You could turn "hints" that can possibly create invalid code
automatically into assertions in non-release builds. Or let the
user add an assertion and use the "turn assert() into assume()"
idea for release builds.
I canno
On Saturday, 15 October 2016 at 19:36:19 UTC, Nordlöw wrote:
On Saturday, 15 October 2016 at 17:48:13 UTC, Basile B. wrote:
I agree. We are several people to do it already. I've started
to during last spring (see
https://forum.dlang.org/post/ficbsdfokvbvslatm...@forum.dlang.org).
So far I use
https://issues.dlang.org/show_bug.cgi?id=8507
Thanks! -- Andrei
On 10/14/2016 3:56 PM, Andrei Alexandrescu via Digitalmars-d wrote:
So I just added https://issues.dlang.org/show_bug.cgi?id=16614, which is
a meta documentation issue for bootcamp.
I'd appreciate it if any of you folks kept in mind to add separate
issues (and make this one depend on them) whene
On Saturday, 15 October 2016 at 19:42:03 UTC, Uplink_Coder wrote:
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter
wrote:
At least with that lookup table below, you can detect isolated
continuation bytes (192 and 193) and invalid codes (above 244).
__gshared static immutable ubyt
On Wednesday, 12 October 2016 at 10:34:52 UTC, Era Scarecrow
wrote:
Anyways, 16bit replacement, extending to 64bit via reordering,
and 8 unique xor's between stages. Once I get the 576 block
finished (1 for salt) I'll probably publish my ugly code for
consideration and to be torn apart for sec
On Sat, 15 Oct 2016 16:22:35 +, Nordlöw wrote:
> Is there a way to check if a pointer is supposed to point to non-GC
> allocated memory?
You can check if it *does* point to GC-allocated memory if you use GC
internals -- the Pool struct is what you want to look at, and the lookup
methods ass
On Saturday, 15 October 2016 at 21:21:22 UTC, Stefan Koch wrote:
On Saturday, 15 October 2016 at 19:42:03 UTC, Uplink_Coder
wrote:
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter
wrote:
At least with that lookup table below, you can detect
isolated continuation bytes (192 and 193
Here my version. It's probably not the shortest (100 ligns of
assembly with LDC) but it is correct and has following properties:
- Performance proportional to the encoding length
- Detects Invalid byte sequences
- Detects Overlong encodings
- Detects Invalid code points
I put the exception to be
Hi,
Extern precompiled Mir GLAS requires additional API changes.
Reduced example:
```d
struct S(T)
{
size_t len;
T ptr;
}
auto foo(S!(const(double)*) sl)
{
}
S!(double*) a;
const S!(double*) b;
foo(a); // fails
foo(b); // fails
```
https://issues.dlang.org/show_bug.cgi?id=16616
On Sunday, 16 October 2016 at 07:59:16 UTC, Patrick Schluter
wrote:
Here my version. It's probably not the shortest (100 ligns of
assembly with LDC) but it is correct and has following
properties:
- Performance proportional to the encoding length
- Detects Invalid byte sequences
- Detects Overl
On Sunday, 16 October 2016 at 04:14:42 UTC, Chris Wright wrote:
On Sat, 15 Oct 2016 16:22:35 +, Nordlöw wrote:
Is there a way to check if a pointer is supposed to point to
non-GC allocated memory?
You can check if it *does* point to GC-allocated memory if you
use GC internals -- the Pool
On Sunday, 16 October 2016 at 08:43:23 UTC, Uplink_Coder wrote:
This looks quite slow.
We already have a correct version in utf.decodeImpl.
The goal here was to find a small and fast alternative.
A: What's 2 + 2?
B: 3
A: That's wrong.
B: But incredibly fast.
On Sunday, 16 October 2016 at 08:43:23 UTC, Uplink_Coder wrote:
On Sunday, 16 October 2016 at 07:59:16 UTC, Patrick Schluter
wrote:
This looks quite slow.
We already have a correct version in utf.decodeImpl.
The goal here was to find a small and fast alternative.
I know but it has to be corr
On Saturday, 15 October 2016 at 00:11:35 UTC, deadalnix wrote:
On Thursday, 13 October 2016 at 15:19:17 UTC, Guillaume
Chatelet wrote:
Pretty cool talk by Chandler Carruth on undefined behavior. It
reminds me of a bunch of conversations than happened on this
mailing list. I bet Walter will like
On Sun, 16 Oct 2016 18:51:06 +, Sebastiaan Koppe wrote:
> On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu wrote:
>> I was thinking it would be handy if tuples had a way to access a field
>> by name at runtime. E.g.:
>>
>> Tuple!(int, "a", double, "b") t;
>> string x = condition
On Wed, 05 Oct 2016 02:11:14 +, Meta wrote:
> I'm currently writing up a DIP to propose removing `body` as a keyword
> to allow it to be used for variable names, functions, etc. I'm looking
> for examples and contexts where `body` would normally be used as a
> variable, function name, alias, e
On 16.10.2016 14:18, Dicebot wrote:
This issue has been discussed before in context of custom containers and
AFAIK so far no one was able to come up with even theoretical concept of
how it can be possibly addressed.
Actually, I did propose a solution before. Just allow annotations on
template
Long story short, it si clearly a waste of time. Qualifying the
process would be an understatement.
Some specifically DIP27 has been written in Feb 2913, following
various discussion at that time. I pushed it at the time. I moved
it to the new git DIP repository. Got mostly irrelevant feedback
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu
wrote:
I was thinking it would be handy if tuples had a way to access
a field by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a" : "b";
double v = t.get!string(x, 3.14);
The get method takes the
On Sunday, 16 October 2016 at 20:11:01 UTC, Chris Wright wrote:
On Sun, 16 Oct 2016 18:51:06 +, Sebastiaan Koppe wrote:
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei
Alexandrescu wrote:
I was thinking it would be handy if tuples had a way to
access a field by name at runtime. E.g.:
On Sunday, 16 October 2016 at 22:17:15 UTC, deadalnix wrote:
Long story short, it si clearly a waste of time. Qualifying the
process would be an understatement.
Some specifically DIP27 has been written in Feb 2913, following
various discussion at that time. I pushed it at the time. I
moved it
On Sunday, 16 October 2016 at 18:51:06 UTC, Sebastiaan Koppe
wrote:
On Sunday, 16 October 2016 at 13:58:51 UTC, Andrei Alexandrescu
wrote:
I was thinking it would be handy if tuples had a way to access
a field by name at runtime. E.g.:
Tuple!(int, "a", double, "b") t;
string x = condition ? "a
Listen, I understand you are not interested in spending loads of
time on boring polishing of formalities. We all do this in our
spare time so that is to be expected.
But what you say here only shows that process is working as
intended - and that it is not suitable for you. Quote from
readme:
On Monday, 17 October 2016 at 02:08:44 UTC, Dicebot wrote:
Listen, I understand you are not interested in spending loads
of time on boring polishing of formalities. We all do this in
our spare time so that is to be expected.
I spent fuck 4;5 years on that thing. Don't come at me saying I'm
On 10/17/2016 12:57 AM, Timon Gehr wrote:
> On 16.10.2016 14:18, Dicebot wrote:
>> This issue has been discussed before in context of custom containers and
>> AFAIK so far no one was able to come up with even theoretical concept of
>> how it can be possibly addressed.
>
> Actually, I did propose a
On 10/15/2016 02:50 PM, Basile B. wrote:
I've given up with the idea of proposing my stuff in phobos. About
memory there would also have be:
- allocators-based factory (https://github.com/dlang/phobos/pull/4062)
- @nogc dispose (https://github.com/dlang/phobos/pull/4351)
But each time the PR wa
On 10/16/2016 3:17 PM, deadalnix wrote:
Long story short, it si clearly a waste of time. Qualifying the process would be
an understatement.
Some specifically DIP27 has been written in Feb 2913, following various
discussion at that time. I pushed it at the time. I moved it to the new git DIP
repo
On 2016-10-17 04:08, Dicebot wrote:
Listen, I understand you are not interested in spending loads of time on
boring polishing of formalities. We all do this in our spare time so
that is to be expected.
But what you say here only shows that process is working as intended
Well, the designed of t
On 10/17/2016 01:02 AM, Walter Bright wrote:
On 10/16/2016 3:17 PM, deadalnix wrote:
Long story short, it si clearly a waste of time. Qualifying the
process would be
an understatement.
Some specifically DIP27 has been written in Feb 2913, following various
discussion at that time. I pushed it a
On 10/16/2016 11:39 PM, Jacob Carlborg wrote:
Most likely Andrei already merged Walter's PR for DMD for this DIP,
> three weeks ago after being open for two hours.
What are you referring to?
72 matches
Mail list logo
