Re: Code signing to help with Windows virus false positives
On Tuesday, 11 October 2016 at 01:37:55 UTC, Martin Nowak wrote: On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote: "to MSI using innosetup" ? There's a misunderstanding here. Inno setup doesn't compile to MS installer, it's a complete independant solution. 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 like tool, it might not solve all our problems. We're fairly clueless here and could really use help here. Just signing the NSIS installers could work for now, any support for this hypothesis. I tried to submit the latest release as sample to Microsoft but their file upload had a size limit smaller than the binary. 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 InnoSetup packages IIRC. I think it's better to go with InnoSetup because it might be more easy and probably more powerful than building MSI directly. But I don't have any experience with building an MSI installer and the feature set of MSI. We are also signing the installer and all exe and DLLs inside.
Re: Batch operations
On Tuesday, 11 October 2016 at 03:20:54 UTC, Stefan Koch wrote: On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson wrote: Splitting this from the colour thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1). [...] This will bloat like hell. The best way would be to provide special Range-Definitions for those. Such as T[4] Front4 () or popFront4 It will be possible to have an overload for ranges that have slicing, that copies in chunks.
Re: Can you shrink it further?
On Tuesday, 11 October 2016 at 03:58:59 UTC, Andrei Alexandrescu
wrote:
On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward -
ideally the
case c < 127 would simply entail a quick return. I tried a
fix, but it
didn't do what I wanted in ldc. We shouldn't assert(0) if
wrong - just
skip one byte. Also, are we right to not worry about 5- and
6-byte
sequences? The docs keep on threatening with it, and then
immediately
mention those are not valid.
[ ... ]
Andrei
If you want to skip a byte it's easy to do as well.
void popFront3(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1;
if (c < 127)
{
Lend :
s = s.ptr[char_length .. s.length];
} else {
if ((c & b01100_) == 0b1000_)
{
//just skip one in case this is not the beginning of a
code-point
char
goto Lend;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240)
{
char_length = 3;
goto Lend;
}
if (c < 248)
{
char_length = 4;
goto Lend;
}
}
}
Affirmative. That's identical to the code in "[ ... ]" :o).
Generated code still does a jmp forward though. -- Andrei
It was not identical.
((c & b01100_) == 0b1000_))
Can be true in all of the 3 following cases.
If we do not do a jmp to return here, we cannot guarantee that we
will not skip over the next valid char.
Thereby corrupting already corrupt strings even more.
For best performance we need to leave the gotos in there.
Re: Linker Error: undefined reference to `internal'
On 10/10/2016 3:20 PM, jython234 wrote: I've tracked it down to two lines (which are the same): private SyncLock lock = new SyncLock(); SyncLock is just an empty class which I use to construct objects for use in "synchronized" blocks (not sure if this is the right way to do this). Apparently if I move the initialization to the constructor there are no linker errors. You can use obj2asm to examine the object files to see what is different between the two cases.
Re: Can you shrink it further?
On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei Alexandrescu wrote:
That looks good. I'm just worried about the jump forward - ideally the
case c < 127 would simply entail a quick return. I tried a fix, but it
didn't do what I wanted in ldc. We shouldn't assert(0) if wrong - just
skip one byte. Also, are we right to not worry about 5- and 6-byte
sequences? The docs keep on threatening with it, and then immediately
mention those are not valid.
[ ... ]
Andrei
If you want to skip a byte it's easy to do as well.
void popFront3(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1;
if (c < 127)
{
Lend :
s = s.ptr[char_length .. s.length];
} else {
if ((c & b01100_) == 0b1000_)
{
//just skip one in case this is not the beginning of a code-point
char
goto Lend;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240)
{
char_length = 3;
goto Lend;
}
if (c < 248)
{
char_length = 4;
goto Lend;
}
}
}
Affirmative. That's identical to the code in "[ ... ]" :o). Generated
code still does a jmp forward though. -- Andrei
Re: Can you shrink it further?
On Tuesday, 11 October 2016 at 03:18:24 UTC, Lurker wrote:
Pardon me asking, but why all these gotos instead of else ifs:
if (c < 192)
{
char_length = 2;
}
else if (c < 240)
{
char_length = 3;
} else if (...) {
}
Does it have any effect on generated code (I don't think it
should)?
No it does not.
I wrote the gotos because that is how I am used to thinking about
code.
If else should work fine here.
Re: Batch operations
On 11/10/2016 4:20 PM, Stefan Koch wrote: On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson wrote: Splitting this from the colour thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1). [...] This will bloat like hell. The best way would be to provide special Range-Definitions for those. Such as T[4] Front4 () or popFront4 We would also want 2, 8 and 16 for SIMD reasons.
Re: Batch operations
On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson wrote: Splitting this from the colour thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1). [...] This will bloat like hell. The best way would be to provide special Range-Definitions for those. Such as T[4] Front4 () or popFront4
Re: Can you shrink it further?
On Tuesday, 11 October 2016 at 03:00:45 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward -
ideally the case c < 127 would simply entail a quick return. I
tried a fix, but it didn't do what I wanted in ldc. We
shouldn't assert(0) if wrong - just skip one byte. Also, are
we right to not worry about 5- and 6-byte sequences? The docs
keep on threatening with it, and then immediately mention
those are not valid.
[ ... ]
Andrei
If you want to skip a byte it's easy to do as well.
void popFront3(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1;
if (c < 127)
{
Lend :
s = s.ptr[char_length .. s.length];
} else {
if ((c & b01100_) == 0b1000_)
{
//just skip one in case this is not the beginning of a
code-point char
goto Lend;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240)
{
char_length = 3;
goto Lend;
}
if (c < 248)
{
char_length = 4;
goto Lend;
}
}
}
Pardon me asking, but why all these gotos instead of else ifs:
if (c < 192)
{
char_length = 2;
}
else if (c < 240)
{
char_length = 3;
} else if (...) {
}
Does it have any effect on generated code (I don't think it
should)?
Batch operations
Splitting this from the colour
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).
So currently D does not have a way to express batch operations
that work seamlessly with normal ranges.
Manu suggested to use the array operation syntax. I suggest
something along the lines of the following, forwarding any
operations to the static array.
struct InBatchesOfN(size_t N,R) if( N!=0 && isInputRange!R
&&
hasLength!R)
{
R r;
static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[]; }
alias get this;
Batch opBinary(string op)(Batch rhs)
if(hasOperator!(ElementType!(R),op))
{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] =
elememts[i] "~op~" rhs.elements[i]");
return b;
}
//repeat for opUnary,opOpAssign,opDispatch etc...
}
Batch batch;
this(R _r)
{
// could have overloads where undefined elements ==
ElementType!(R).init
assert(_r.length % N ==0);
r = _r;
foreach( i; iota(N))
{
batch[i] = r.front;
r.popFront;
}
}
bool empty() { return r.empty; }
auto front() { return batch; }
void popFront()
{
foreach(i; iota(N))
{
batch.elements[i] = r.front;
r.popFront;
}
}
}
auto inBatchesOf(size_t N,R)(R r)
{
return InBatchesOfN(r);
}
Thoughts?
Re: Can you shrink it further?
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei Alexandrescu
wrote:
That looks good. I'm just worried about the jump forward -
ideally the case c < 127 would simply entail a quick return. I
tried a fix, but it didn't do what I wanted in ldc. We
shouldn't assert(0) if wrong - just skip one byte. Also, are we
right to not worry about 5- and 6-byte sequences? The docs keep
on threatening with it, and then immediately mention those are
not valid.
[ ... ]
Andrei
If you want to skip a byte it's easy to do as well.
void popFront3(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1;
if (c < 127)
{
Lend :
s = s.ptr[char_length .. s.length];
} else {
if ((c & b01100_) == 0b1000_)
{
//just skip one in case this is not the beginning of a
code-point char
goto Lend;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240)
{
char_length = 3;
goto Lend;
}
if (c < 248)
{
char_length = 4;
goto Lend;
}
}
}
Re: Can you shrink it further?
That looks good. I'm just worried about the jump forward - ideally the
case c < 127 would simply entail a quick return. I tried a fix, but it
didn't do what I wanted in ldc. We shouldn't assert(0) if wrong - just
skip one byte. Also, are we right to not worry about 5- and 6-byte
sequences? The docs keep on threatening with it, and then immediately
mention those are not valid.
void popFront3(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1;
if (c < 127)
{
Lend :
s = s.ptr[char_length .. s.length];
} else {
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240) {
char_length = 3;
goto Lend;
}
if (c < 248) {
char_length = 4;
}
goto Lend;
}
}
Andrei
On 10/10/16 9:39 PM, Stefan Koch wrote:
This version has 24 instructions but these have a smaller encoding then
and are generally inexpensive
With inline asm and conditional moves it would be possible to reduce
this even further
to ~20 instructions.
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t char_length = 1;
if (c < 127)
{
goto Lend;
} else {
if ((c & 0b1100_) == 0b1000_)
{
// This is invalid as a first char
goto Lerror;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240) {
char_length = 3;
goto Lend;
}
if (c < 248) {
char_length = 4;
goto Lend;
}
//These characters are also no longer valid
Lerror : assert(0);
}
Lend :
s = s.ptr[char_length .. s.length];
}
Re: color lib
On Tuesday, 11 October 2016 at 00:10:04 UTC, Nicholas Wilson
wrote:
What about forwarding the array ops to a foreach of the static
array?
Like as above but instead of:
ElementType!(R)[N] batch;
have:
static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[];}
Batch opBinary(string op)(Batch rhs)
if(hasOperator!(ElementType!(R),op))
{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]"
~op~"rhs.elements[i]");
return b;
}
//repeat for opUnary,opOpAssign...
}
Batch batch;
I'll make another forum thread for this.
whoops missed an
alias get this;
Re: Can you shrink it further?
This version has 24 instructions but these have a smaller
encoding then and are generally inexpensive
With inline asm and conditional moves it would be possible to
reduce this even further
to ~20 instructions.
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t char_length = 1;
if (c < 127)
{
goto Lend;
} else {
if ((c & 0b1100_) == 0b1000_)
{
// This is invalid as a first char
goto Lerror;
}
if (c < 192)
{
char_length = 2;
goto Lend;
}
if (c < 240) {
char_length = 3;
goto Lend;
}
if (c < 248) {
char_length = 4;
goto Lend;
}
//These characters are also no longer valid
Lerror : assert(0);
}
Lend :
s = s.ptr[char_length .. s.length];
}
Re: Code signing to help with Windows virus false positives
On Saturday, 20 August 2016 at 13:45:11 UTC, Basile B. wrote: "to MSI using innosetup" ? There's a misunderstanding here. Inno setup doesn't compile to MS installer, it's a complete independant solution. 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 like tool, it might not solve all our problems. We're fairly clueless here and could really use help here. Just signing the NSIS installers could work for now, any support for this hypothesis. I tried to submit the latest release as sample to Microsoft but their file upload had a size limit smaller than the binary.
Re: color lib
On Sunday, 9 October 2016 at 13:28:05 UTC, Manu wrote:
On 9 October 2016 at 15:34, Ilya Yaroshenko via Digitalmars-d
wrote:
On Sunday, 9 October 2016 at 05:21:32 UTC, Manu wrote:
On 9 October 2016 at 14:03, Nicholas Wilson via Digitalmars-d
wrote:
[...]
Well the trouble is the lambda that you might give to 'map'
won't work anymore. Operators don't work on batches, you need
to use a completely different API, and I think that's
unfortunate.
Could you please give an example what type of operation should
be vectorized?
Even operations that don't require shuffling, eg:
RGBA8[] a, b;
zip(a, b).map!(e => e[0] + e[1]).copy(output);
Which I've suggested before (and Walter liked the idea), could
be
sugared up by making use of the languages largely under-used
array
operation syntax:
output[] = a[] + b[]; // ie, types have overloaded addition
operators, so this array expression would be lowered to the
pipeline
expression above. This would be super-useful for HEAPS of
things!
Even these still need to be done in batches since colour adds
are saturating operations, and there are SIMD instructions for
saturating arithmetic, so we basically always have to do colour
work in SIMD, which means batching, and that basically ruins
any chance for natural, readable, expressions in your code. I
want to find a way that we can express these operations
naturally, without having to always manually handle the
batching.
If we can get there, then I will say D is a good language for
stream-data processing.
What about forwarding the array ops to a foreach of the static
array?
Like as above but instead of:
ElementType!(R)[N] batch;
have:
static struct Batch
{
ElementType!(R)[N] elements;
auto get() { return elements[];}
Batch opBinary(string op)(Batch rhs)
if(hasOperator!(ElementType!(R),op))
{
Batch b;
foreach(i; iota(N)) mixin("b.elements[i] = elememts[i]"
~op~"rhs.elements[i]");
return b;
}
//repeat for opUnary,opOpAssign...
}
Batch batch;
I'll make another forum thread for this.
Re: color lib
On 10 October 2016 at 23:41, Andrea Fontana via Digitalmars-d
wrote:
> On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
>>
>> On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d
>> wrote:
>>>
>>> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>>>
>>> From doc:
>>> colorFromString Create a color from a string. May be a hex color in the
>>> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
>>> color from the Colors enum.
>>>
>>> It seems it reads just rgb. (+ enum)
>>>
>>> I think that:
>>> colorFromString("red");
>>> colorFromString!"rgb"("#3212ff");
>>> colorFromString!"bgra"("#ff1232dd");
>>>
>>> makes more sense.
>>>
>>> Andrea
>>
>>
>> Why? I see no value in that function being a template... It's not like you
>> can confuse "#FF0080" and "LightGoldenrodYellow". As far as I know, there's
>> no possible ambiguity in colour strings, so why make them separate
>> functions?
>
>
> But it would be useful to create rgb, bgr, argb, bgra, or other color space
> using a string.
Give the preferred format as template arg?
> If a third party library or source gives me code in rgba, I have to
> preprocess it to convert as argb and then pass it to your library.
Sorry, what are we talking about? My lib supports basically every
format or arrangement I've ever encountered... you can work with
practically any data format you can think of.
> Anyway, I don't know if a code with letters a-f can be composed. In that
> case an ambiguity exists.
It must also be exactly 3,4,6,8 letters long, and begin with the
letter '#' or '$' ;)
I'm not sure why it matters what format the colour you have is...
Strings are in the form #RRGGBB, or #AARRGGBB. That is all.
It's the standard I've seen used everywhere ever, including the web,
which is a pretty good precedent :P
If you support swizzled forms of strings, then ambiguity exists.
Better not to allow it.
If you want a BGR from a string, use: colorFromString!BGR8("#FF");
If you want Lab: colorFromString!(Lab!float)("#FF");
Re: Stylish and dlang,org
On Saturday, 8 October 2016 at 08:58:37 UTC, Jakob Ovrum wrote: On Saturday, 8 October 2016 at 08:03:50 UTC, Russel Winder wrote: jmiller did a dark dlang.or Stylish style in 2012. It is now moderately (!) out of date. Anyone know if jmiller is around to update it, or if that is not possible someone who knows Stylish styles to create a new one so that we can view the site in lovely dark mode instead of the awful dark on light. https://gist.github.com/JakobOvrum/e00f97f30bba4b24b6bc How do I enable it? What Chrome extensions are preferred?
Re: New encryption block...
On Monday, 10 October 2016 at 09:54:32 UTC, Era Scarecrow wrote: The largest portion would be that much like a hash, one small change will change the entire thing rather than a smaller portion (with the original blocksize). The multiple re-arranging and encryption steps is to ensure small changes affects every other block it was part of. With CBC block mode, for example, all blocks later in the data stream are changed if one block is changed. Earlier blocks aren't changed because CBC processes data in a single pass (which is an important practical requirement for a lot of applications). If you wanted all the blocks to change, two passes would be enough. Just thinking that if someone makes a database of say the first 4 bytes expected in a file format (like gzip, bzip2, others, etc) then they can map most of the keys and immediately know how to decrypt it (assuming it's of a particular file/stream type). Yep, this is one of the many reasons all secure block modes must use an IV (or equivalent). BTW, if anyone's interested, here's a explanation of a real attack on short block size ciphers that doesn't assume background knowledge: https://blog.cryptographyengineering.com/2016/08/24/attack-of-week-64-bit-ciphers-in-tls/ (The defence is to stop using crypto that was looking bad in the 90s.)
Re: Linker Error: undefined reference to `internal'
I've tracked it down to two lines (which are the same): private SyncLock lock = new SyncLock(); SyncLock is just an empty class which I use to construct objects for use in "synchronized" blocks (not sure if this is the right way to do this). Apparently if I move the initialization to the constructor there are no linker errors.
Re: Linker Error: undefined reference to `internal'
On 10/10/2016 12:23 PM, jython234 wrote: ld fails with this message: Linking... ../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10): undefined reference to `internal' ../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o): (.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18): undefined reference to `internal' I have no idea what this means, and have never seen it before. A symbol remains undefined after all input files, including libraries, had been processed. Common causes for this are: A function was called in your code, but the function was never written. A virtual function was declared, but never written. A data variable was referenced, but never defined anywhere. Did not specify all the .obj files to the linker. The calling conventions of the function being referenced do not match the calling conventions of the defined function. Compiler switches, memory models, and special keywords can all affect calling convention (and thereby the name of the symbol as it appears in the .obj file). One or more missing library files (.lib). One way to figure out which .lib file contains the missing symbol is to run: \dm\bin\grep symbolname \dm\lib\*.* The LIB environment variable is missing or not pointing to the \dm\lib directory or wherever the .lib files reside.
Linker Error: undefined reference to `internal'
I posted this on stackoverflow, but it doesn't seem like anyone knows what is going on: I'm writing an application in D which interfaces with OpenGL and a few other native libraries (using the Derelict libraries). However, this error does not seem to relate to that at all. Whenever I do "dub build" the compilation succeeds, but ld fails with this message: Linking... ../git/mango-engine/bin/libmango-engine.a(gl_model_503_284.o):(.data._D12mango_engine8graphics6opengl8gl_model7GLModel6__initZ+0x10): undefined reference to `internal' ../git/mango-engine/bin/libmango-engine.a(shader_51b_52f.o): (.data._D12mango_engine8graphics6shader13ShaderProgram6__initZ+0x18): undefined reference to `internal' collect2: error: ld returned 1 exit status I have no idea what this means, and have never seen it before. Also, strangely this error only occurs when I import the specific files: gl_model.d and shader.d, from another DUB project. If they are not imported the linker succeeds. I'm not sure what information to provide, so I will just link the whole source code: https://github.com/jython234/mango-engine
Re: Required DMD changes for Mir and few thoughts about D future
On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu wrote: On 10/8/16 2:49 PM, Andrei Alexandrescu wrote: On 10/8/16 1:22 PM, Martin Nowak wrote: Integrating this with a pre-compiled ldc library is a fantastic idea OTOH. If we can make this work, it will be much less effort and yield the fastest implementation. Also would speed up the development cycle a bit b/c the kernels don't need to be recompiled/optimized. You mean dmd/ldc/etc interop at binary level? Yes, that would be pretty rad indeed! -- Andrei (after thinking a bit more) ... but Mir seems to rely in good part on templates, which makes pre-compiled libraries less effective. -- Andrei Independent from Mir, a stable ABI for D which all compilers follow would be a tremendous win, especially from the perspective of shipping D stuff in Linux distributions. So maybe this is worth attempting?
Re: Can you shrink it further?
On Monday, 10 October 2016 at 15:17:05 UTC, Stefan Koch wrote:
On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu
wrote:
Oh, forgot to mention: the initial/short path should only
check for ASCII, i.e. c < 0x80. -- Andrei
Since in this case stability of min is concern, you can shave of
another 2 instructions by writing the comparison by hand
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t char_length = 1;
if (!(c & 0x80)) {
goto Lend;
} else {
import core.bitop;
uint i = 7u - bsr(~c | 1u);
import std.algorithm;
if (i > 6u) goto Lend;
char_length = i < s.length ? i : s.length;
}
Lend :
s = s.ptr[char_length .. s.length];
}
Re: Can you shrink it further?
On Monday, 10 October 2016 at 15:37:09 UTC, Stefan Koch wrote: Since in this case stability of min is concern, you can shave of another 2 instructions by writing the comparison by hand In this case the stability of min is +NO+ concern.
Re: Can you shrink it further?
On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu
wrote:
Oh, forgot to mention: the initial/short path should only check
for ASCII, i.e. c < 0x80. -- Andrei
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t char_length = 1;
if (!(c & 0x80)) {
goto Lend;
} else {
import core.bitop;
uint i = 7u - bsr(~c | 1u);
import std.algorithm;
if (i > 6u) goto Lend;
char_length = min(i, s.length);
}
Lend :
s = s.ptr[char_length .. s.length];
}
This one removes one unnecessary ret.
It will also probably be better for the branch-predictor.
Re: Supporting musl libc
Dne 10.10.2016 v 15:27 openwrt via Digitalmars-d napsal(a): On Sunday, 9 October 2016 at 15:48:49 UTC, Daniel Kozak wrote: On Sunday, 9 October 2016 at 13:38:33 UTC, Jacob Carlborg wrote: On 2016-10-08 20:47, Daniel Kozak wrote: What is the current status? Without support of musl-libc, I can not ad support for a Alpine linux distribution. It is a shame because they already have go and rust support. I've not worked at this at all. For my use case it was easier to just build in Docker instead. I solved this by using libexecinfo library from freebsd openwrt also use musl, and I can not run my d code on it(unless I rebuild everythings with glic). Yes, even libexecinfo does not fixed all issues, we really need to add other C runtimes. In D runtime and phobos there is a lot of places which wrongly use version(linux) instead of CRuntime_Glibc.
Re: color lib
On Monday, 10 October 2016 at 13:25:07 UTC, Manu wrote:
On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d
wrote:
On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
From doc:
colorFromString Create a color from a string. May be a hex
color in the
standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the
name of any
color from the Colors enum.
It seems it reads just rgb. (+ enum)
I think that:
colorFromString("red");
colorFromString!"rgb"("#3212ff");
colorFromString!"bgra"("#ff1232dd");
makes more sense.
Andrea
Why? I see no value in that function being a template... It's
not like you can confuse "#FF0080" and "LightGoldenrodYellow".
As far as I know, there's no possible ambiguity in colour
strings, so why make them separate functions?
But it would be useful to create rgb, bgr, argb, bgra, or other
color space using a string.
If a third party library or source gives me code in rgba, I have
to preprocess it to convert as argb and then pass it to your
library.
Anyway, I don't know if a code with letters a-f can be composed.
In that case an ambiguity exists.
Re: Supporting musl libc
On Sunday, 9 October 2016 at 15:48:49 UTC, Daniel Kozak wrote: On Sunday, 9 October 2016 at 13:38:33 UTC, Jacob Carlborg wrote: On 2016-10-08 20:47, Daniel Kozak wrote: What is the current status? Without support of musl-libc, I can not ad support for a Alpine linux distribution. It is a shame because they already have go and rust support. I've not worked at this at all. For my use case it was easier to just build in Docker instead. I solved this by using libexecinfo library from freebsd openwrt also use musl, and I can not run my d code on it(unless I rebuild everythings with glic).
Re: color lib
On 10 October 2016 at 23:00, Andrea Fontana via Digitalmars-d
wrote:
> On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
>
> From doc:
> colorFromString Create a color from a string. May be a hex color in the
> standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be the name of any
> color from the Colors enum.
>
> It seems it reads just rgb. (+ enum)
>
> I think that:
> colorFromString("red");
> colorFromString!"rgb"("#3212ff");
> colorFromString!"bgra"("#ff1232dd");
>
> makes more sense.
>
> Andrea
Why? I see no value in that function being a template... It's not like
you can confuse "#FF0080" and "LightGoldenrodYellow". As far as I
know, there's no possible ambiguity in colour strings, so why make
them separate functions?
Re: color lib
On Monday, 10 October 2016 at 08:44:49 UTC, Manu wrote:
On 10 October 2016 at 17:29, Andrea Fontana via Digitalmars-d
wrote:
On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote:
I've done another pass incorporating prior feedback, mostly
focusing on documentation.
http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html
Can interested parties please give it another once-over and
add
further comments?
How can I get this to a point where people would like to see
it in phobos?
Repo: https://github.com/TurkeyMan/color
PR: https://github.com/dlang/phobos/pull/2845
Nice work!
colorFromString should be colorFromRGBString :)
Nar. It parses any form of colour-in-a-string.
From doc:
colorFromString Create a color from a string. May be a hex color
in the standard forms: (#/$)rgb/argb/rrggbb/aarrggbb May also be
the name of any color from the Colors enum.
It seems it reads just rgb. (+ enum)
I think that:
colorFromString("red");
colorFromString!"rgb"("#3212ff");
colorFromString!"bgra"("#ff1232dd");
makes more sense.
Andrea
Re: color lib
On Monday, 10 October 2016 at 12:10:56 UTC, Jacob Carlborg wrote: Isn't std.typecons.Flag metaprogramming ;) Hahaha, oh wow. If ever there was a case for mixins.
Re: color lib
On 2016-10-10 12:39, Ethan Watson wrote: I'm especially trying to make Binderoo readable as there's so many programmers that are scared by metaprogramming. Isn't std.typecons.Flag metaprogramming ;) -- /Jacob Carlborg
Re: Using gethostbyname_r instead of gethostbyname in std.socket
On Saturday, 8 October 2016 at 13:46:28 UTC, Jakob Ovrum wrote:
...
The doc for InternetAddress does say it uses InternetHost
internally, and the docs do recommend getAddress over using
Internet{Host, Address} directly,
I have no idea why we don't use std.socket.getAddress; I'll look
into that. If switching over is viable (which I imagine it is)
and sufficient, then that sounds like a great solution short term.
but maybe InternetHost.getHostByName should use getAddress
internally to benefit from getaddrinfo.
Sounds good :) I can't comment on what wider impact that might
have though.
If not, it should probably at least warn about not being
reentrant.
It is "kind of" reentrant - it has synchronisation around the
gethostbyname call. Things fall apart when gethostbyname is
accessed directly, e.g. by a third party library, as is the case
in our application.
Re: color lib
On Saturday, 8 October 2016 at 13:06:42 UTC, Manu wrote: Oh no, you too? >_< Yeah, I've been going on a readability bender lately, especially in public facing code. My thinking there is that statements in code that don't immediately give context are essentially a cipher. Because that's exactly what you need to do to understand the code - look something up to see what it means. Named parameters and variable names that provide the context avoid that to a large degree. I'm especially trying to make Binderoo readable as there's so many programmers that are scared by metaprogramming. My GDCE talk spent a lot of time attempting to make it all understandable. Making the code descriptive seals the deal. If I can make my code more descriptive, and it compiles out just the same but makes the compiler do a bit more work... Make the compiler do more work and optimise the compiler. I'm far more lax on not-publicly-facing code (so basically API implementations and supporting code that isn't part of a public interface). Anything I expect someone other than myself to interact with gets the readability treatment. Which, as you know, is important because readable code generally isn't efficient code - as is evidenced by the vectorisation/buffer processing thread going on in here. It's also interesting how many programmers get vehemently defensive when you call out non-descriptive programming practices as programming for your own convenience and no one else. I have this argument with using i/j/k/foo/bar/etc in loops as well. Incidentally, have you had a geez over the core API? An efficient API will emerge when we work out how to work batched operations into ranges... Been slowly making my way through it. Seems solid enough, but I haven't looked through it all thoroughly yet.
Re: Add "Go To Source" for Docs?
On Sunday, 9 October 2016 at 06:50:00 UTC, Sönke Ludwig wrote: Am 08.10.2016 um 23:49 schrieb Jacob: Well a lot of the times I'm browsing the phobos library documentation I want to go to the source code, but there's no easy way to go there directly from the docs. Some modules have a link to the source file but I think that's done manually as many of them don't. I think it'd be beneficial to have a way to tell the doc generator to include a "go to source" button at each doc entry of function/type. With the option to set a github repo or other link as the destination of the link, it should also include the line number when outputting the docs. Might be a bit specific for github there though, as setting the line number just involves adding a number to the end of the link. Whereas being able to set a local file as a link might be desired as well. But I don't think you can tell the OS to open the file at a certain line with just a file uri. The documentation under http://dlang.org/library/ has such a link at the top of each page. See for example http://dlang.org/library/std/algorithm/comparison/either.html Is that generated using something else? Adding a similar feature to the other docs would do it then. Right now they lack any sort of link to source. http://dlang.org/phobos/std_range.html#zip For example, has no links anywhere to the source code except for the one link at the top, and that's just to the module. It doesn't specify the line that the function is defined at.
Re: New encryption block...
On Monday, 10 October 2016 at 03:15:07 UTC, sarn wrote: End users won't want to permute+encrypt multiple times unless you can show there's a benefit in the speed/security tradeoff, so you'll need to think about that in the design. The largest portion would be that much like a hash, one small change will change the entire thing rather than a smaller portion (with the original blocksize). The multiple re-arranging and encryption steps is to ensure small changes affects every other block it was part of. Just thinking that if someone makes a database of say the first 4 bytes expected in a file format (like gzip, bzip2, others, etc) then they can map most of the keys and immediately know how to decrypt it (assuming it's of a particular file/stream type). The larger block size also allows for multiple keys so you could push past far past the limitations of a single block cipher. As for a specific example, not really. Something fairly small, so personal documents and the like or archives, unlike say multi-media where it doesn't contain any personal data (probably). The only other idea is another multi-step process used for when generating hashes/keys or the like which is to slow down or make it annoyingly difficult to brute force passwords from a hashfile. Alternatively with the salting having it for encrypted communication would help hide sentences/replies where you reply the same thing over and over again. Y>Do you have the stuff? M>Yes Y>Did you stash it in the place? M>Yes Y>Do you like Lasagna? M>Yes or something like that :P Oh well. My question was mostly an idea, having something to look over for block ciphers will be an interesting read (when I get to it)
Re: color lib
On 10 October 2016 at 17:29, Andrea Fontana via Digitalmars-d wrote: > On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote: >> >> I've done another pass incorporating prior feedback, mostly focusing on >> documentation. >> >> >> http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html >> >> Can interested parties please give it another once-over and add >> further comments? >> How can I get this to a point where people would like to see it in phobos? >> >> Repo: https://github.com/TurkeyMan/color >> PR: https://github.com/dlang/phobos/pull/2845 > > > Nice work! > > colorFromString should be colorFromRGBString :) Nar. It parses any form of colour-in-a-string.
Re: color lib
On Thursday, 6 October 2016 at 14:53:52 UTC, Manu wrote: I've done another pass incorporating prior feedback, mostly focusing on documentation. http://dtest.thecybershadow.net/artifact/website-b6e2e44dd40dd7c70eb45829c02060b99ae3937b-57272ccdf902fa3f0c050d522129f2be/web/library-prerelease/std/experimental/color.html Can interested parties please give it another once-over and add further comments? How can I get this to a point where people would like to see it in phobos? Repo: https://github.com/TurkeyMan/color PR: https://github.com/dlang/phobos/pull/2845 Nice work! colorFromString should be colorFromRGBString :)
Re: Required DMD changes for Mir and few thoughts about D future
On 10/10/16 2:05 AM, Martin Nowak wrote: On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu wrote: (after thinking a bit more) ... but Mir seems to rely in good part on templates, which makes pre-compiled libraries less effective. -- Andrei On Saturday, 8 October 2016 at 18:53:32 UTC, Andrei Alexandrescu wrote: Ilya's answer http://forum.dlang.org/post/rexuwvohqceaglcbr...@forum.dlang.org Sounds like a feasible approach for phobos inclusion w/ prolly very little usability restrictions on the generic API wrapping those. Yes, after talking to him this seems definitely a worthwhile pursuit. -- Andrei
