Re: Beta 2.084.1

2019-02-05 Thread Andre Pany via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 04:18:55 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.084.1 point release, 
♥ to the 6 contributors.


http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.084.1.html


As usual please report any bugs at
https://issues.dlang.org

-Martin


This beta again has this issue:
lld-link.exe: error: could not open msvcrt100.lib: no such file 
or directory
lld-link.exe: error: could not open OLDNAMES.lib: no such file or 
directory


(It is caused if you have a visual studio / build tools 
installation, then

lld gets confused).

It was already solved in the nightly build, I downloaded some 
days ago.


Kind regards
André


Re: Issues Donating or Registering for DConf via Flipcause

2019-02-05 Thread Martin Tschierschke via Digitalmars-d-announce

On Tuesday, 29 January 2019 at 02:29:08 UTC, Mike Parker wrote:
Flipcause released a major upgrade to their platform last week 
that unified several different components (donations, events, 
online stores, etc) into a single system they call Universal 
Checkout.


[...]



No chance... I updated my Master Card with the Secure Code thing, 
but the same result again.

I tried again 2 times: only result

=> Your session has expired.

Flipcause has been a better usage experience before. Sure I can 
give my 25 bucks via Paypal, but this is not the idea behind, 
isn't it?




Re: Issues Donating or Registering for DConf via Flipcause

2019-02-05 Thread Mike Parker via Digitalmars-d-announce
On Tuesday, 5 February 2019 at 11:17:01 UTC, Martin Tschierschke 
wrote:




Flipcause has been a better usage experience before. Sure I can 
give my 25 bucks via Paypal, but this is not the idea behind, 
isn't it?


Go ahead and go through PayPal if Flipcause doesn't work for you. 
They're working on the issues right now. They've credited our 
account with some money and have been running tests on our 
account and others. They'll work it out eventually, I'm sure.


a van Emde Boas tree

2019-02-05 Thread Alex via Digitalmars-d-announce

Hi all,
my van Emde Boas tree finally reached an announceable state, at 
version 0.12.0.


It operates on a closed universe, defined on construction.

After that, the tree operates on unique key up to a certain 
capacity, which is at least as large as the universe size.


All operations including insertion, removing, look up and next 
neighbor search are O(log(log(U)). min and max lookup are O(1).


Some graphics are included on the front page for performance 
comparison with existent libraries.


I relicensed the package to BSL-1.0 and moved it on github, so 
the documentation should work properly now.


All tickets are welcome of course and will be managed in my spare 
time.


Re: a van Emde Boas tree

2019-02-05 Thread Craig Dillabaugh via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote:

Hi all,
my van Emde Boas tree finally reached an announceable state, at 
version 0.12.0.



clip


All tickets are welcome of course and will be managed in my 
spare time.


Link?


Re: a van Emde Boas tree

2019-02-05 Thread Dejan Lekic via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote:

Hi all,
my van Emde Boas tree finally reached an announceable state, at 
version 0.12.0.


vEB tree is an interesting data structure. Where is the 
implementation? - You did not provide any links...


Re: a van Emde Boas tree

2019-02-05 Thread Petar via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 15:47:30 UTC, Dejan Lekic wrote:

On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote:

Hi all,
my van Emde Boas tree finally reached an announceable state, 
at version 0.12.0.


vEB tree is an interesting data structure. Where is the 
implementation? - You did not provide any links...


Most likely the repo is this one: 
https://github.com/Sandman83/vebtree


Re: a van Emde Boas tree

2019-02-05 Thread Martin Drašar via Digitalmars-d-announce
Dne 5.2.2019 v 16:47 Dejan Lekic via Digitalmars-d-announce napsal(a):
> On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote:
>> Hi all,
>> my van Emde Boas tree finally reached an announceable state, at
>> version 0.12.0.
> 
> vEB tree is an interesting data structure. Where is the implementation?
> - You did not provide any links...

I guess it is: https://code.dlang.org/packages/vebtree


Re: a van Emde Boas tree

2019-02-05 Thread Alex via Digitalmars-d-announce
On Tuesday, 5 February 2019 at 16:04:03 UTC, Petar Kirov 
[ZombineDev] wrote:

On Tuesday, 5 February 2019 at 15:47:30 UTC, Dejan Lekic wrote:

On Tuesday, 5 February 2019 at 15:28:04 UTC, Alex wrote:

Hi all,
my van Emde Boas tree finally reached an announceable state, 
at version 0.12.0.


vEB tree is an interesting data structure. Where is the 
implementation? - You did not provide any links...


Most likely the repo is this one: 
https://github.com/Sandman83/vebtree


Yes... sorry. Too deep in the code...
https://code.dlang.org/packages/vebtree


Re: Beta 2.084.1

2019-02-05 Thread Johan Engelen via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 04:18:55 UTC, Martin Nowak wrote:

Glad to announce the first beta for the 2.084.1 point release,


Any chance of getting this in?
https://github.com/dlang/phobos/pull/6814

Phobos std.file has become unusable after 2.082 because of [1] 
leading to memory corruption. It's pretty bad: dmd 2.082 and 
2.083, and LDC 1.12 and 1.13 cannot be used for serious work 
(unless you prevent people from using std.file by deleting it?).


Cheers,
  Johan

[1] the trigger of the bug: 
https://github.com/dlang/phobos/pull/6584


Gillespie algorithm

2019-02-05 Thread Alex via Digitalmars-d-announce
Doing some physical simulations I could abstract the Gillespie 
algorithm, see


https://code.dlang.org/packages/gillespied

which may be useful.

The number of algorithms able to model physical (continuous) time 
during an ongoing (reaction) process is rather limited. The 
announced algorithm is known to provide this feature. There are 
very much manifestations and improvements of the original 
Gillespie. In general, the improvements try to improve the speed 
of the algorithm either via

- faster timing generation
- faster next reaction look up
- approximating the output by assumptions

Compared to the standard Gillespie algorithm two enhancements 
were implemented:
- for the case, reaction propensities are known, interarrival 
timings do not necessarily depend on a random number and its 
logarithm. This makes each time query faster.
- If the governing simulation can handle non-nogc algorithm 
instantiation, a dedicated working array can be handled inside 
the algorithm. This provides faster next reaction search for all 
operations.


All issues are of course welcome and will be tackled in my spare 
time. I hope, for this library, many further improvements, and 
applications could be found in future.


intel-intrinsics v1.0.0

2019-02-05 Thread Guillaume Piolat via Digitalmars-d-announce
"intel-intrinsics" is a DUB package for people interested in x86 
performance that want neither to write assembly, nor a 
LDC-specific snippet... and still have fastest possible code.


Available through DUB: 
http://code.dlang.org/packages/intel-intrinsics



*** Features of v1.1.0:

- All intrinsics in this list: 
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=MMX,SSE,SSE2 Use existing Intel documentation and syntax


- write the same code for both DMD and LDC, in the last 6 
versions for each. (Note that debug performance might suffer a 
lot when no inlining is activated.)


- Use operators on SIMD vectors as if core.simd were implemented 
on DMD 32-bit


- Introduces int2 and float2 because short SIMD vectors are useful

- about 6000 LOC (for now! more to come)

- Bonus: approximated pow/exp/log. Perform 4 approximated pow at 
once.




The long-term goal for this library is to be _only about 
semantics_, and not particularly codegen(!). This is because LLVM 
IR is portable, so forcing a particular instruction is undoing 
this portability work. **This can seem odd** for an "intrinsics" 
library but this way exact codegen options can be choosen by the 
library user, and most intrinsics can gracefuly degrade to 
portable IR in theory.


In the future, "magic" LLVM intrinsics will only be used when 
built for x86, but I think all of it can become portable and not 
x86-specific. Besides, there is a trend in LLVM to remove magic 
intrinsics once they are doable with IR only.




tl;dr you can use "intel-intrinsics" today, and get quite-optimal 
code with LDC, without duplication. You may come across early 
bugs too.

http://code.dlang.org/packages/intel-intrinsics

(note: it's important to bench against vanilla D code or arrays 
ops too, in some case the vanilla code wins)


Re: Beta 2.084.1

2019-02-05 Thread Seb via Digitalmars-d-announce

On Tuesday, 5 February 2019 at 17:41:50 UTC, Johan Engelen wrote:

On Tuesday, 5 February 2019 at 04:18:55 UTC, Martin Nowak wrote:

Glad to announce the first beta for the 2.084.1 point release,


Any chance of getting this in?
https://github.com/dlang/phobos/pull/6814


-> https://github.com/dlang/phobos/pull/6855


Re: intel-intrinsics v1.0.0

2019-02-05 Thread Simen Kjærås via Digitalmars-d-announce
On Wednesday, 6 February 2019 at 01:05:29 UTC, Guillaume Piolat 
wrote:
"intel-intrinsics" is a DUB package for people interested in 
x86 performance that want neither to write assembly, nor a 
LDC-specific snippet... and still have fastest possible code.


Neat. Question: On Github it's stated that implicit conversions 
aren't supported, with this example:


__m128i b = _mm_set1_epi32(42);
__m128 a = b; // NO, only works in LDC

Couldn't this be solved through something like this:

struct __m128 {
float4 value;
alias value this;
void opAssign(__m128i rhs) {
value = cast(float4)rhs.value;
}
}

--
  Simen