Re: Is it possible to have reproducible-builds?
On Thursday, 26 October 2017 at 04:34:36 UTC, Ky-Anh Huynh wrote: Hi, I'd like to distribute binaries (compiled from Dlang sources) to my servers and users. This really helps end users because they don't need to rebuild things with custom dmd/dub setup. However, distributing things require them to `trust` me, and this is another thing I want to avoid. Is it possible to have reproducible-builds with (any) dlang compiler? and how? See also https://wiki.debian.org/ReproducibleBuilds Thanks a lot for your reading. See also the old topic: http://forum.dlang.org/thread/fsmdaethvbvcxnunb...@forum.dlang.org
Is it possible to have reproducible-builds?
Hi, I'd like to distribute binaries (compiled from Dlang sources) to my servers and users. This really helps end users because they don't need to rebuild things with custom dmd/dub setup. However, distributing things require them to `trust` me, and this is another thing I want to avoid. Is it possible to have reproducible-builds with (any) dlang compiler? and how? See also https://wiki.debian.org/ReproducibleBuilds Thanks a lot for your reading.
Re: Getting a safe path for a temporary file
On Sunday, 18 January 2015 at 00:51:37 UTC, Laeeth Isharc wrote: On Saturday, 17 January 2015 at 16:55:42 UTC, Marc Schütz wrote: On Saturday, 17 January 2015 at 14:37:00 UTC, Laeeth Isharc wrote: On Saturday, 17 January 2015 at 13:47:39 UTC, Marc Schütz wrote: [...] I agree that it would be useful. This is what I used, although there may be a better option: http://dlang.org/phobos/std_uuid.html Nice idea, but it still allows for intentional collision attacks :-( The only really safe solution is one that generates (probably) unique names, then opens the file with O_EXCL|O_CREAT (or whatever other means the OS provides), and if it fails, retries with a different name. `std.stdio.tmpfile()` already does that (it uses `tmpfile(3)` under the hood), but doesn't allow access to the name. I don't follow why a collision attack is applicable in this case. Your stage 1 of generating unique names: how is this different from using a random uuid? UUIDs are defined to be unique, not unpredictable. UUID that use random number generation (UUID4) should use a cryptographically secure random number generator but are not required to. Therefore it shouldn't be blindly trusted against someone actively trying to get a collision.
Re: Getting a safe path for a temporary file
On Sunday, 18 January 2015 at 16:00:32 UTC, Kagamin wrote: On Sunday, 18 January 2015 at 11:21:52 UTC, Marc Schütz wrote: It's not different, and if you're still doing the O_EXCL open afterwards, it's safe. I just assumed you were going to use the generated filename without a further check. This is then unsafe, no matter how the UUID is generated, and depending on the RNG that's been used, they can be quite predictable. Granted, the risk is low, but still... tmpfile is more predictable: it generates sequential file names. Being predictable is only an issue if the file is wrongly used (ie: no check that it might already exist, or be a symlink or check at the wrong time leaving an exploitable time frame etc). Sequential file names are a good way to provide uniqueness over a single system after all.
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 20:04:47 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 October 2017 at 19:50:31 UTC, SrMordred wrote:
so why this line resolves to false?
Because it is illegal to put a statement or declaration inside
__traits(compiles). sorry, I should have said that before...
even though the mixin can be legal in another context, it won't
be in the __traits context due to this:
https://dlang.org/spec/traits.html#compiles
"Returns a bool true if all of the arguments compile (are
semantically correct). The arguments can be symbols, types, or
expressions that are syntactically correct. The arguments
cannot be statements or declarations. "
When there's a closing ;, it is a mixin statement.
void F(){}
pragma(msg, __traits( compiles, mixin("F();") ) );//false
Oh, now thats explains. I thought that a "mixin statement" was
equal to the argument type that it compiles to. Thanks!
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 19:50:31 UTC, SrMordred wrote:
so why this line resolves to false?
Because it is illegal to put a statement or declaration inside
__traits(compiles). sorry, I should have said that before... even
though the mixin can be legal in another context, it won't be in
the __traits context due to this:
https://dlang.org/spec/traits.html#compiles
"Returns a bool true if all of the arguments compile (are
semantically correct). The arguments can be symbols, types, or
expressions that are syntactically correct. The arguments cannot
be statements or declarations. "
When there's a closing ;, it is a mixin statement.
void F(){}
pragma(msg, __traits( compiles, mixin("F();") ) );//false
Re: __traits(compiles , mixin ... )
The semicolon there indicates it is a complete statement that
does nothing, and that's no error.
so why this line resolves to false?
void F(){}
pragma(msg, __traits( compiles, mixin("F();") ) );//false
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 19:25:01 UTC, Adam D. Ruppe
wrote:
On Wednesday, 25 October 2017 at 19:12:02 UTC, SrMordred wrote:
Maybe i´m tired already, but whats wrong here:
pragma(msg, __traits( compiles, mixin("int x") ) );
You are missing a ;
The mixin must compile as a full thing in context. Variable
declarations need the ; to be complete.
it returns false anyway.
void F(){
writeln("inside");
}
struct T{}
void main()
{
pragma(msg, __traits( compiles, mixin("int x;") )
);//false
pragma(msg, __traits( compiles, mixin("F();") ) );//false
pragma(msg, __traits( compiles, mixin("F()") ) );//true
mixin( "F();" ); //compiles
pragma(msg, __traits( compiles, mixin("T();") ) ); //false
pragma(msg, __traits( compiles, mixin("T()") ) ); // true
mixin( "T();" ); // Error: `structliteral` has no effect in
expression `T()`
}
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 19:21:27 UTC, SrMordred wrote: mixin( "T();" ); Error: `structliteral` has no effect in expression `T()` The semicolon there indicates it is a complete statement that does nothing, and that's no error. If there's no ;, it is just an expression that must be somewhere else - and the compile error is deferred until higher in the call chain.
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 19:12:02 UTC, SrMordred wrote:
Maybe i´m tired already, but whats wrong here:
pragma(msg, __traits( compiles, mixin("int x") ) );
//output: false
Or the original case I found:
struct T{}
pragma(msg, __traits( compiles, T() ) ); //true
pragma(msg, __traits( compiles, mixin("T()") ) ); //true
mixin( "T();" ); Error: `structliteral` has no effect in
expression `T()`
Re: __traits(compiles , mixin ... )
On Wednesday, 25 October 2017 at 19:12:02 UTC, SrMordred wrote:
Maybe i´m tired already, but whats wrong here:
pragma(msg, __traits( compiles, mixin("int x") ) );
You are missing a ;
The mixin must compile as a full thing in context. Variable
declarations need the ; to be complete.
__traits(compiles , mixin ... )
Maybe i´m tired already, but whats wrong here:
pragma(msg, __traits( compiles, mixin("int x") ) );
//output: false
Re: call Pascal DLL functions from D
On Wednesday, 25 October 2017 at 10:47:56 UTC, Oleg B wrote: On Wednesday, 25 October 2017 at 04:30:12 UTC, Basile B. wrote: If I wrote `array[5..7] of ...` I get array that can be indexed by `5`, `6` and `7`, right? It means that array have 3 elements. If A=5, B=7 then length of array is B-A+1, 7-5+1=3. In my case I have [1..49] and [2..50] ranges: 49-1+1=49, 50-2+1=49. I don't understand why length must be 48... Yeah of course, me neither.
Re: call Pascal DLL functions from D
On Wednesday, 25 October 2017 at 03:36:54 UTC, Adam D. Ruppe wrote: I'd suggest just trying it and seeing if the functions return what you expect. Unfortunately they returns unexpected codes. Otherwise I wouldn't post question here. I go here then I have no idea to resolve problem.
Re: call Pascal DLL functions from D
On Wednesday, 25 October 2017 at 04:30:12 UTC, Basile B. wrote: On Wednesday, 25 October 2017 at 03:12:56 UTC, Oleg B wrote: 2. `array[A..B] of TFoo` is `TFoo[B-A+1]` (static array) No A-B. In Pascal the upper bound of a range (like here but i'm not sure this i called like that in the grammar) or of a slice is inclusive. alias HarmonicArray = OneHarmonic[49]; 48 ! Most likely the problem is the array length. If I wrote `array[5..7] of ...` I get array that can be indexed by `5`, `6` and `7`, right? It means that array have 3 elements. If A=5, B=7 then length of array is B-A+1, 7-5+1=3. In my case I have [1..49] and [2..50] ranges: 49-1+1=49, 50-2+1=49. I don't understand why length must be 48... In any case I tried 48 and CheckSignalData function returns other error code, but it point to current field too (incorrect value of coefs - it can be if floating point value is badly read).
Re: writeln double precision
On Tuesday, October 24, 2017 16:59:31 Arun Chandrasekaran via Digitalmars-d- learn wrote: > On Tuesday, 24 October 2017 at 16:18:03 UTC, H. S. Teoh wrote: > > On Tue, Oct 24, 2017 at 10:02:11AM +, Arun Chandrasekaran > > > > via Digitalmars-d-learn wrote: > >> On Monday, 23 October 2017 at 18:08:43 UTC, Ali Çehreli wrote: > >> > On 10/23/2017 07:22 AM, Arun Chandrasekaran wrote: > >> > > [...] > >> > > >> > The rule is that every expression has a type and 22/7 is int. > >> > >> Thanks Ali. Is this for backward compatibility with C? > >> Because, if there is a division, a natural/mathematical (not > >> programmatic) expectation is to see a a double in the result. > > > > [...] > > > > I have never seen a programming language in which dividing two > > integers yields a float or double. Either numbers default to a > > floating point type, in which case you begin with floats in the > > first place, or division is integer division, yielding an > > integer result. > > > > > > T > > I'm not denying that all the programming languages does it this > way (even if it is a cause of related bugs). > I'm just questioning the reasoning behind why D does it this way > and if it is for compatibility or if there is any other reasoning > behind the decision. Part of it is compatibility. In general, valid C code should either be valid D code with the same semantics, or it shouldn't compile. We haven't done a perfect job with that, but we're close. And dividing two integers resulting in a floating point value doesn't fit with that at all. But regardless of that, there's the question of whether it's even desirable, and in a language that's geared towards performance, it really isn't. Also, many us don't want floating point values creeping into our code anywhere without us being explicit about it. Floating point math is not precise in the way that integer math is, and IMHO it's best to be avoided if it's not needed. Personally, I avoid using floating point types as much as possible and only use them when I definitely need them. If they acted like actual math, that would be one thing, but they don't, because they live in a computer, and D's built-in numerical types are closely modeled after what's in the hardware. Obviously, floating point types can be quite useful, and we want them to work properly, but having stuff automatically convert to floating point types on you without being asked would be a serious problem. And in general, D is far more strict about implicit conversions than C/C++ is, not less. So, it would be really out of character for it to do floating point division with two integers. - Jonathan M Davis
Re: call Pascal DLL functions from D
On Wednesday, 25 October 2017 at 03:12:56 UTC, Oleg B wrote: Hello. I have DLL written on Pascal and "headers" for use it (types and functions signatures definitions). How I can port "headers" to D? [...] Hi, this thread might be interesting for you, if you use Delphi http://forum.dlang.org/post/hpodoabutuakfxbzz...@forum.dlang.org This thread describes a bridge between the D Programming Language and Delphi. Kind regards André
