Re: Asio Bindings?
On Wednesday, 8 June 2016 at 23:19:13 UTC, Andrej Mitrovic wrote: I do have (Steinberg) ASIO binding in D. The problem is I couldn't release the bindings. I've asked Steinberg if it was OK to release D bindings and they were strongly against it unfortunately (and this was over 3 years ago..). Any kind of direct use of ASIO requires their approval first.. meaning you had to register on their website. I would recommend using third party libs that abstract the underlying engine, like PortAudio or RtAudio (the later of which I'm going to release a port of soon!). I had a binding to PortAudio but the devs of that library insisted on only supporting interleaved audio, RtAudio supports both interleaved and non-interleaved audio, and the library is easy to port. Any news on this?
Re: DIP: Tail call optimization
On Sunday, 10 July 2016 at 09:20:07 UTC, ketmar wrote: On Sunday, 10 July 2016 at 09:05:46 UTC, Tofu Ninja wrote: Your joking right? No personal attacks? where do you see personal attack in my words? i'm not saying that OP is dumb, and i'm not saying that his proposal is dumb. but it is *aimed* to dumb people (which doesn't automatically makes it dumb, you know). and i got tired of being "polite", from now on when i'll see dumb people, i'll say that i see dumb people, not "different" or "mentally impaired". as for the topic, i *tried* to explain why i see no value in the proposal. and part of the explanation included referring to "brain-damaged coders". but yeah, this (again) reminded me why i once resigned from NG. i'd probably should do it again, IRC is enough. Seems like your pretty dumb. You don't capitalize I, which is a basic grammatical rule in the English language. I'm sure you have your dumb logic for it though. Your real problem is that you are an arrogant prick that seems to think the world revolves around your tiny little pathetic uninteresting life. You are not god, not the end all be all, not the shit, not even popular or important. Stop trying to pretend you are and actually try to get along with other people, and accept that not every is as smart as you think you are. Maybe not everyone in the world is a bad ass leet coder as you are, maybe they are a bad ass Tennis player that does coding for fun on the side to expand their understanding of life. What do you do besides code? Are you actually any good at coding BTW? I doubt as good as you think you are. People like you have a very tiny understanding of reality and it shows. Please grow up, quickly. Your life and everyone around you will benefit. It's not about how big you think your balls are, how big they actually are, or if there tennis balls... Grow up, act your age(if your not 12, which you probably are, so act like your 30 then), get with the program, and try to help make everyone's life a bit more enjoyable. If you get your panties in a ruff because someone says something that you think is "dumb", enlighten them nicely... after all, you might just be the one needing enlightenment.
Re: Get return type statically
I should point out also that this should be inheritable. Eventually I would like to create an algebra of SuperFunctions. e.g., SF3 = SF1 + SF2 is a new super function that combines the parameter list of SF1 and SF2 and unionizes their return type. Both functions are called by Do(which will ultimately be handled by opCall). Other operations on the parameters can be created(intersection or subtraction, multiplication, etc...). I believe, to do this, I will have to create a string mixin that formulates Do(...) properly using a CTFE.
Re: Get return type statically
On Tuesday, 28 June 2016 at 01:41:03 UTC, "Smoke" Adams wrote:
I have a type
public class SuperFunction(T)
{
T t;
return(T) Do() { return t(); }
}
where T is a delegate or function. First, I would like to be
able to specify that this must be the case for SuperFunction so
we can't pass non-function/delegates for T. Second, How to
specify the return type of Do to match that of T.
e.g., SuperFunction!(bool function())
then return(T) should be bool.
Similarly, I would like to extra the T's parameters and make Do
have them also.
This way, SuperFunction!T.Do emulates T in every way.
I should mention that I am looking to make this as type safe as
possible as if Do was declared exactly like T manually.
Get return type statically
I have a type
public class SuperFunction(T)
{
T t;
return(T) Do() { return t(); }
}
where T is a delegate or function. First, I would like to be able
to specify that this must be the case for SuperFunction so we
can't pass non-function/delegates for T. Second, How to specify
the return type of Do to match that of T.
e.g., SuperFunction!(bool function())
then return(T) should be bool.
Similarly, I would like to extra the T's parameters and make Do
have them also.
This way, SuperFunction!T.Do emulates T in every way.
Re: Local fixed sized arrays
On Monday, 27 June 2016 at 22:56:35 UTC, Ali Çehreli wrote:
On 06/27/2016 02:58 PM, Smoke Adams wrote:
I'm in need of a way to create a local array that isn't GC'ed.
It must
be dynamic in the sense of setting the size at compile time
but it will
be used only in scope and only on structs.
function x(int y)
{
bool[y] arr;
arr ~= 3;
}
I care about slicing or anything but appending, removal, and
indexing. I
don't even need bounds checking. I don't see a need to get
locked in to
the GC for such simple cases.
One way is to make x() a function template:
import std.stdio;
void x(int y)() {
bool[y] arr;
arr[y/2] = true;
writeln(arr);
}
void main() {
x!5();
}
Ali
But the length depends on runtime behavior. Might be 5 or 100.
This doesn't handle it, does it?
I already make a simple malloc based array that does what I want.
Looks like a normal array with ~=, [], foreach. Does what I need
it to do. Only works with BasicTypes of course.
Local fixed sized arrays
I'm in need of a way to create a local array that isn't GC'ed. It
must be dynamic in the sense of setting the size at compile time
but it will be used only in scope and only on structs.
function x(int y)
{
bool[y] arr;
arr ~= 3;
}
I care about slicing or anything but appending, removal, and
indexing. I don't even need bounds checking. I don't see a need
to get locked in to the GC for such simple cases.
Diff between function and delegate
I have alias fnc = void function(Object); alias del = void delegate(); Does func avoid the GC? I am passing in this to Object so I don't technically need a delegate or a "context". I want to be sure that I'm actually gaining something here by doing this. I read somewhere that delegates only require the GC when they use objects outside their scope. Do delegates always use the GC or only in certain cases?
Re: executeShell doesn't work but system does
On Sunday, 26 June 2016 at 16:02:18 UTC, ag0aep6g wrote:
On 06/26/2016 05:37 PM, Smoke Adams wrote:
[...]
Unsolicited spelling correction: no 'i' in "deprecated".
[...]
`system` directly prints its output, `executeShell` returns it
in a tuple with the status code. Maybe cls works by printing
some specific clear code. If so, you have to print the output
of the command.
[...]
neither work but
wait(spawnShell("cls"));
executeShell doesn't work but system does
system("cls") works but executeShell doesn't. system is
depreciated.
What's going on? The docs say that it creates a new process. I
simply want to clear the console!
Re: Call to Action: making Phobos @safe
On Saturday, 25 June 2016 at 22:44:37 UTC, Walter Bright wrote: Andrei identified a key blocker for D adoption is the incomplete implementation of @safe. I'm working on the compiler end. But Phobos has a lot of code that is pointlessly not @safe, making it frustrating to write @safe code that calls Phobos. Some are listed in Bugzilla, most are not. [...] How hard would it be to add a compiler switch, similar to -vgs that shows every non-safe function? This would not just help out with phobos.
Re: Should % ever "overflow"?
On Sunday, 26 June 2016 at 03:54:28 UTC, deadalnix wrote: On Sunday, 26 June 2016 at 02:05:53 UTC, "Smoke" Adams wrote: On Sunday, 26 June 2016 at 00:31:29 UTC, deadalnix wrote: On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams wrote: This proves nothing. This isn't a proof, this is a definition. This is the definition that is used by all programming languages out there and all CPUs. It isn't going to change because someone on the internet think he has a better definition that provide no clear advantage over the current one. Again, no proof at all Either can't read or you can't think. Which is it ? and inaccurate. Not every programming language or cpu does this. Please don't make up facts to support your "definitions" and desires. Having a negative modulo is just ignorant. Languages: C#: https://msdn.microsoft.com/en-us/library/0w4e0fzs.aspx Java: https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.17.3 C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf (See 6.5.5 for update on % operator, mentioning, example at 7.20.6). Python2: https://docs.python.org/2/reference/expressions.html Python3: https://docs.python.org/3/reference/expressions.html CPUs: Arm7(eeabi): https://github.com/wayling/xboot-clone/blob/master/src/arch/arm/lib/gcc/__aeabi_idivmod.S Arm7(Darwin): http://opensource.apple.com//source/clang/clang-163.7.1/src/projects/compiler-rt/lib/arm/modsi3.S Mips: http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html (See DIV instruction) X86: http://x86.renejeschke.de/html/file_module_x86_id_137.html Now I'm sure there are a weird CPU that isn't produced since the 80s and that D will never support that do it in some other way, but for all platforms that matter today, this isn't the case. This is not MY definition, this is the definition everybody except you uses? Even PHP get this right (http://php.net/manual/en/language.operators.arithmetic.php). Now champion, what do you have supporting your definition ? Your a moron. I guess you think just because everyone believes in Santa Clause it means he exists? http://mathworld.wolfram.com/Congruence.html https://en.wikipedia.org/wiki/Modulo_operation https://en.wikipedia.org/wiki/Modular_arithmetic http://stackoverflow.com/questions/1082917/mod-of-negative-number-is-melting-my-brain https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6422581 http://www.mathworks.com/help/matlab/ref/mod.html?requestedDomain=www.mathworks.com It's one thing to claim that the sign of the modulo is the same as the sign of the divisor, but entirely different to claim the modulo should be negative. Of course, I don't expect a neanderthal like yourself to understand that. Have fun lemming. Oh, hey, I'm going to define that your an idiot! Thanks for agreeing with me.
Re: Should % ever "overflow"?
On Sunday, 26 June 2016 at 00:31:29 UTC, deadalnix wrote: On Saturday, 25 June 2016 at 23:01:00 UTC, "Smoke" Adams wrote: This proves nothing. This isn't a proof, this is a definition. This is the definition that is used by all programming languages out there and all CPUs. It isn't going to change because someone on the internet think he has a better definition that provide no clear advantage over the current one. Again, no proof at all and inaccurate. Not every programming language or cpu does this. Please don't make up facts to support your "definitions" and desires. Having a negative modulo is just ignorant.
Re: Should % ever "overflow"?
On Friday, 24 June 2016 at 20:43:38 UTC, deadalnix wrote:
On Friday, 24 June 2016 at 20:33:45 UTC, Andrei Alexandrescu
wrote:
In a checked environment, division may "overflow", e.g. -6 /
2u must be typed as uint but is not representable properly one.
How about remainder? I suppose one can make the argument that
remainder should never overflow (save for rhs == 0), because
it could be defined with either a positive or negative
denominator (which is not part of the result).
What's the most reasonable behavior?
Andrei
Most reasonable is
numerator = quotient * divisor + remainder
Which means it can be negative.
This proves nothing.
Wiki:
For a ***positive integer n***, two integers a and b are said to
be congruent modulo n, written:
a ≡ b ( mod n ) , {\displaystyle a\equiv b{\pmod {n}},\,}
a\equiv b{\pmod {n}},\,
if their difference a − b is an integer multiple of n (or n
divides a − b). The number n is called the modulus of the
congruence.
For any "negative" remainder, all one has to do is subtract one
from the divisor:
quotient*(divisor - 1 + 1) + remainder
= quotient*new_divisor + pos_remainder
where new_divisor = divisor - 1, pos_remainder = quotient +
remainder
There are problems with allowing the remainder to be negative and
it is generally best to restrict it to positive values.
e.g., 129 = 2*52 + 25 OR 3*52 - 27.
In the second case, we have 129/52i = 3? Basically by restricting
to positive integers, we have a more natural interpretation and
relationship to floor and ceil functions and we don't have to
worry about it being negative(think of using in in an array
indexing scheme),
Re: Get calling this, if exists
On Friday, 24 June 2016 at 15:35:57 UTC, Steven Schveighoffer
wrote:
On 6/24/16 11:15 AM, Smoke Adams wrote:
On Friday, 24 June 2016 at 03:16:58 UTC, Meta wrote:
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work
as a
compile time parameter, given that the reference itself is a
runtime
value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
I don't want to be explicit! One can be explicit with __FILE__
too but
one doesn't have to be.
__FILE__ is a constant, so is __LINE__. __THIS__ would not be,
so this is somewhat different.
With UFCS, you can get close:
void log(T)(T obj, string s)
{
...
}
struct Test
{
void test(string s)
{
this.log(s);
}
}
But I believe you have to call with explict 'this'.
Perhaps an opDispatch can help, but seems an awful lot to avoid
explicit passing of this variable.
-Steve
The problem with UFCS is that I am using variadic parameters. The
logging function isn't designed to accept the first parameter as
this.
It would be much easier to simply have the compiler "insert" it
using __THIS__. Just because it isn't constant isn't really that
big of a deal to the compiler. It could just manually add the
parameter at the end of of the arguments.
I would also have to convert all the calls to this.log.
This becomes problematic because not not all calls are inside
objects.
We have __FUNCTION__ so, __THIS__ seems somewhat natural. Null
for outside of objects is fine.
Re: Please rid me of this goto
On Friday, 24 June 2016 at 03:22:11 UTC, Timon Gehr wrote: On 24.06.2016 04:36, Smoke Adams wrote: You do realize that e^(-1/t)^t is a counter example? e^(-1/t) -> 0 as t -> 0 t -> 0 as t -> 0 That's not a counterexample to anything I said. ^ is discontinuous at (0,0) and indeed, you can force the limit to an arbitrary value by choosing the two expressions the right way. That's clear. but e^(-1/t)^t does not -> 1 as t-> 0, which is obvious since it/s 1/e. So, We can define 0^0 = 1 and maybe that is better than 2, but it is arbitrary in the sense that it's a definition. It may bear fruit but it is not necessarily meaningful. ... It's meaningful in those cases where you want to use 0^0, and otherwise just don't use it. Suppose a person is running some numerical simulation that happens to be computing an a value for an equation that is essentially based on the above. Then the numerical simulation is inherently broken. a^b takes on any arbitrary non-negative value in an arbitrary small region around (0,0) and is undefined at many points in such a region. (BTW: It would be fine with me if 0.0^^0.0 was NaN -- that's a completely different case than the one at hand: pow on integers.) ... break the laws of physics by arbitrarily defining something to be true when it is not. ... Utter nonsense. (Also note that the 'laws of physics' typically give rise to piecewise analytic functions, and if you only consider analytic functions, 0 ^ 0 = 1 is actually the right answer.) Please, it seems you only know enough about math and physics to get you into trouble. 1. do you realize that the "equations" of man are only approximations to the equations of life? Or do you really think gravity behaves exactly as 1/r^2? Also, what about when r = 0? how do you propose to define it? Set it to 0? 1? -infinity? What's the solution here? Surely there is a non-arbitrary solution? 2. You hold way to much faith in man. Math and Science are tools, tools are created, manipulated, updated, retooled, and used to make other tools. Their only use is how well they work. They work quite well but we cannot prove how accurate they are. If you know about Godel, you would know that we can't even prove that we can't prove anything(which itself is meaningless). 3. What you are arguing is the convenience factor. Sometimes also known as the lazy factor. Just admit it and stop trying to prove that somehow god has made this choice. 4. An equation in math is just one form of the same abstract mathematical construct. Simply put: f(x) = x = sqrt(x)^2 = inv(cos(x)) = All these types of identities can substituted in an equation to change it's form. 5. All forms are different. Obviously x != sqrt(x)^2 in all cases. Hence the transformations using identities are not actually equal in all cases: sqrt(x)^2 = x only for x >= 0. 6. Symbols are not absolute. They are mans creation and agreement on their meaning so they can be useful. x is just chicken scratch until everyone agrees on how to interpret it. 7. And this is where the problem lies. Assumptions can be deadly. They should only be made when they have to. Your argument about using integers only is nonsense because you have made the assumption that only integers will ever be used and also that the integers are not related to the real number case. Both of these are provably false. e.g., Lets suppose that, for integers, we have PowI(x,y) and for reals, PowR(x,y). Someone does if (isInteger(x) && isInteger(y) return PowI(x,y); else return PowR(x,y); Why they might do this is immaterial.. I just did it, so it is possible. Maybe PowI is faster because of some type of new algorithm someone came up with. 8. The truth is the correct answer. The truth of the matter is, 0^0 is undefined. Accept it, just because you don't like the answer doesn't give you the right to change it. This is the same belief many have in Santa Clause, the Tooth Fairy, Jesus Christ, etc. No proof they exist but they belief it and change the truth to match the result(which is anti-science, anti-math, and anti-logic, anti-progress, and anti-truth and ultimately anti-god). It's one thing to argue the convenience factor, and this is ok but it should be well understood by everyone. The other is to argue that what you are saying is fact, and this is clearly demonstrably false. Arguing a special case, such as using only integers, is just as false because F => F is a false statement. 9. If you are using some other kind of logical system than the standard one that all of math and science is built on, then forgive me for being wrong... But you didn't state this from the beginning and I mistakenly assumed we were in the same reality.
Re: Get calling this, if exists
On Friday, 24 June 2016 at 03:16:58 UTC, Meta wrote:
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work
as a compile time parameter, given that the reference itself
is a runtime value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
I don't want to be explicit! One can be explicit with __FILE__
too but one doesn't have to be.
I don't care if it's null.
Get calling this, if exists
Is there a type of __THIS__ construct similar to __FILE__ and
__LINE__?
Something that returns the current this ptr if it exists, null
otherwise.
Log(string filename = __FILE__, Object obj = __THIS__)()
{
// inspect obj and do stuff
}
Re: Please rid me of this goto
On Friday, 24 June 2016 at 01:49:27 UTC, Timon Gehr wrote: On 24.06.2016 02:14, H. S. Teoh via Digitalmars-d wrote: On Fri, Jun 24, 2016 at 01:58:01AM +0200, Timon Gehr via Digitalmars-d wrote: On 24.06.2016 01:18, H. S. Teoh via Digitalmars-d wrote: On Thu, Jun 23, 2016 at 11:14:08PM +, deadalnix via Digitalmars-d wrote: On Thursday, 23 June 2016 at 22:53:59 UTC, H. S. Teoh wrote: This argument only works for discrete sets. If n and m are reals, you'd need a different argument. For reals, you can use limits/continuation as argument. The problem with that is that you get two different answers: lim x^y = 0 x->0 but: lim x^y = 1 y->0 ... That makes no sense. You want lim[x->0] x^0 and lim[y->0] 0^y. Sorry, I was attempting to write exactly that but with ASCII art. No disagreement there. So it's not clear what ought to happen when both x and y approach 0. The problem is that the 2-variable function f(x,y)=x^y has a discontinuity at (0,0). So approaching it from some directions give 1, approaching it from other directions give 0, and it's not clear why one should choose the value given by one direction above another. ... It is /perfectly/ clear. What makes you so invested in the continuity of the function 0^y? It's just not important. I'm not. I'm just pointing out that x^y has an *essential* discontinuity at (0,0), Which just means that there is no limiting value for that point. and the choice 0^0 = 1 is a matter of convention. A widely-adopted convention, but a convention nonetheless. It does not change the fact that (0,0) is an essential discontinuity of x^y. ... No disagreement here. Nothing about this is 'arbitrary' though. All notation is convention, but not all aspects of notations are arbitrary. [...] not something that the mathematics itself suggest. ... What kind of standard is that? 'The mathematics itself' does not suggest that we do not define 2+2=5 while keeping all other function values intact either, and it is still obvious to everyone that it would be a bad idea to give such succinct notation to such an unimportant function. Nobody said anything about defining 2+2=5. What function are you talking about that would require 2+2=5? ... There exists a function that agrees with + on all values except (2,2), where it is 5. If we call that function '+', we can still do algebra on real numbers by special casing the point (2,2) in most theorems, but we don't want to. It's clear that 0^0=1 is a choice made by convenience, no doubt made to simplify the statement of certain theorems, but the fact remains that (0,0) is a discontinous point of x^y. Yup. At best it is undefined, since it's an essential discontinuity, Nope. x=0 is an essential discontinuity of sgn(x) too, yet sgn(0)=0. just like x=0 is an essential discontinuity of 1/x. That is not why 1/0 is left undefined on the real numbers. It's a convention too, and it is not arbitrary. What *ought* to be the value of 0^0 is far from clear; it was a controversy that raged throughout the 19th century and only in recent decades consensus began to build around 0^0=1. ... This is the 21st century and it has become clear what 0^0 should be. There is no value in discrediting the convention by calling it 'arbitrary' when it is not. You do realize that e^(-1/t)^t is a counter example? e^(-1/t) -> 0 as t -> 0 t -> 0 as t -> 0 but e^(-1/t)^t does not -> 1 as t-> 0, which is obvious since it/s 1/e. So, We can define 0^0 = 1 and maybe that is better than 2, but it is arbitrary in the sense that it's a definition. It may bear fruit but it is not necessarily meaningful. Suppose a person is running some numerical simulation that happens to be computing an a value for an equation that is essentially based on the above. Because of numerical rounding, lets suppose we end up with t = 0. At that moment the calculation goes haywire and destroys a spacecraft with 3 people on it. Those people have families and young children who end up growing up without a father and turn to crime All because of some idiot who wanted to break the laws of physics by arbitrarily defining something to be true when it is not. Seriously, your logic has severe consequences. Just because 0^0 looks like 1, it is far more complex than that and your tiny little brain can't comprehend them. First law of mathematics: Please don't kill people, computers can't program themselves and grants can't write themselves, nor can the IRS collect from dead people. Please, Just say no to 0^0 = 1! Luckily, it was only a stimulation and no one got hurt... this time!
