visibility deprecation with last dmd compiler
I have 2 files
file abc.d:
==
module my.abc;
class Abc
{
private int x;
this() { this.x = 1; }
}
==
and xyz.d:
==
module my.xyz;
import my.abc;
class Xyz: Abc
{
this() { super(); this.x = 2; }
}
==
Compilation fails with "Deprecation: my.abc.Abc.x is not visible
from module xyz"
As I understand, the reason is
https://dlang.org/changelog/2.071.0.html#dip22
But how can I use private fields from descedant class?
Re: Pointer to private structure
On Monday, 19 December 2016 at 10:14:49 UTC, Ali wrote: On Monday, 19 December 2016 at 06:42:27 UTC, Nikhil Jacob wrote: [...] What're you trying to do here? Forward declarations in C++ are used to solve a few different things: 1. Reduce build times (unneeded in D AFAIK) 2. Break cyclic references (unneeded in D again?) 3. Give APIs visibility (D's modules and Access layers solve this) 4. Maintain binary compatibility while allowing internal data changes (aka pimlp idiom) <-- This I believe you cannot do in D - https://wiki.dlang.org/Access_specifiers_and_visibility (someone correct me if I'm wrong) I've seen something about .di files in D. But they seem flakey a bit. I was trying to do something similar to pimlp idiom. But after thinking over it, I found a better way in D. Thanks for pointing to the wiki
Re: Pointer to private structure
On Monday, 19 December 2016 at 06:21:10 UTC, ketmar wrote: i bet that just trying this with D compiler will take less time than writing forum post. I did try but it seems to give compilation failure... Let me try once more and I will get back with more details.
Pointer to private structure
In C, we can define a struct without body in an include file and use pointer to that structure For examples in public header file. struct data; data* new_data(); We can then define the elements of struct data privately inside the implementation of library. Can we do this in D without using void* ?
Re: How to override impure function from pure function
On Tuesday, 13 December 2016 at 05:10:02 UTC, Nicholas Wilson
wrote:
On Tuesday, 13 December 2016 at 04:48:11 UTC, Nikhil Jacob
wrote:
In the D spec for pure functions it says that a pure function
can override
"can override an impure function, but an impure function
cannot override a pure one"
Can anyone help me how to do this ?
what this means is
class Foo
{
void foo() { ... }
}
class Bar : Foo
{
override void foo() pure { ... }
}
is allowed. but
int someglobal;
class Foo
{
void foo() pure { ... }
}
class Bar : Foo
{
override void foo() { someglobal = 42; }
}
in not.
I mistook the original statement to mean that an impure function
can be called from a pure function with some manual overrides.
Thank you for the clarification.
How to override impure function from pure function
In the D spec for pure functions it says that a pure function can override "can override an impure function, but an impure function cannot override a pure one" Can anyone help me how to do this ?
Re: Check whether function/delegate uses any shared or global variables
On Monday, 12 December 2016 at 12:30:42 UTC, Jacob Carlborg wrote: On 2016-12-12 12:15, Nicholas Wilson wrote: there is the pure function attribute, how ever this still allows you to use globals *if you pass them as parameters to the function*. And it can access immutable global data. Thank you all for the help
Re: Check whether function/delegate uses any shared or global variables
On Monday, 12 December 2016 at 11:15:28 UTC, Nicholas Wilson wrote: On Monday, 12 December 2016 at 11:02:21 UTC, Nikhil Jacob wrote: Is there any way to check whether a function/delegate passed to a function uses any shared or global variables ? I could not find any in std.traits. there is the pure function attribute, how ever this still allows you to use globals *if you pass them as parameters to the function*. see https://dlang.org/spec/function.html#pure-functions Make sense.. I have two follow up questions 1. What about delegates ? 2. If a function is not explicitly declared as pure but satisfies the conditions of a pure function then can i check whether the function is pure using functionAttributes in std.traits.
Check whether function/delegate uses any shared or global variables
Is there any way to check whether a function/delegate passed to a function uses any shared or global variables ? I could not find any in std.traits.
Re: State of issues.dlang.org
On Tuesday, 25 October 2016 at 13:04:22 UTC, ag0aep6g wrote: On 10/25/2016 05:17 AM, Jacob wrote: I think you're mistaken in thinking that no one looks at issues. I usually at least glance over newly filed ones, and often check if they're valid. Let me rephrase that then, no one does anything about the issues. I look at a lot of issues to, some that can easily be answered and the issue closed. But that's the problem, everyone is just an observer and no one does anything.
Re: State of issues.dlang.org
On Tuesday, 25 October 2016 at 12:48:48 UTC, Vladimir Panteleev wrote: I don't think its state is much worse than that of a typical bugtracker for projects of this scale. What projects are those? For ones of similar size at the very least all issues get tagged. There are a bunch of issues that have nothing done with them. Anyways for the site itself, it seems to be lacking features. It is a standard Bugzilla instance. We do not develop the software. That doesn't make the point any less valid. If something is broke you fix it or replace it. When viewing issues as a list there isn't that much information about the issue, other than the summary. You can create custom views for whatever task you have at hand. Didn't know that, the setting was buried at the bottom of the page past the hundreds of errors. The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues. If something is unclear, please refer to the Bugzilla manual. Not unclear so much as the feature is there and is never used. If it is a bit bigger of an enhancement and needs a DIP to add the functionality. Feature requests that require a DIP do not belong on Buzilla. Who is to determine that? I see a lot of Buzilla reports that are large enhancements that should need a DIP. But they stay as open issues flagged enchancement. That's the point. There's no, or at least no one does say, this needs a DIP, closes the issue to remove it from sight. TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place. Err, no. Just because you haven't seen a Bugzilla instance elsewhere doesn't mean we should replace it. The UI is a bit 90's, but otherwise it has served us well. Umm, who said I haven't seen it elsewhere? If a system is un-maintainable that doesn't mean it's ok and should just be overlooked.
State of issues.dlang.org
I sort of feel that issues.dlang.org is an unmaintained mess. Anyone has access to it every aspect of editing anyone else's issue, so anyone could be added really without any oversight. There's no editing one's comments so I often see people making multiple posts to themselves to add more information or to correct themselves. That's just a minor issue. There are 16k issues (I'm guessing every ID basically means a unique issue) for DMD alone. It has some issues where an individual made a comment, no tags or anything was set, and then 2-3 years later its remained like that til someone reserves it with a change or comment Only for there only to be that one additional comment then the issue gets buried for another year or so. There are so many like this and it is unclear what exactly the issue is or what needs to be done with it. Almost every issue is like this as well. There are some discussions in some of the issues but a lot of the times nothing seems to be done about them. Anyways for the site itself, it seems to be lacking features. When viewing issues as a list there isn't that much information about the issue, other than the summary. Things that are listed with an issue: The ID, it's alright I guess can be useful from the list, knowing the issue number to reference it in a pull request or other issue. The "Product", completely useless, is D for everything on the site essentially. The "Comp", that's fine for searching for errors across multiple but kind of useless when viewing the issue list for a single project. The "assignee", kind of useless and it's never used, only every seen it set to "nobody". The "Status", kind of useless don't need to know that information, just need to know if it is open or closed and that shouldn't really be part of the list ; if I search for issues I should just specify if I want them to be open or not. The "Resolution", only ever seen it as "---", maybe it means something for closed issues but I haven't seen any closed issues. So what is the point of the list if it doesn't display any useful information. There's no, "needs work", or "enhancement" or any other description that can add to what the issue is or what it needs to have done to it. When there are 16k+ issues, having better information in the list view is desired. To make searching for an issue easier, rather than having to click on each one individually item to get more information from it. There's no lack of space, especially when almost every column could be removed for something with more useful information. So now there are this many issues and it probably won't be an easy task to go through all of them and determine which ones are actually valid. To weed out all the issues that can simply be deleted. It would be nice to know what needs to be done for an issue, if it is a small enhancement and can simply get a PR to add the functionality. If it is a bit bigger of an enhancement and needs a DIP to add the functionality. Or whether an issue exists and how the issue needs to be handled. Is it a feature that was implemented incorrectly and needs to be reworked. Or was it possibly an oversight of a combination of features and a more thought out solution needs to be created, which might involve something more extreme as removing a previous feature. Well wrote more than I planned to, didn't re-read it though, probably should considering I won't be able to edit it. Oh well. TLDR; The issue system in place right now needs to be removed and a better system with oversight put in place. Rather than the wildwest it is now, with no oversight and issues existing for years before anyone looks at them. If anyone even ever looks at them. Some of them aren't even real issues and they just end up clogging the pipes, so to speak.
Re: I close BIP27. I won't be pursuing BIPs anymore
On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu wrote: On 10/18/2016 04:15 PM, Atila Neves wrote: I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free". That's right, thanks Atila. -- Andreu Actually thinking it over some more, you would be able to distinguish it. You would simply treat func(Foo) to be the equivalent of func(Foo&&) in C++. void func(ref const Foo); void func(Foo); enum ctfeFoo = Foo(); func(ctfeFoo); // calls func(ref const Foo); // zero reason to do a move as enum's can't house runtime values const Foo foo; func(foo); // calls func(ref const Foo); func(Foo()); // calls func(Foo) // no ambiguity, same reason there isn't one for C++'s && // Foo() is modifiable temporary import std.algorithms.mutation : move; Foo rfoo; func(move(rfoo)); // calls func(Foo) So now you would be able to define a single function to take both rvalues and lvalues.
Re: I close BIP27. I won't be pursuing BIPs anymore
On Tuesday, 18 October 2016 at 20:22:58 UTC, Andrei Alexandrescu wrote: On 10/18/2016 04:15 PM, Atila Neves wrote: I think I get it; I'm just not sure given the comments that pop up in the forum. Isn't one of the main reasons distinguishing between these two? void fun(ref const Foo); void fun(Foo); If they can't be distinguished, you don't get move semantics "for free". That's right, thanks Atila. -- Andreu Is that really the only reason they aren't being allowed? Whenever I use const& in C++ I generally don't want to copy or move anything. How about adding a new qualifier? void func(ruleThemAll(Foo) foo); const Foo f; func(f); // ok func(Foo()); // ok // --- void func(ref ruleThemAll(Foo) foo); void func(ref const Foo);// error: ruleThemAll can have no overloads that match // function(Foo) or function(ref Foo)
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.
Add "Go To Source" for Docs?
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.
Re: Ranges and Take
On Wednesday, 5 October 2016 at 02:16:57 UTC, Jonathan M Davis wrote: On Wednesday, October 05, 2016 00:10:39 Jacob via Digitalmars-d wrote: Having access to iterators would solve the problem here I think. But everything is ranges and that wouldn't entirely fit. For a linked list though, you can create a range from a single iterator. The implementation of DList's Range is pretty much two iterators. Oh well, have to implement my own anyways I guess, since DList uses the garbage collector. A replacement for std.container is in the works, but who knows when that will be done (or whether the result will really be what you want anyway). In the interim, I'd recommend checking out http://code.dlang.org/packages/emsi_containers - Jonathan M Davis Well I also need it to support noncopyable types. Which right now isInputRange (and other ranges) doesn't allow if "front" returns a reference. I found that it was already posted here a year or two back so I guess it isn't a priority to fix.
Re: Ranges and Take
Having access to iterators would solve the problem here I think. But everything is ranges and that wouldn't entirely fit. For a linked list though, you can create a range from a single iterator. The implementation of DList's Range is pretty much two iterators. Oh well, have to implement my own anyways I guess, since DList uses the garbage collector.
Ranges and Take
Currently some implementations rely on the struct Take from std.range to obtain certain functionality. I think this is a bit flawed, as it isn't generic enough. As such you end being locked to this "Take" structure. Which means you can't define your own implementation if needed. https://github.com/dlang/phobos/blob/v2.071.2/std/container/dlist.d#L649 It is used here in DList in "linearRemove". There is a function "tail" which implements getting a range for the last few elements. But it is a bit inefficient as it first has to go through every single element from the front. At least in the case of a linked list. So maybe I want to implement my own "TailTake", that now means defining a new overload for "linearRemove" in DList. Then not only that there are already other functions in std.range that do define their on constructs, "takeOne()" for example does this. So that function can't be used with DList, and so forth.
Re: D and Secure Programming
import std.stdio;
struct SomeStruct
{
int value;
void func()
{
writeln(value);
}
}
void main()
{
SomeStruct someStruct;
someStruct.value = 333;
auto func = cast(void function(ref
SomeStruct))
func(someStruct);
}
Has worked so far for me.
Re: D and Secure Programming
On Monday, 3 October 2016 at 01:24:45 UTC, Walter Bright wrote: On 10/2/2016 4:57 PM, Jacob wrote: While on the subject, taking the address of a struct's method returns an incorrect type that allows it to be called incorrectly even with @safe. Which is a bit ironic cause then it can't be cast'd to a type that is actually safe to use. auto func = func(); // ops runtime error, allows calling function that needs an object Please file bugzilla issues for these sorts of things. Thanks! > C++ makes this a pointer to a member function which looks like: "void > (SomeStruct::*)()" for the example above. Either way for safety and just having > a defined way to call a pointer to a member function would be nice. http://digitalmars.com/articles/b68.html Has existed since 2010... https://issues.dlang.org/show_bug.cgi?id=3720 Also using a proxy is suboptimal, if you use a cast() and add in "ref SomeStruct" as a parameter, it functions properly and doesn't require the proxy.
Re: D and Secure Programming
While on the subject, taking the address of a struct's method returns an incorrect type that allows it to be called incorrectly even with @safe. Which is a bit ironic cause then it can't be cast'd to a type that is actually safe to use. auto func = func(); // ops runtime error, allows calling function that needs an object C++ makes this a pointer to a member function which looks like: "void (SomeStruct::*)()" for the example above. Either way for safety and just having a defined way to call a pointer to a member function would be nice.
Re: Allow Explicit Pointer for Auto Declaration
On Friday, 30 September 2016 at 13:37:43 UTC, Meta wrote:
This suggestion has come up before but Andrei is against it.
https://github.com/dlang/dmd/pull/3615
It brings a tear to my eye.
Ah that's a shame, would like to reopen that conversation. Is
there any way to ping him on the forums. I can see his case for
not wanting "[$]" arrays, but I feel it's a different case for
pointers.
Andralex on github:
Complicates the language without a corresponding increase in
power
I'd say it increases readability and maintainability, that may
not be an increase in "power" (what does that even mean) but I'd
argue maintainability and readability are more important than
"power". When you see "auto" you can't infer any information
about it making it harder to read code. Adding some extra
information to it can make it more readable at a glance.
Small obscure feature of dubious usefulness that creates a
precedent for other small obscure features of increasingly
dubious usefulness
This functionality already exists in function form as seen below.
So the foot is already in the door, it's a matter adding the
functionality to auto declarations, for completeness and such ;).
How about accepting stuff like that in function parameters,
etc? It's easy to argue that on grounds of completeness, now
that there's a foot in the door.
Ref as well. The functionality of reference is almost exactly a
partial type specification. As in C++ a reference is denoted by
"&", when you look at the implementaiton in C++ they are almost
exactly the same.
for(auto* v : args);
for(auto& v : args);
So the functionality already exists as a reference as well. It
exists in a function parameter as well as in a foreach statement.
Basically everywhere that you made the argument against the
feature, as it could extend to those areas as well. The only
place "ref" doesn't exist in D is when specifying a variable.
Otherwise it's almost exactly the same feature.
import std.stdio;
void test(T)(T* t) // functionality already exists in
function form
{
writeln(T.stringof);
}
void main()
{
int* p;
test(p);
// test(10); // error won't compile this
foreach(ref v ; 0 .. 10) // basically equivalent to C++:
for(auto& v : arr)
{
}
}
Re: Allow Explicit Pointer for Auto Declaration
On Friday, 30 September 2016 at 05:01:52 UTC, Steven Schveighoffer wrote: On 9/29/16 9:48 PM, Jacob wrote: It still requires the &, what it prevents is this situation: auto pValue = expr; // wanted pointer, expr evaluates to non-ptr value through change of code or simply forgetting "&" Wait, what happens when you do that? If that's now an error, this is a non-starter. -Steve I said before it doesn't break existing code. Like before, you can do everything the same way without a change in behavior and auto with a "*" is currently invalid.
Re: Allow Explicit Pointer for Auto Declaration
On Friday, 30 September 2016 at 03:07:41 UTC, Mike Parker wrote: On Friday, 30 September 2016 at 01:48:02 UTC, Jacob wrote: auto* pValue = expr; // still invalid code unless expr evaluate to a pointer type auto* pValue = // this is valid if expr is a ref It still requires the &, what it prevents is this situation: auto pValue = expr; // wanted pointer, expr evaluates to non-ptr value through change of code or simply forgetting "&" So no code should be broken, you can do everything the same way without a change in behavior and auto with a "*" is currently invalid. Basically how it works in C++: http://ideone.com/TUz9dO You could forget the * just as easily as the &. Easier to notice and to check whether the type is a pointer.
Re: Allow Explicit Pointer for Auto Declaration
On Friday, 30 September 2016 at 00:05:45 UTC, Steven Schveighoffer wrote: On 9/29/16 7:42 PM, Jacob wrote: Was wondering if this feature could be implemented, right now auto needs to be written like this: auto pValue = someFunctionReturnsRef(); // forgot '&', still valid // makes a copy when we didn't want one The feature would make the code look like this: auto* pValue = someFunctionReturnsRef(); // error expecting pointer We don't accidentally make a copy when we wanted a pointer. C++ has a similar semantic for it's auto. Hm... I'm not familiar with C++ auto, but C++ does have local references. D does not. I'm not sure if you are asking for the syntax specified, or asking for the original line to be treated like the specified syntax. The latter absolutely is not going to happen, because that breaks valid code. Even if we added: auto* pValue = expr; I don't see why this is more advantageous than: auto pValue = -Steve auto* pValue = expr; // still invalid code unless expr evaluate to a pointer type auto* pValue = // this is valid if expr is a ref It still requires the &, what it prevents is this situation: auto pValue = expr; // wanted pointer, expr evaluates to non-ptr value through change of code or simply forgetting "&" So no code should be broken, you can do everything the same way without a change in behavior and auto with a "*" is currently invalid. Basically how it works in C++: http://ideone.com/TUz9dO
Allow Explicit Pointer for Auto Declaration
Was wondering if this feature could be implemented, right now auto needs to be written like this: auto pValue = someFunctionReturnsRef(); // forgot '&', still valid // makes a copy when we didn't want one The feature would make the code look like this: auto* pValue = someFunctionReturnsRef(); // error expecting pointer We don't accidentally make a copy when we wanted a pointer. C++ has a similar semantic for it's auto.
Re: sending shared pointer to struct. message type mismatch
On Thursday, 21 April 2016 at 17:33:32 UTC, ag0aep6g wrote: On 21.04.2016 19:10, jacob wrote: I was going to suggest either sending a `shared(TS*)` or receiving a `shared(T)*`. But it looks like you can't send a shared pointer. When I tried, it got turned into a unshared-pointer-to-shared on the way. Oh that tricky "shared" keyword... Thank you! http://pastebin.com/YkZ3YzKG fixed version here
sending shared pointer to struct. message type mismatch
Hello!
I try to send shared pointer to struct:
[code]
import std.stdio;
import std.concurrency;
shared struct S(T, uint M)
{
T[M] x;
}
shared struct M
{
int x;
}
private void runner(T)()
{
shared(T*) s = receiveOnly!(shared(T*))();
writeln(s.x.length);
writeln(s.x[0]);
send(thisTid, true);
}
int main(string[] argv)
{
alias S!(M, 2) TS;
alias shared(TS*) PS;
Tid runnerTid = spawn(!(TS));
auto s = new shared(TS);
s.x[0] = M(42);
send(runnerTid, s);
bool ok = receiveOnly!bool();
return 0;
}
[/code]
But after evaluating line "shared(T*) s =
receiveOnly!(shared(T*))();" I get an exception:
"First-chance exception: std.concurrency.MessageMismatch
Unexpected message type: expected 'shared(S!(M, 2u)*)', got
'shared(engine.S!(M, 2u).S)*' at std\concurrency.d(224)"
How can I pass shared pointer to "runner" thread correctly?
trying to implement lock-free fixedsize queue
I try to implement chunk (something like lock-free fixedsize
queue)
--
import core.atomic;
shared struct Chunk(T, uint N)
{
shared T[N] data;
shared uint count;
shared uint queueCounter;
@property uint capacity() { return N; }
@property uint count() { return count; }
@property bool full() { return count == N; }
void append(shared T value)
{
atomicOp!("+=")(queueCounter, 1);
while(1)
{
uint c = count;
if(cas(, c, c + 1))
{
data[c] = value;
atomicOp!("-=")(queueCounter, 1);
break;
}
}
}
bool waitAll()
{
if(!full())
{
return false;
}
while(0 != queueCounter)
{
}
return true;
}
}
--
And call it like:
--
import std.parallelism;
struct S
{
bool dirty;
int time;
int[16] data;
}
int main(string[] argv)
{
const uint N = 14344;
shared Chunk!(S, N) ch;
foreach(i; taskPool.parallel(std.range.iota(N), 10))
{
shared S item;
item.time = i;
ch.append(item);
}
while(!ch.waitAll()) {}
// DONE
return 0;
}
--
It works fine with N == 14343, but fails without any message with
14344 (value depends on computer).
Why does program fail?
Am I doing correct CAS append?
Re: DIP74 - where is at?
On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload wrote: On Monday, 12 October 2015 at 16:56:27 UTC, Jacob wrote: I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that. Maybe you should take a break from programming for a while and work on your attitude? While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something! Dude you are kind of being a jerk. He's just arguing against, rather passionately, a design decision he thinks is poor. It values no one if individuals remain quiet and conform. Certainly not the leadership. What you see as arrogance is really just passion. Passion or not, "If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad." That statement shows a lot of arrogance. It he not really just saying "I have no clue if X is true, but since I don't know, I'll just assume it's false and assume you are wrong.". That's not very logical. Why wouldn't he just as well assume X is true? The fact is, he can't and shouldn't make such statements about X if he has no "evidence" about it. Instead, wouldn't the proper approach be to discuss, learn, and share what one things in a positive way so everyone can learn about X and reach a more intelligent understanding of it? Hilter was very passionate too, are you saying he was right?
Re: DIP74 - where is at?
On Tuesday, 13 October 2015 at 18:13:33 UTC, Ice Cream Overload wrote: On Tuesday, 13 October 2015 at 12:16:26 UTC, Jacob wrote: On Monday, 12 October 2015 at 19:35:33 UTC, Ice Cream Overload wrote: [...] Passion or not, "If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad." That statement shows a lot of arrogance. It he not really just saying "I have no clue if X is true, but since I don't know, I'll just assume it's false and assume you are wrong.". That's not very logical. Why wouldn't he just as well assume X is true? The fact is, he can't and shouldn't make such statements about X if he has no "evidence" about it. Instead, wouldn't the proper approach be to discuss, learn, and share what one things in a positive way so everyone can learn about X and reach a more intelligent understanding of it? Hilter was very passionate too, are you saying he was right? Since you brought up the Hilter reference, it's useful to mention that he was successful because people blindly followed him and his actions... But really...do we always have to resort to Hitler references when discussing disagreements? Seems very cliche. It's only cliche if you aren't interested in the truth. It doesn't matter if I used Hilter or any other person that was "passionate" but wrong. Hilter is just the greatest example and most obvious example. If you actually understand the issue, you would realize it has nothing to do with Hilter.
Re: DIP74 - where is at?
On Monday, 12 October 2015 at 07:21:58 UTC, deadalnix wrote: On Monday, 12 October 2015 at 06:02:47 UTC, Andrei Alexandrescu wrote: There are not considered because DIP25 is "simpler" and you and Walter "like it". As long as nothing changes here, there is really no point in wasting my time. That is a fair assessment. Basically I believe DIP25 is good language design, and I have evidence for it. The evidence you showed failed to convince me the design is a hack, and yelling at me is unlikely to help. Please decide as you find fit. At some point it is clear that several language designers will disagree on estimating the quality of something. If you are wondering why I'm inflammatory, here you go. You are pulling me the old prove a negative trick. You have good evidence that DIP25 is good design ? Good, because I have none. And that's my proof. As long as I have no evidence that DIP25 is good, DIP25 is bad. I've noticed that you seem to be quite arrogant. Usually it is a result of ignorance. Your statement basically proves that. Maybe you should take a break from programming for a while and work on your attitude? While you have no proof of this, If you do a little soul searching you'll find that the world doesn't revolve around you. Put down your toys and get out of the sandbox and you might learn something!
D run-time interpretation
There are many programs out there that use some sort of scripting capabilities. I've been wanting to write an app that exposes a scripting like environment D, lua, or some other fast language to the user. But there are two requirements: 1. The user has access to all objects created in app. e.g., if I create a class X in the app then the user can instantiate X in the script without having to recreate it. (the script then, is sort of an extension of the app) I don't mind actually having to expose X to the script, but it should be easy. 2. It should be fast. When it is "recompiled" it shouldn't take more than a few seconds. It also shouldn't require a re-initialization of everything. Can D do this easily?
Re: D run-time interpretation
On Tuesday, 6 October 2015 at 20:02:48 UTC, Jonathan M Davis wrote: On Tuesday, 6 October 2015 at 19:42:08 UTC, Jacob wrote: There are many programs out there that use some sort of scripting capabilities. I've been wanting to write an app that exposes a scripting like environment D, lua, or some other fast language to the user. But there are two requirements: 1. The user has access to all objects created in app. e.g., if I create a class X in the app then the user can instantiate X in the script without having to recreate it. (the script then, is sort of an extension of the app) I don't mind actually having to expose X to the script, but it should be easy. 2. It should be fast. When it is "recompiled" it shouldn't take more than a few seconds. It also shouldn't require a re-initialization of everything. Can D do this easily? You know, you can use D as a scripting language. On Linux, you do something like put #!/bin/rdmd at the beginning of the file, mark it is executable, and then you can run it. I don't know what you need to put on the top to make it work on Windows. These days, I write most of my scripts in D. - Jonathan M Davis But this isn't what I want, only part. Essentially I want to write an app that allows the user to "inteface" with the internals of the app, to control things and such. Half the app is graphics and provides the backbone, sets up the graphics, deals with all that mess that the user doesn't need to deal with. The user, though, can control specific things such as the colors, objects, and such in the graphics scene. But instead of providing relatively static settings for the user(mess with sliders and such), I would like them to be able to specify what they want in "code". e.g., User script code: Graphics.Objects["Ship"].X = 10*cos(time); Graphics.Objects["Ship"].Y = 10*sin(time); ... So the user has the ability to access the "internals". Here Graphics is a sort of container for all the graphics, Objects is a map of all the objects in the scene. But ultimately the code should be "compiled" in to the backbone of the app so it runs as fast as possible(not re-interpreted each scene). One can think of it like this: The user provides code, the code is compiled as a function and the function called by the app. As long as one can link up the objects this should not be difficult. If I were to do this by hand I'd have to write or use an interpreter or compiler(probably too slow) and provide a mapping of all the objects I want to expose(I'll have to "export" them from the app). I could use something like LuaD, as I think it has the ability to parse strings as lua code, and the lua code can directly interface with the app. So this would not be that difficult to implement. The questions here are, is it fast enough and can it provide the simplicity I'd want. I think C# has some type of compiler that allows one, in real time, to re-compile source code chunks and execute them as part of the program(not as separate entities that have no access to the underlying code). This process would work but surely is too slow: 1. Treat the script code as pure D code. 2. Provide object references(pointers) to the objects I want to expose to the D code(as function arguments or through a lookup table or whatever) 3. compile the code into a dll. 4. Call the code in the dll per frame(or how ever I need to). This would work great except the recompiling part and dll interfacing would surely be too slow. Since the user code could be modified often(modify a line, recompile), I need the changes to happen as fast as possible. If one wanted to modify the above code to Graphics.Objects["Ship"].X = 10*sin(time); Graphics.Objects["Ship"].Y = 10*cos(time); I don't want the user to wait 5 mins while the app does all the work listed. Even, if it's 50 seconds it's still too slow. I'd also like to use D as the scripting language since it would probably flow better(although, maybe lua and python could work too). My app essentially has a visual scene representing the 3d graphics, and a "script editor" that allows the user to interact and modify the scene using code. The scripting is crucial as it what makes the app what it is.
Re: GuiDub
On Tuesday, 29 September 2015 at 07:53:12 UTC, ponce wrote: On Tuesday, 29 September 2015 at 05:17:42 UTC, Jacob wrote: Does anyone actually maintain all this or use it? Cause surely I shouldn't be getting errors like this? I have about 50 packages in my dub.json and they all came from copying the dependency directly(so no mistake on my part). Some advices: - do not use the "umbrella" packages like "dplug" but rather the sub-packages like "dplug:dsp". This will reduce the number of dependencies. - cut the number of dependencies to the minimum. For example you have freeimage AND imaged who overlap quite a bit. More dependencies = more problems. Add them one by one IF they are needed and after evaluating them. - before relying on a dependency, check that it looks maintained, has travis-ci integration, and build. Without editing anything, you can do: dub test thatpackage anywhere and it should download and build the tests. - if given the choice, use a derelict binding vs a statically linked dependency. This will make things a tad easier. I was under the impression that dub was sort of the "god particle" for building D apps. That it would take care of all this mess. It surely doesn't and hasn't made my life easier! Everyone says to use dub, so I use it and can't even get the packages to import properly. Dub should handle the discrepancies, not me! I'm not smart enough to be able to deal with dependencies of dependencies of dependencies of dependencies with all kinds of versioning issues at each step of the way. Sounds like dub is just a different dll hell.
Re: GuiDub
On Tuesday, 29 September 2015 at 03:28:41 UTC, Rikki Cattermole wrote: On 29/09/15 3:47 PM, Jacob wrote: Idea: A gui app for dub that you run, it downloads the package info from the repository and you can select a project or create a new one and it will automatically add or remove dependencies? I'm having to browse the repository then manually add the dependencies to the dub.json file... so old school! Also, the app could provide documentation, and other resources(tutorials, etc) related the packages. An app probably could be created in a few days and would make the experience more enjoyable. I'd create it myself but I'm busy at the moment, and it would probably take a big longer than someone more informed. Sounds like something an IDE can be used for. Could be integrated but not necessary. Something that can maintain and make it easier to remove, update, and all that. doing it by hand is a pain when you have a lot of libraries added. Also: Error executing command build: Root package test1 contains reference to invalid package gtk-d Yet I used exactly what the dub repository says to use.
Re: GuiDub
On Tuesday, 29 September 2015 at 04:01:18 UTC, Jacob wrote:
On Tuesday, 29 September 2015 at 03:28:41 UTC, Rikki Cattermole
wrote:
On 29/09/15 3:47 PM, Jacob wrote:
Idea:
A gui app for dub that you run, it downloads the package info
from the
repository and you can select a project or create a new one
and it will
automatically add or remove dependencies?
I'm having to browse the repository then manually add the
dependencies
to the dub.json file... so old school!
Also, the app could provide documentation, and other
resources(tutorials, etc) related the packages.
An app probably could be created in a few days and would make
the
experience more enjoyable. I'd create it myself but I'm busy
at the
moment, and it would probably take a big longer than someone
more informed.
Sounds like something an IDE can be used for.
Could be integrated but not necessary. Something that can
maintain and make it easier to remove, update, and all that.
doing it by hand is a pain when you have a lot of libraries
added.
Also:
Error executing command build:
Root package test1 contains reference to invalid package gtk-d
Yet I used exactly what the dub repository says to use.
also
Error executing command build:
Root package test1 contains reference to invalid package
derelict-gl3
Error executing command build:
Root package test1 contains reference to invalid package
derelict-sdl2
Error executing command build:
Root package test1 contains reference to invalid package gfm:math
Error executing command build:
Root package test1 contains reference to invalid package scid
Error executing command build:
Root package test1 contains reference to invalid package
derelict-util
Error executing command build:
Root package test1 contains reference to invalid package gl3n
etc..
It seems like all the packages are invalid!! WTH is going on? I
thought dub was suppose to be easy and work?
Does anyone actually maintain all this or use it? Cause surely I
shouldn't be getting errors like this? I have about 50 packages
in my dub.json and they all came from copying the dependency
directly(so no mistake on my part).
{
"name": "test1",
"description": "A minimal D application.",
"copyright": "Copyright © 2015, Jacob",
"authors": ["Jacob"],
"dependencies": {
"gfm:math": "~>3.0",
"dplug": "~>1.1.34",
"cerealed": "~>0.6.2",
"imageformats": "~>5.1.0",
"pathlib": "~>0.3.0",
"enumap": "~>0.4.0",
"mintegrated": "~>0.2.1",
"speech4d": "~>0.1.0",
"jsonizer": "~>0.5.1",
"dgame": "~>0.6.3",
"desil": "~>0.2.1",
"derelict-imgui": "~>0.7.0",
"derelict-sfml2": "~>3.0.1",
"derelict-steamworks": "~>0.0.3",
"derelict-util": "~>2.0.3",
"derelict-lua": "~>1.2.2",
"derelict-ode": "~>1.1.2",
"derelict-allegro5": "~>0.0.2",
"derelict_extras-mantle": "~>0.2.0",
"derelict_extras-fann": "~>4.0.1",
"derelict_extras-sndfile": "~>2.0.0",
"derelict_extras-bass": "~>2.0.0",
"derelict-cl": "~>2.0.0",
"derelict-enet": "~>2.0.0",
"derelict-assimp3": "~>1.0.1",
"derelict-ft": "~>1.0.2",
"m3d": "~>0.1.4",
"derelict-sass": "~>2.0.0",
"derelict-glfw3": "~>1.1.0",
"derelict-ogg": "~>1.0.1",
"derelict-vorbis": "~>1.0.1",
"wave-d": "~>1.0.2",
"derelict-physfs": "~>1.0.0",
"derelict-il": "~>1.0.0",
"directx-d": "~>0.9.1",
"freeimage": "~>1.0.1+3.16.0",
"clfft": "~>0.1.1",
"lock-free": "~>0.1.1",
"derelict-alure": "~>1.0.0",
"dsfml": "~master",
"std_event": "~master",
"derelict_extras-glib": "~master",
"netstack": "~master",
"luad": "~master",
"three-d": "~master",
"grape": "~master",
"civge": "~master",
"nitro": "~master",
"nitro-gen": "~master",
"process-stats": "~master",
"llvm-d": "~master",
"bzip2": "~>0.1.0",
"simd": "~>0.0.2",
"cassowary-d": "~>0.0.1",
"dcheck": "~>0.1.0",
"d-beard": "~>2.0.0",
"geneticd": "~>0.1.1",
"orderedmap": "~>0.0.2",
"stochastic": "~>0.3.0",
"maybe-d": "~>0.0.1",
"pack-d":
GuiDub
Idea: A gui app for dub that you run, it downloads the package info from the repository and you can select a project or create a new one and it will automatically add or remove dependencies? I'm having to browse the repository then manually add the dependencies to the dub.json file... so old school! Also, the app could provide documentation, and other resources(tutorials, etc) related the packages. An app probably could be created in a few days and would make the experience more enjoyable. I'd create it myself but I'm busy at the moment, and it would probably take a big longer than someone more informed.
Re: How to setup mono-D for shared libraries?
On Wednesday, 23 September 2015 at 04:34:45 UTC, Rikki Cattermole wrote: On 23/09/15 8:20 AM, Jacob wrote: How do I setup mono-D for creating shared libraries and including them into other projects? When I drag the .d files to create the library from, which is not my own, I get undefined references. I have the lib files, which are a bunch of separate libs, that I want to include into one big lib. Once that's done I want to include that lib into another project. I'd rather not modify si.ini. Are there any tutorials for getting started with Mono-D? (setup, not coding) Well you could go the route of dub, which configuration files can be loaded directly into it as a project. To create the library, what do I do? 'dub init myLib' then delete app.d, and then add all the library.d files? Then what? Where do I tell it to find the .lib files without adding them to sc.ini? Do I just mess with dub.json to and add all the proper build options to get both the lib and the dependent apps working or are there other steps I'm missing?
How to setup mono-D for shared libraries?
How do I setup mono-D for creating shared libraries and including them into other projects? When I drag the .d files to create the library from, which is not my own, I get undefined references. I have the lib files, which are a bunch of separate libs, that I want to include into one big lib. Once that's done I want to include that lib into another project. I'd rather not modify si.ini. Are there any tutorials for getting started with Mono-D? (setup, not coding)
