Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 23:04:46 UTC, James Japherson
wrote:
The whole point is not to use $ as an identifier but to specify
to the compiler of that it can rewrite it.
It's called 'alias'.
// compile time
int foo(alias index)(int[] a)
{
return a[index(a.length)];
}
// run time
int barr(int[] a, size_t function(size_t) index)
{
return a[index(a.length)];
}
int main()
{
import std.range: iota;
import std.array: array;
import std.stdio: writeln;
int[100] a = iota(0,100).array;
a.foo!(l => l-3).writeln;
a.barr(l => l-3).writeln;
return 0;
}
Re: Farewell (of sorts)
Good luck! On 10/04/2018 06:15 AM, Shachar Shemesh wrote: > D will no longer be my day job. After a one year distraction with Go, I'm back to C++ myself. I've just finished my first reading of Scott Meyers' "Effective Modern C++" Oh boy! :) I'm reminded one more time that C++ is very hard to use correctly without reading several books like his. > Eyal Lotem Yay! :) Ali
Re: A Friendly Challenge for D
On 10/10/2018 07:52 PM, Jabari Zakiyth wrote: > On Wednesday, 10 October 2018 at 22:25:17 UTC, Neia Neutuladh wrote: >> On 10/10/2018 03:05 PM, Jabari Zakiya wrote: >>> https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ >> >> It would be great if you could provide a link to a freely downloadable >> version of this. > > You can download the paper for free from that link. Did you have trouble > doing it? I think the problem is, scribd requires an account, which they apparently happy to link to an existing Google or Facebook account. > Here's another link to paper. > > https://www.academia.edu/7583194/The_Segmented_Sieve_of_Zakiya_SSoZ_ Similarly, that one requires a Google account. > Here, again, is the link to the Nim code. Just install Nim (current > 0.19.0) and compile and run it per instructions in code. I recommend > people do that to see its outputs and verify its results. > > https://gist.github.com/jzakiya/6c7e1868bd749a6b1add62e3e3b2341e That works! :) Ali
Re: A Friendly Challenge for D
On Thursday, 11 October 2018 at 00:22:10 UTC, tide wrote: On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. If you want help with your paper, possibly some kind of decent financial incentive would be appropriate. If the algorithm benefits from more threads than finding or creating an implementation that runs on a GPU would probably be the true performance test. CPUs have like 4-8 cores in the mainstream? A GPU has hundreds, though with some limitations. I'm writing the paper anyway (just like the others), so other implementations are icing on the cake to show implementation variations, as a benefit to readers. Maybe if I set up a website and created a Rosetta Code repo for people to post their different language implementations, and offer a T-shirt for fastest implementation. :-) Yes, a GPU based implementation would be the epitome for this algorithm, by far. This is actually why I have gotten the algorithm to this implementation so that the number crunching can all be done in parallel threads. (It would also be screamingly fast done in hardware in a FPGA too.) However, I only have standard consumer grade laptops. Hopefully someone(s) with sufficient hardware, interest, and time, will take this upon themselves to do this and publicize their results.
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 22:25:17 UTC, Neia Neutuladh wrote: On 10/10/2018 03:05 PM, Jabari Zakiya wrote: https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ It would be great if you could provide a link to a freely downloadable version of this. You can download the paper for free from that link. Did you have trouble doing it? Here's another link to paper. https://www.academia.edu/7583194/The_Segmented_Sieve_of_Zakiya_SSoZ_ Here, again, is the link to the Nim code. Just install Nim (current 0.19.0) and compile and run it per instructions in code. I recommend people do that to see its outputs and verify its results. https://gist.github.com/jzakiya/6c7e1868bd749a6b1add62e3e3b2341e
Re: Farewell (of sorts)
On 10/4/2018 6:15 AM, Shachar Shemesh wrote: One of those things is this: October 14th will be my last day working for Weka.IO. My best wishes for your next adventure! -Walter
Re: Passing $ as a function argument
On 10/10/2018 05:01 PM, James Japherson wrote:
All I'm proposing is to to allow one to escape that syntax to function
calls.
foo(int index)
{
return arr[index];
}
and D can support
foo($-1);
which simply gets translated in to
arr[arr.length - 1]
I think you might have a misunderstanding about how $ works.
$ is a variable of type size_t. It's an integer. It is syntactic sugar.
You can't pass $ as a special value; it's expanded to refer to a
specific array at compile time, and it's an alias to the .length
property of that array. In order to pass it to a function, you need an
array as context.
Right now, the compiler looks at the enclosing index expression and uses
it to determine the value to pass.
You want it to look into the function you're calling to determine the
value to pass.
It's obvious what you want it to do in this particular case -- the
compiler should track where that function parameter is used, find the
relevant array, and use it to get the length to pass. How about:
module a;
extern(C) int foo(int index)
{
return someGlobalArray[index];
}
module b;
extern(C) int foo(int index);
void main() { foo($); }
The compiler doesn't have access to the function body to determine what
array you're talking about.
Or:
int foo(int index)
{
if (someCondition)
return someGlobalArray[index];
else
return someOtherArray[index];
}
foo($);
There are two arrays you could be talking about, potentially of
different lengths, and the compiler can't tell which you're going to access.
Or:
int foo(int index)
{
int something = index;
return someGlobalArray[something];
}
The compiler can't just track how the `index` variable is used; it has
to track how every variable is used and where it can get its value. This
gets complicated fast.
Or:
int foo(int index)
{
return std.process.environment["PATH"].split(":")[index];
}
The compiler has to execute the bulk of this function at runtime in
order to figure out what value to pass to it.
Your proposal only works in the most trivial cases. Because of that, if
we made that change, you'd try using it at call sites, then the function
definition would change slightly and your code would break.
It's generally not good for a programming language to have brittle
features like that.
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson
wrote:
Would be nice to be able to pass $ as a function argument to be
used in automatic path length traversing.
You can already do this, by returning a custom type from opDollar:
/// Define RealNumbers so that, given `RealNumbers r`, `r[x] ==
x` but `r[$] == real.infinity`.
struct RealNumbers
{
private struct Dollar {}
Dollar opDollar() { return Dollar.init; }
real opIndex(size_t index) { return index; }
real opIndex(Dollar dollar) { return real.infinity; }
}
unittest
{
RealNumbers r;
assert(r[5] == 5);
assert(r[$] == real.infinity);
}
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. If you want help with your paper, possibly some kind of decent financial incentive would be appropriate. If the algorithm benefits from more threads than finding or creating an implementation that runs on a GPU would probably be the true performance test. CPUs have like 4-8 cores in the mainstream? A GPU has hundreds, though with some limitations.
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 23:26:38 UTC, Dennis wrote:
Can you give a real-world, non-foo/bar example where you want
to use it? I have trouble understanding what you want to
accomplish.
I don't understand why you need to be convinced that this is
relevant.
Do you not realize that there are cases where one wants to select
the last element of a list without having to explicitly know it?
After all, the whole point of $ is exactly to specify this "last
element".
arr[$-1]
is EXACTLY shorthand for
arr[arr.length - 1]
So, you are already drinking the cool aid.
All I'm proposing is to to allow one to escape that syntax to
function calls.
foo(int index)
{
return arr[index];
}
and D can support
foo($-1);
which simply gets translated in to
arr[arr.length - 1]
All D does is look at the argument, when parsing, see's the $ and
say's "Ah ah, they they want to access the last element of the
array where index is used.
It then simply sets index to arr.length - 1.
It is NO different than what it already does except, because we
can use it in functions, explicitly(it only works at compile
time), it is just more sugar... again, $ is pure sugar.
There are many applications, I shouldn't have to justify why it
would be useful... it is, because it is as useful as it is.
If you claim it is not useful then you also must make that claim
about the current semantics of $.
But since you seem to need prodding, I will prod,
// returns elements from graph
GetNormalizedGraph(int index)
{
auto Graph[1000];
for(i = 0; i < Graph.length; i++)
Graph[i] = i^2/100;
return normalized(Graph[index]);
}
then
GetNormalizedGraph($-1)
always returns the last element. The point is, the caller doesn't
have to know the size of Graph inside... it can change without
breaking the program.
It beats having to use hacks like using negative -1 to represent
the length, etc.
The only problem is that we might use index for multiple arrays
all having different lengths, which would be a violation since it
would make the index multi valued. This can be solved by using
lengths for the arrays but setting the index to max value or an
compiler error.
// returns elements from graph
GetNormalizedGraph(int index = -1)
{
auto Graph[1000];
for(i = 0; i < Graph.length; i++)
Graph[i] = i^2/100;
return normalized(Graph[index == -1 ? Graph.length : index]);
}
The problem is when we do
GetNormalizedGraph()
it is tells us nothing
GetNormalizedGraph(-1)
is confusing, are we indexing at -1?
GetNormalizedGraph(int.max)
again confusing, the array isn't going to to be int.max long, is
it?
but
GetNormalizedGraph($-1)
makes perfect sense for what $ does.
The compiler just has to do a little magic, that is all... all
sugar is magic anyways. I don't know why some people want to have
their sugar in their coffee but the scoff at people who drink
cokes.
Re: Passing $ as a function argument
Can you give a real-world, non-foo/bar example where you want to
use it? I have trouble understanding what you want to accomplish.
On Wednesday, 10 October 2018 at 23:04:46 UTC, James Japherson
wrote:
It also has no context in and of itself. The compiler knows
what to do with it... The same can be done with function
arguments. You just haven't thought about the problem enough.
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
That also brings some difficulties. What kind of code do you
expect the compiler to generate when the declaration is unknown?
```
int getFromArray(int loc); // implemented in another file,
compiled separately
void main() {
getFromArray($); // what integer is passed?
}
```
Finally I want to note that accessing element $ is a range
violation, $-1 is the index of the last element in an array. $
can be used as an endpoint for intervals (where the endpoint is
excluded from the range):
```
auto popped = arr[1..$]; //pop the front element
auto elem = popped[$-1]; //okay, last element
auto err = popped[$]; //range violation
```
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 13:32:15 UTC, Simen Kjærås wrote:
On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson
wrote:
Would be nice to be able to pass $ as a function argument to
be used in automatic path length traversing.
void foo(int loc)
{
return bar[loc];
}
then foo($) would essentilly become
foo(&)
becomes ==>
return bar[$];
instead of having do to thinks like foo(bar.length).
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
then foo($) always returns a value and the outside world does
not need to know about foo. Since $ is a compile thing
expression and not used anywhere else this can always be
done(it is a symbolic substitution and has a direct
translation in to standard D code except $ cannot be used as
arguments like this the current D language grammar).
$ requires context (the array) for its value to be known - it's
not a compile-time expression any more than rand() +
currentWeather(getGpsCoordinates()) is. If $ were a valid
identifier, you could do something like this:
struct Sentinel {}
Sentinel $;
void foo(T)(T loc) {
auto bar = double[RandomPInt+1];
static if (is(T == Sentinel)) {
return bar[$];
} else {
return bar[loc];
}
}
unittest {
foo($);
}
Note that this would turn foo into a template, so that foo($)
creates a separate function from foo(3).
Since $ isn't a valid identifier, this is currently impossible,
but bachmeier's suggestion of foo!"$" works:
void foo(string s = "")(int loc = 0)
if (s == "" || s == "$") {
auto bar = double[RandomPInt+1];
static if (s == "$") {
return bar[$];
} else {
return bar[loc];
}
}
--
Simen
The whole point is not to use $ as an identifier but to specify
to the compiler of that it can rewrite it.
You seem to think that what the compiler does is absolute
authority. This is why I said "It would be nice" meaning that
if we had some a feature(which is entirely doable, not some
mathematical impossibility), it would allow one to express the
limit of an index in a concise way. Your templated version is not
concise. All you really proved is that the compiler can be given
a rewrite rule and handle this nicely.
$ is not an used for identifiers, it is used to specify that the
maximum length of the array it is used in is to be used. It is
short hand for doing hacks such as specifying -1 for maximum
length, etc.
You seem to to have not understood the problem.
I mean, don't you understand that the entire point of $ in the
first place is just syntactic sugar?
It also has no context in and of itself. The compiler knows what
to do with it... The same can be done with function arguments.
You just haven't thought about the problem enough.
Re: A Friendly Challenge for D
On 10/10/2018 03:05 PM, Jabari Zakiya wrote: https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ It would be great if you could provide a link to a freely downloadable version of this.
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 20:43:01 UTC, Kagamin wrote: On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: https://gist.github.com/jzakiya/6c7e1868bd749a6b1add62e3e3b2341e As i understand, main thread preallocates global memory and tracks it, and other threads don't track it? Here's an abreviated elementary explanation of the algorithm and implementation. You will need to read (download) my paper "The Segmented Sieve of Zakiya (SSoZ)" because I will make reference to things in it, to keep this as short as possible. https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ To really understand the math and theory of the algorithm requires primarily just understanding Table 3 on page 3 of the paper, as it encapsulates everything. You can read the paper to understand the language of the algorithm used in the code. Twinprimes are 2 (odd) primes that differ by only 2 eg. 3-5, 5-7, 11-13, 29-31. Table 3 shows all the residues values (prime candidates|pcs) and residues groups (resgroups|columns) to find all the primes upto 541 using P5 (modpg = 30, rescnt = 8). For a given value N, it will be represented with a PG table of some number of resgroups, with max size I call Kmax (the regroups value N residues in). Using P5, I only need to sieve primes along the residue tracks (restracks) that can produce twinprimes, here 11-13, 17-19, 29-31. Thus I create 3 byte arrays, one for each twinpair, and use the lower 2 bits to represent the upper and lower twinprime restracks. Then for each twinpair (here 3) I run 3 thread which perform the SSoZ on the entire Kmax length of resgroups in parallel. At the end I accumulate the results and print them out. This, in a nutshell, is what the algorithm does. The paper gives you enough to understand the fundamental nature of the algorithm, though I've learned so much more than in 2014. :) The larger the PG the more twinpair restracks (see page 14) there are to use. For larger numbers you want to use the largest PG possible that 'fits' into the hardware cpu. All my development|testing was done on laptops using Intel I5|I7 cpus with 4 or 8 threads. I'm really interested how it performs on other platforms (ARM, AMD, PowerPC, etc). The main proc "twinprimes_ssoz" manages program flow and set as follows: 1) accepts the input number (an integer) in "val" from the cli 2) sets "num" to be first odd number < "val" if "val" even 3) calls "selectPG" with "num" to select optimum Prime Generator (PG) parameters 4) compute various working parameters per selected PG and number value (see refs) 5) compute global values for number of primes, and their values, <= sqrt(num) for selected PG with proc "sozpg" 6) Set initial twinprime count for selected PG 7) Then with proc "segsieve" allocate one thread to perform SSoZ (segmented sieve of zakiya) on each twinprime pair residues (determined by selected PG), and count number of twinprmes computed in each thread. 8) Then determine true total twinprime count and last twinprime <= "num" It also is timing different intervals and prints out diagnostics and final output. The proc "twins_sieve" is the primary function that manages and performs the SSoZ for a given twinprim pair parameters in each thread. The more threads the faster the process goes. I'll provide more info later. I have to run now. I wanted to get this out now while I was at my laptop, and online.
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: https://gist.github.com/jzakiya/6c7e1868bd749a6b1add62e3e3b2341e As i understand, main thread preallocates global memory and tracks it, and other threads don't track it?
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: [...] Looking forward to this :)
Re: Passing $ as a function argument
On 10/10/2018 01:46 AM, James Japherson wrote: Would be nice to be able to pass $ as a function argument to be used in automatic path length traversing. $ only works in indexing operations because that's required to figure out what it refers to. However, you can mostly use it as a readonly variable there, with the caveat that you can't refer to it directly from function literals.
A Friendly Challenge for D
Hi. I hope this is the right place to request this, if not please tell me a better one. I had looked at D, and played with it some circa 2010~2012, but time and life took my priorities away. But I'm still interested in learning different languages, but there are so many more now it's hard to devote the time to learn them to some high level of proficiency. Subsequently, I started learning Nim, because I find the syntax and constructs simpler and more familiar than most (I'm coming mostly from a Ruby background). I have developed in Nim a program to find twinprimes that seems to be the fastest of its type, compared to primesieve (https://primesieve.org/) which claims to be the fastest, written in C++. Here is the code to my Nim implementation of twinprimes_ssoz. https://gist.github.com/jzakiya/6c7e1868bd749a6b1add62e3e3b2341e The total file is just 318 lines of code, with about 60 separate lines of comments. The code is extensively commented per line to explain what's happening. Reading the references given in the code introduction will explain the general process. See "The Segmented Sieve of Zakiya (SSoZ)" https://www.scribd.com/doc/228155369/The-Segmented-Sieve-of-Zakiya-SSoZ I am in the process of writing up a paper to explain this application, and implementation. What I am requesting here is for a person(s) who is an "expert" (very good) to create a very fast D version, using whatever tricks it has to maximize performance. I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. This algorithm is designed to be run in multiprocessing environments (more core/threads, better performance). The Nim version (0.18.0, 0.19.0 recently released) uses its native parallel processing structure. In C++, et al, it may be best implemented using OPenMP, or CUDA, etc. These are implementation details one versed in a language could determine. Well that's it. I am willing to share performance data, compared to primesive, if you like. The beauty of this algorithm|implementation is its simplicity in design, and minimal code. It shouldn't be that hard to understand to determine how to translate into D. Of course, I'm am fully available to answer questions and provide help. Thanks Jabari
Re: Farewell (of sorts)
On Thursday, October 4, 2018 7:15:23 AM MDT Shachar Shemesh via Digitalmars- d wrote: > Hello everyone, > > First of all, I know I've had a shorter than usual fuse of late. I'd > like to apologize to everyone about this. It is the culmination of quite > a few things increasing the load I'm under. > > One of those things is this: October 14th will be my last day working > for Weka.IO. Accordingly, my involvement in D will be considerably > reduced after that date, as working with D will no longer be my day job. > > A few of you knew that I was looking for a new job, but I postponed > officially announcing this, as I wanted to see who will be taking over > maintenance of Mecca. On that front, I have some good news and some bad > news. > > The bad news is that the person taking over will not have Mecca as his > sole responsibility. I am hoping he'll be able to do enough. > > The good news is that they put on this task my top pick for it. His name > is Eyal Lotem, and is a great developer. Some of you have met him as he > attended DConf three years ago. > > I will probably keep half an eye on the forum, and I might also be > around on the Slack channels. My email address will change as a result. > Feel free to find me at firstn...@lastname.biz, after applying the > relevant substitutions. I think it's a better captcha than running D > code :-) Well, best of luck in your new job, and thank you for your thoughts and contributions. I know that you often haven't been happy with how D does things, but you've had an impact, and you will be missed. You can of course continue to contribute in your free time, but given your views on D, that obviously doesn't seem likely. Hopefully, some form of your DIP gets accepted though given that D does seem a bit crippled with regards to some use cases and moves at the moment. Regardless, at minimum, in your time with Weka, you've made many of us around here think. - Jonathan M Davis
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson
wrote:
Would be nice to be able to pass $ as a function argument to be
used in automatic path length traversing.
void foo(int loc)
{
return bar[loc];
}
then foo($) would essentilly become
foo(&)
becomes ==>
return bar[$];
instead of having do to thinks like foo(bar.length).
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
then foo($) always returns a value and the outside world does
not need to know about foo. Since $ is a compile thing
expression and not used anywhere else this can always be
done(it is a symbolic substitution and has a direct translation
in to standard D code except $ cannot be used as arguments like
this the current D language grammar).
$ requires context (the array) for its value to be known - it's
not a compile-time expression any more than rand() +
currentWeather(getGpsCoordinates()) is. If $ were a valid
identifier, you could do something like this:
struct Sentinel {}
Sentinel $;
void foo(T)(T loc) {
auto bar = double[RandomPInt+1];
static if (is(T == Sentinel)) {
return bar[$];
} else {
return bar[loc];
}
}
unittest {
foo($);
}
Note that this would turn foo into a template, so that foo($)
creates a separate function from foo(3).
Since $ isn't a valid identifier, this is currently impossible,
but bachmeier's suggestion of foo!"$" works:
void foo(string s = "")(int loc = 0)
if (s == "" || s == "$") {
auto bar = double[RandomPInt+1];
static if (s == "$") {
return bar[$];
} else {
return bar[loc];
}
}
--
Simen
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson
wrote:
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
then foo($) always returns a value and the outside world does
not need to know about foo. Since $ is a compile thing
No language change is necessary right now if you write one more
character: foo!"$"
Re: Passing $ as a function argument
On Wednesday, 10 October 2018 at 08:46:42 UTC, James Japherson
wrote:
Would be nice to be able to pass $ as a function argument to be
used in automatic path length traversing.
void foo(int loc)
{
return bar[loc];
}
then foo($) would essentilly become
foo(&)
becomes ==>
return bar[$];
instead of having do to thinks like foo(bar.length).
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
then foo($) always returns a value and the outside world does
not need to know about foo. Since $ is a compile thing
expression and not used anywhere else this can always be
done(it is a symbolic substitution and has a direct translation
in to standard D code except $ cannot be used as arguments like
this the current D language grammar).
I don't really get your example and what benefits this would have?
And also what about the current behavior of the $ operator?
Re: extern(C++, ns) is wrong
On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote:
That's all you need really, any symbol you add will cause the
error.
extern(C++, bliz):
created a symbol "bliz", you can't import a package from
"bliz" cause then there's a symbol clash. I thought you
implemented extern(C++) ...
And yes, the example is actually complete. Again, but I'll
simplify the filenames:
ns/bar.d
-
module ns.bar;
import ns.baz;
extern(C++, ns):
ns/baz.d
-
module ns.baz;
import ns.bar;
extern(C++, ns):
dmd ns/bar.d ns/baz.d
I just found this little hack for such situations. It seems like
a combined effect of mixin template and normal mixin that seems
to work by abusing the creation of temporary module for each
instantiation.
The obvious downside is mixin/CTFE being memory hungry and
compilation times increase.
Also not sure what happens when there is name clashes due to
multiple symbols imported from multiple modules.
Tested with DMD 2.082 -m32mscoff on Windows.
file1.d
```
mixin template a01() {
mixin(`
extern(C++, namespaceone)
public void fun ();
`);
} mixin a01;
mixin template a02() {
mixin(`
extern(C++, namespaceone)
public void otherfun ();
`);
} mixin a02;
// the rest
```
file2.d
```
mixin template a03() {
mixin(`
extern(C++, namespaceone)
public void yetanotherfun ();
`);
} mixin a03;
// ...
```
Re: Using a development branch of druntime+phobos with ldc
On Wednesday, 10 October 2018 at 10:06:36 UTC, kinke wrote: LDC has its own forks of druntime and Phobos, with numerous required adaptations. So you'd need to apply your patches to those forks & build the libs (druntime and Phobos are separate libs for LDC), e.g., with the included ldc-build-runtime tool, which makes this painless: https://wiki.dlang.org/Building_LDC_runtime_libraries The Wiki page also shows how to link those libs instead of the shipped-with ones. Thanks.
Re: Using a development branch of druntime+phobos with ldc
On Wednesday, 10 October 2018 at 08:29:52 UTC, Per Nordlöw wrote: but what about rebuilding druntime+phobos with ldc and linking with that specific libphobos.so when compiling my benchmarking app with ldc? Is it possible? If so, what's the preferred way? LDC has its own forks of druntime and Phobos, with numerous required adaptations. So you'd need to apply your patches to those forks & build the libs (druntime and Phobos are separate libs for LDC), e.g., with the included ldc-build-runtime tool, which makes this painless: https://wiki.dlang.org/Building_LDC_runtime_libraries The Wiki page also shows how to link those libs instead of the shipped-with ones.
Re: Thread-safe attribution
struct Bob
{
threadsafe Atomic!(string[string]) y;
}
void f(ref threadsafe Bob b)
{
string[string] aa=b.y;
aa["b"]="c";
}
Like this?
Passing $ as a function argument
Would be nice to be able to pass $ as a function argument to be
used in automatic path length traversing.
void foo(int loc)
{
return bar[loc];
}
then foo($) would essentilly become
foo(&)
becomes ==>
return bar[$];
instead of having do to thinks like foo(bar.length).
The usefulness comes from the case when bar is local:
void foo(int loc)
{
auto bar = double[RandomPInt+1];
return bar[loc];
}
then foo($) always returns a value and the outside world does not
need to know about foo. Since $ is a compile thing expression and
not used anywhere else this can always be done(it is a symbolic
substitution and has a direct translation in to standard D code
except $ cannot be used as arguments like this the current D
language grammar).
Using a development branch of druntime+phobos with ldc
I'm experimenting with a new GC at https://github.com/nordlow/druntime/blob/fastalloc-gc/src/gc/impl/fastalloc/gc.d in my druntime branch fastalloc-gc. I've found a way to benchmark it using dmd as outlined at https://forum.dlang.org/post/zjxycchqrnxplkrlm...@forum.dlang.org but what about rebuilding druntime+phobos with ldc and linking with that specific libphobos.so when compiling my benchmarking app with ldc? Is it possible? If so, what's the preferred way?
