Re: DIP69 - Implement scope for escape proof references
On 12/10/2014 8:56 PM, deadalnix wrote: On Thursday, 11 December 2014 at 03:27:08 UTC, Walter Bright wrote: I disagree. It's critical for chaining one function to the next. I one can't return, one can't chain. I guess I'm not seeing the problem.
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
Could we come back to the topic ? :)
Re: DIP69 - Implement scope for escape proof references
On 2014-12-05 15:27:41 +, Steven Schveighoffer said: On 12/4/14 4:24 AM, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. Can we take a step back here? I read many people's comments and I understand only about half of them. Can someone who knows what this new feature is supposed to do give some Ali Çehreli-like description on the feature? Basically, let's strip out the *proof* in the DIP (the how it works and why we have it), and focus on how it is to be used. I still am having a hard time wrapping my head around the benefits and when to use scope, scope ref, why I would use it. I'm worried that we are adding all this complication and it will confuse the shit out of users, to the point where they won't use it. -Steve This is exactly why this feature should be default behavior with compiler warnings generated when things escape scope. The basic idea is that most things should be on the stack and go away when the stack goes away. The proposal codifies how the compiler should infer that references to variables which are to be placed on the stack are not escaping their scope. The benefit is that the GC has to do *way* less work from what it has to do now for most of the use cases of D. -Shammah
Re: Can we make Throwable an interface?
On Tuesday, 9 December 2014 at 18:00:05 UTC, Sean Kelly wrote: All the stack tracing stuff is wired through Throwable, so some duplication may need to occur if it were changed to an interface. I can think of two ways to solve this: 1. rename the current Throwable (to e.g. ThrowableBase) and make it inherit the new Throwable interface. 2. Move the relevant functionality to a mixin template that is used in a limited set of base exception classes. Lars
Re: Can we make Throwable an interface?
On Tuesday, 9 December 2014 at 17:06:45 UTC, Dmitry Olshansky wrote: Then we could use interfaces as "tags" for exceptions and catch using one of many interfaces an exception has. I think that is an excellent idea! I have looked a bit at boost::exception, and wanted for a while to incorporate something similar into DIP33. It has two important features: Firstly, it allows semantic tagging of exceptions, which is implemented in C++ by means of multiple (virtual) inheritance. Your suggestion of using interfaces for this would fit the bill nicely, I think. For interfaces that have extra functions, we could supply standard implementations of those functions as mixin templates for when users don't want to implement those functions themselves. Secondly, boost::exception allows for transport of arbitrary data to the catch site, and importantly, supplying additional data as the exception propagates up the call chain. (E.g., the lowest-level I/O function only has a file descriptor and can only provide an errno code, so the file name must be supplied at a higher level, e.g. in std.stdio.File. Furthermore, the file was opened in some context, e.g. "read image file", which may also be useful to know at the catch site.) I'm not sure what is the best way to achieve this in D, but one option is to use an (associative?) array of Variants. Consider DIP33: http://wiki.dlang.org/DIP33 The 2 problems it had were: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. 2. Single hierarchy has some appeal but it doesn't allow to catch on similar classes that do not inherit from the same base class. Basically there are many ways to view similarities of excpetions and single hierarchy fails to address that. I consider (2) the biggest problem by far. The enum solution doesn't preclude extension by subclassing – in fact, that was the main purpose of the "unknown" constant in the "Kind" enums. Lars
Checksums of files from Downloads
I wanted to join D community, but I realized that I even cannot install tools from the site securely. (Correct me if I wrong.) To dlang.org maintainers: I trust you but I don't trust man-in-the-middle. So, could you at least provide checksums (e.g. sha1) for all files which are available on the following pages, please. http://dlang.org/download.html http://code.dlang.org/download Also It would be great if you: 1) install good (not self-signed) SSL certificate to allow visitors use HTTPS; 2) sign all *.exe files provided in download sections.
Re: DIP69 - Implement scope for escape proof references
On 2014-12-11 07:03:58 +, Shammah Chancellor said: On 2014-12-04 09:24:13 +, Walter Bright said: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. I like the basics of the proposal and I think it's the right direction. HOWEVER, I strongly believe that function arguments should be scoped by default and `impure` when they take reference which they will keep. -Shammah Also, more feedback. I would suggest that scope variable are the default inside of functions as well as parameters. Using escape analysis, instead of them being errors, make them warnings and implicitly make them impure. -Shammah
Re: DIP69 - Implement scope for escape proof references
On 2014-12-04 10:00:28 +, Walter Bright said: On 12/4/2014 1:51 AM, eles wrote: On Thursday, 4 December 2014 at 09:25:11 UTC, Walter Bright wrote: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. Making it implicit and requiring an explicit "escape" for un-scoped variables? Was afraid that would break too much code. No, this is super important. Break it all! This kind of change will significantly increase the performance of D code by almost eliminating GC thrashing. Having to type scope EVERYWHERE will make it unused and therefore unusable in other people's libraries. -Shammah.
Re: DIP69 - Implement scope for escape proof references
On 2014-12-04 09:24:13 +, Walter Bright said: http://wiki.dlang.org/DIP69 Despite its length, this is a fairly simple proposal. It adds the missing semantics for the 'scope' storage class in order to make it possible to pass a reference to a function without it being possible for it to escape. This, among other things, makes a ref counting type practical. It also makes it more practical to use other storage allocation schemes than garbage collection. It does not make scope into a type constructor, nor a general type-annotation system. It does not provide an ownership system, though it would complement one. I like the basics of the proposal and I think it's the right direction. HOWEVER, I strongly believe that function arguments should be scoped by default and `impure` when they take reference which they will keep. -Shammah
Re: DIP69 - Implement scope for escape proof references
On Thursday, 11 December 2014 at 03:30:07 UTC, Walter Bright wrote: If you want data to 'escape' from r.front, then it shouldn't be marked as scope. Definitely, using scope successfully will require some rethinking of how code is written. Allowing or prohibiting escaping of r.front in that example depends on definition of mapped range. There is nothing to "rethink" about it - case is almost identical to const+inout.
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 10:59:17 UTC, ketmar via Digitalmars-d wrote: > that is absolutely nonsense, you *CAN'T* "recover" from > invalid code. > that is the fact. fact: Earth is not a sphere. fact: you > can't > automatically recover from invalid code. That sounds much like an opinion, a lot less like a fact. If you are willing to convince people, please provide some evidence, aside from another unrelated fact. the ones who believes that recovery covers most of the cases should bring proofs, not me. it's obvious that guessing on invalid input is unreliable. Fine, I don't have the hard proof at hand, since my compilation-error state programs don't tend to go into version control systems. Perhaps I can track them too if such statistics can be shown to have some real value. On the other hand, I'm fine with the current state, and without evidence from your side, it's not going to change. So the inversion of who should bring proofs is also a false claim.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 11 December 2014 at 03:27:08 UTC, Walter Bright wrote: I disagree. It's critical for chaining one function to the next. I one can't return, one can't chain.
Re: struct default constructor, unions and bizaro behavior.
On Thursday, 11 December 2014 at 03:33:01 UTC, Walter Bright wrote: Please file a bug report. I did, kenji told me that this is as per design and expected. I don't think this design make any sense, so u bring the thing here :)
Re: DIP69 - Implement scope for escape proof references
On 12/9/2014 8:34 PM, Dicebot wrote: But as far as I understand the spec it will result it this code failing too: auto r = ["aaa", "bbb", "ccc"].map!foo; // should compile but will fail because foo returns scope ref: string s = r.front; What I mean is that in current proposal it is impossible to transfer scope information down the call chain - either function always returns scope ref or never. Which implies the necessity of something like `auto scope`... If you want data to 'escape' from r.front, then it shouldn't be marked as scope. Definitely, using scope successfully will require some rethinking of how code is written.
Re: struct default constructor, unions and bizaro behavior.
On 12/10/2014 1:57 PM, deadalnix wrote:
struct S {
union {
T1 t1;
T2 t2;
}
T3 t3;
}
T1 a1;
T3 a3;
S(a1, a3);
This is erroring because t1 is set twice. It turns out that the
second parameter of the struct map to t2 rather than t3.
This behavior do not make any sense, ever. Why is that the
default ?
Please file a bug report.
Re: DIP69 - Implement scope for escape proof references
On 12/9/2014 10:43 PM, deadalnix wrote: On Wednesday, 10 December 2014 at 05:23:29 UTC, Walter Bright wrote: On 12/8/2014 3:21 PM, deadalnix wrote: On Monday, 8 December 2014 at 21:16:36 UTC, Walter Bright wrote: A 'scope ref' parameter may not be returned as a 'ref' or a 'scope ref'. It can safely be returned if you consider its lifetime as the intersection of the lifetime of the function's parameter. The only purpose to a 'scope ref' parameter is to say it isn't being returned. 'ref' itself does not escape in any way other than by returning. That is a completely useless feature. Also, you want to have scope return for container like thing. I disagree. It's critical for chaining one function to the next.
Re: DIP69 - Implement scope for escape proof references
On Thursday, 11 December 2014 at 00:48:32 UTC, bearophile wrote: deadalnix: That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases). What syntax do you suggest to use if you want to extend it that way later? Bye, bearophile scope[symbol_name] would get the same lifetime as symbol_name for instance. This is only a proposal, I'm not convinced that this is strictly necessary, and, as long as we know we can add it if needed, we are good.
Re: Do everything in Java…
On 12/10/2014 10:28 AM, H. S. Teoh via Digitalmars-d wrote: Yeah, the compiler cannot instantiate the template without access to the full body. It *could*, though, if we were to store template body IR in object files, perhaps under specially-dedicated object file sections. It wouldn't prevent reverse-engineering (which is moot anyway when templates are involved), but it *would* work as an "opaque" library interface file. Storing it as body IR accomplishes nothing practical over storing it as source file, i.e. .di files.
Re: DIP69 - Implement scope for escape proof references
deadalnix: That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases). What syntax do you suggest to use if you want to extend it that way later? Bye, bearophile
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 22:20:37 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 10 December 2014 at 22:05:10 UTC, deadalnix wrote: That is completely off topic. this is a function parameter, you can return scope, and you don't need to know who own the container for that to work. You have many scopes, if two different scopes pass in "horses" to a function in a recursive chain then you need to know which horse the returned "leg" belongs to… But by all means… go ahead if you think it is off topic. (it isn't) It is always safe to consider scopeness of the retrun value (if marked scope) as being the intersection of the lifetime of parameters. That should cover most bases, and we can still extends later if this is too limited (I suspect it is ok for most cases).
Re: Do everything in Java…
On Thu, Dec 11, 2014 at 10:17:29AM +1100, Daniel Murphy via Digitalmars-d wrote:
> "H. S. Teoh via Digitalmars-d" wrote in message
> news:mailman.3042.1418240846.9932.digitalmar...@puremagic.com...
>
> >Also, storing a full AST is probably overkill -- lexing and parsing
> >the source generally doesn't take up too much of the compiler's time,
> >so we might as well just use the source code instead.
>
> Exactly
>
> >What makes it more worthwhile is if the AST has already been somewhat
> >processed, e.g., constants have been folded, etc.. Probably after
> >semantic1 and semantic2 have been run (though I'm not sure how far
> >one can get if the template hasn't been instantiated yet).
>
> Not very far at all.
>
> >This way, work that has already been done doesn't need to be repeated
> >again.
>
> When it's templates that haven't been instantiated, you haven't done
> any of the work yet.
Well, I was thinking more of how far we *could* go, rather than how far
dmd *actually* goes currently (which is nowhere at all, since all it
does right now is to parse the template, until you instantiate it).
But I suspect you can't go too far -- at least, not if the code actually
depends on the template arguments in any meaningful way. As an extreme
case, Dicebot's example is one where you can't go anywhere at all:
auto myFunc(string code)() {
return mixin(code);
}
On the other extreme, you have templates that really shouldn't be
templates because they don't actually depend on their template
arguments:
auto myFunc(A...)() {
return 1+2*3/4-5;
}
You could basically already compile the entire function without caring
for the template arguments.
Real-life use cases, of course, generally fall somewhere in between
these two extremes. So I'd expect they would have some parts that cannot
be processed any further than parsing, and other parts that can
ostensibly go quite far, depending on how independent they are of the
template arguments.
Hmm, on second thoughts, this seems to be an interesting direction to
explore, because template code that you *can* get quite far on, also
represents code that is quite independent of template arguments, which
means a large part of them should be identical across different template
arguments. That makes them candidates for being merged, which would help
reduce template bloat. By attempting analysis of template bodies, the
compiler might be able to automatically identify these
"mostly-independent" pieces of code, and perhaps apply some strategies
for automatic code merging.
T
--
Windows 95 was a joke, and Windows 98 was the punchline.
Re: Do everything in Java…
On 10 Dec 2014 18:30, "H. S. Teoh via Digitalmars-d"
wrote:
>
> On Wed, Dec 10, 2014 at 06:15:48PM +, Paulo Pinto via Digitalmars-d wrote:
> > On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
> > Digitalmars-d wrote:
> [...]
> > >In D, this should be akin to:
> > >
> > >// Package header
> > >module functions;
> > >void Swap(T)(out T x, out T y);
> > >
> > >// Package body
> > >module functions;
> > >void Swap(T)(out T x, out T y)
> > >{
> > > // Implementation
> > >}
> > >
> > >// Importing it
> > >import functions : Swap;
> > >void main()
> > >{
> > > int x = 1;
> > > int y = 2;
> > > Swap(x, y);
> > >}
> > >
> > >Iain
> >
> > But the current object model doesn't support it, right?
> >
> > At least my understanding is that you need to have the full body
> > visible.
> [...]
>
> Yeah, the compiler cannot instantiate the template without access to the
> full body. It *could*, though, if we were to store template body IR in
> object files, perhaps under specially-dedicated object file sections. It
> wouldn't prevent reverse-engineering (which is moot anyway when
> templates are involved), but it *would* work as an "opaque" library
> interface file.
>
So long as it's instantiated somewhere in the provided by the library
object shipped with the module interface, then all symbols will
resolve at link-time.
I can't imagine Ada being much different at the object level. To even
quote from a book of Ada that covers information hiding in a section
(changing the function names to be relevant for this discussion).
"""
In the above example, the full definition of Swap can be indeed
deferred until the package body. The reason, of course, is that
nearly all current machines have a uniform addressing structure, so
that an access value always looks the same regardless of what it is
designating.
To summarise, the logical interface corresponds to the visible part;
the physical interface corresponds to the complete package
specification, that is, to both the visible part and the private part.
As long as a package specification is not changed, the package body
that implements it can be defined and redefined without affecting
other units that use this specification as an interface to the
package. Hence it is possible to compile a package body separately
from its package specification.
"""
Now if you swap 'package specification' for 'function/template
signature', you've got yourself more or less describing how D
modules/packages work.
Iain.
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
"Stefan Koch" wrote in message news:smlizntnnsppmzsdc...@forum.dlang.org... I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently. DMD is where the frontend's development takes place, and the frontend is shared with GDC and LDC. I don't think they maintain significant frontend patches on top of DMD's frontend.
Re: Do everything in Java…
On 12/10/2014 4:15 AM, Paulo Pinto wrote: I prefer the model used by the referred languages, where binary libraries and metadata is used, instead of the C toolchain model. For example, just shipping the .TPU/.DCU libraries in the Object Pascal world. If the metadata had enough info in it to do inlining, it might as well be the source code.
Re: Do everything in Java…
"H. S. Teoh via Digitalmars-d" wrote in message news:mailman.3042.1418240846.9932.digitalmar...@puremagic.com... Also, storing a full AST is probably overkill -- lexing and parsing the source generally doesn't take up too much of the compiler's time, so we might as well just use the source code instead. Exactly What makes it more worthwhile is if the AST has already been somewhat processed, e.g., constants have been folded, etc.. Probably after semantic1 and semantic2 have been run (though I'm not sure how far one can get if the template hasn't been instantiated yet). Not very far at all. This way, work that has already been done doesn't need to be repeated again. When it's templates that haven't been instantiated, you haven't done any of the work yet.
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
On Wed, Dec 10, 2014 at 10:47:45PM +, Brad Anderson via Digitalmars-d wrote: > On Wednesday, 10 December 2014 at 18:39:39 UTC, Stefan Koch wrote: > >On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy wrote: > > > >>DMD's inliner might be a good place to start. There is a lot to be > >>done there. > > > >I am sure that would be interesting. But I gather PR's for DMD are > >not merged too frequently. > > DMD pull requests actually don't languish for too long unless it's a > controversial or complicated pull request. DMD gets and merges more > pull requests than Phobos. Yeah, I've submitted relatively simple PRs for dmd, and they usually get merged within a few days, sometimes in a day if it's trivial. T -- Verbing weirds language. -- Calvin (& Hobbes)
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 22:34:50 UTC, Dicebot wrote:
Then please show something that actually helps and is
applicable to D template system. There is not much value in
vague references with "imagine rest yourself" flavor.
To be specific I am interested how would it handle pattern like
this (very common for D code and not present in Ada at all
AFAIK):
void foo(T)(T t)
{
mixin(generator!T());
}
What exactly would one put in IR for plain uninstantiated foo?
Maybe you should agree on what a high level IR is first? Here are
some alternatives:
1. Regular IR: A high level IR basically is a flattened AST where
you do substitutions, perform partial evaluation and strip out
symbols. In a high level IR that supports templating you might
preserve several partial instances using incomplete types. If it
is non-transformable to begin with… then the compiler won't
transform it.
2. Search optimizing IR: What the compiler does could be based on
heuristics and statistical information. Think term rewriting
systems working on "possible programs" with heuristics as a guide
so you build up a database of precompiled segments for "possible
programs" and produce guiding datastructures that speed the
optimization search. The basic idea being that you spend a lot of
time precompiling libraries, and cut down on compiling concrete
instances of programs.
3. Generating IR: The compiler could build JITable compiler code
for templates, e.g. the templates are stored as a VM program that
is executed by the compiler and is allowed to make calls into the
compiler code. Basically "compile-time-functions" with inside
compiler know-how.
Re: Comparing Parallelization in HPC with D, Chapel, and Go
Sparsh Mittal: I am author of the paper "A Study of Successive Over-relaxation Method Parallelization Over Modern HPC Languages". The code has been made available for academic use at https://www.academia.edu/9709444/Source_code_of_Parallel_and_Serial_Red-Black_SOR_Implementation_in_Chapel_D_and_Go_Languages Questions and comments can be sent to my email address [although note that use of software does not imply support]. What compiler, compiler version, and compilation arguments did you use for the D code? (For such kind of benchmarks the DMD compiler is the wrong compiler to use). I have improved and made more idiomatic the serial version of the D code: http://dpaste.dzfl.pl/a6743f2eceda Bye, bearophile
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
On Wednesday, 10 December 2014 at 18:39:39 UTC, Stefan Koch wrote: On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy wrote: DMD's inliner might be a good place to start. There is a lot to be done there. I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently. DMD pull requests actually don't languish for too long unless it's a controversial or complicated pull request. DMD gets and merges more pull requests than Phobos.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 21:39:42 UTC, Paulo Pinto wrote:
That was just an example, I could have written lots of other
stuff.
Then please show something that actually helps and is applicable
to D template system. There is not much value in vague references
with "imagine rest yourself" flavor.
To be specific I am interested how would it handle pattern like
this (very common for D code and not present in Ada at all AFAIK):
void foo(T)(T t)
{
mixin(generator!T());
}
What exactly would one put in IR for plain uninstantiated foo?
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 21:59:57 UTC, deadalnix wrote: On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote: Simple, by dropping C based linker model as I state on my comment. Ho please, that is a salesman answer, not an engineer one. I was talking how the toolchains for other programming languages work. It is complete clear to me this wouldn't work for D, besides there are lots of more important areas to improve on. As a language geek that just lurks and works in other languages, I don't have anything to sell. -- Paulo
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 22:05:10 UTC, deadalnix wrote: That is completely off topic. this is a function parameter, you can return scope, and you don't need to know who own the container for that to work. You have many scopes, if two different scopes pass in "horses" to a function in a recursive chain then you need to know which horse the returned "leg" belongs to… But by all means… go ahead if you think it is off topic. (it isn't)
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 15:15:59 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote: That why i say they are linked. I don't think your way of stating it contradict what I said. scope allow for manipulation of data without owning them. Whatever the owner is (be it the stack frame or anything else) doesn't really matter here. It does when you return parts of it, like if you pass in a binary tree and return a node. Which you have to be able to do for the concept to make sense. When you solve issues in language design you should address the hard issues first, because the easy issues will then tend to resolve themselves if the design is good. If you start with "the low hanging fruit" you end up with pointless special casing… D is already in that landscape and should try hard not to sink deeper into the muddy waters. I posit that if you have a solution for ownership/retaining references then the solution for scope will come from this as a side-effect. That is completely off topic. this is a function parameter, you can return scope, and you don't need to know who own the container for that to work. Granted, the current proposal lack the horsepower to do so.
struct default constructor, unions and bizaro behavior.
struct S {
union {
T1 t1;
T2 t2;
}
T3 t3;
}
T1 a1;
T3 a3;
S(a1, a3);
This is erroring because t1 is set twice. It turns out that the
second parameter of the struct map to t2 rather than t3.
This behavior do not make any sense, ever. Why is that the
default ?
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote: Simple, by dropping C based linker model as I state on my comment. Ho please, that is a salesman answer, not an engineer one.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 19:24:17 UTC, Dicebot wrote: On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto wrote: The libraries contain the required metadata for symbol tables and code locations that need to be extracted into the executable/library. Package definition files contain the minimum information the compiler needs to know to search for the remaining information. Example, ... Example shows generics, not templates. Full blown template/mixin support is impossible without anything else but full source access in one form or another. That was just an example, I could have written lots of other stuff. - Paulo
Re: Can we make Throwable an interface?
10-Dec-2014 11:24, Kagamin пишет: On Tuesday, 9 December 2014 at 17:06:45 UTC, Dmitry Olshansky wrote: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. What's the problem? That you miss the point of standard exception hierarchy - that is client code shall not be concerned with 3-rd party exceptions of every library as long as 3rd parties use common hierarchy(s). A big problem is we can't catch based on enum or would have to rethrow. Another problem is that one hierarchy is too rigid and exceptions can be viewed from different angles (implementation-wise like WindowsException and semantic categories like PermissionException). When you add new functionality to std lib, you add an enum entry in the same pull request. Aye. And every program that had final switch on it fails. There is too many opportunities to break code with that. In contrast with interfaces one explicitly has open set of possible derived interfaces. 3rd party libraries define their specific exceptions and enums. Which is utter failure. If every MyFooBar library defines MyFooBar exception then the whole point of standard exceptions is moot. We degrade back to specific per library error codes, with a benefit that they are transported across stack frames. The point is to _catch_ based on common failure causes the same way across _any_ libraries. The 3rd parties are then free to provide more specific causes of say OsException or FormatException etc. which may then find their way into standard. So that all arithmetic libraries inherit Underflow and Overflow as needed in their custom exceptions, or even just use anonymous class and be done. This allows extension while keeping client's code simple. Unlike DIP33 where one cannot make FormatException grow custom enum flag for his own library _only_ thus requiring client code to _always_ deal with your custom exception explicitly. -- Dmitry Olshansky
Re: Can we make Throwable an interface?
On Wed, Dec 10, 2014 at 10:47:46PM +0300, Dmitry Olshansky via Digitalmars-d
wrote:
> 10-Dec-2014 11:20, Kagamin пишет:
> >On Tuesday, 9 December 2014 at 18:07:16 UTC, H. S. Teoh via
> >Digitalmars-d wrote:
> >>what is more interesting is "was this failure caused by permission
> >>error?".
> >
> >And what if it does?
> >You would create thousands of types and their cartesian products just
> >to check for one of them?
>
> There is no need for cartesian products.
> E.g.
> interface ConversionException { }
> interface Overflow : ConversionException {}
> interface Underflow : ConversionException {}
> ...
>
> Basically enum in DIP 33 expends to a set of dervied interfaces.
>
> Anyhow enums do not allow one to catch based on them which already
> makes them highly unusable.
[...]
Exactly, that's what makes interfaces a good solution to this. Enums are
also non-extensible, since once Phobos fixes the enum values, user code
cannot extend it, even if a user-defined Exception naturally falls under
one of the preexisting exception categories. Using interfaces would
allow users to leverage the existing exception hierarchy instead of
reinventing the square wheel every time.
T
--
This is not a sentence.
Re: Can we make Throwable an interface?
10-Dec-2014 11:20, Kagamin пишет:
On Tuesday, 9 December 2014 at 18:07:16 UTC, H. S. Teoh via
Digitalmars-d wrote:
what is more interesting is "was this failure caused by permission
error?".
And what if it does?
You would create thousands of types and their cartesian products just to
check for one of them?
There is no need for cartesian products.
E.g.
interface ConversionException { }
interface Overflow : ConversionException {}
interface Underflow : ConversionException {}
...
Basically enum in DIP 33 expends to a set of dervied interfaces.
Anyhow enums do not allow one to catch based on them which already makes
them highly unusable.
--
Dmitry Olshansky
Re: Do everything in Java…
On Wed, Dec 10, 2014 at 08:33:22PM +0100, Jacob Carlborg via Digitalmars-d wrote: > On 2014-12-10 18:43, H. S. Teoh via Digitalmars-d wrote: > > >That's why the current object file model doesn't work very well. > > > >You'd have to extend the object file format to include compiler IR > >for templates, then the compiler can instantiate templates from that > >IR without needing access to the source. Which is a feature I've > >brought up several times, but nobody seems to be interested in doing > >anything about it. > > Can't you just put it in a custom section? Or perhaps that what you're > saying. Although, I'm not sure if OMF supports custom sections. [...] That *is* what I'm saying. But so far, it seems people aren't that interested in doing that. *shrug* T -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a. -- Wouter Verhelst
Re: Do everything in Java…
On Wed, Dec 10, 2014 at 07:00:24PM +, Tobias Pankrath via Digitalmars-d wrote: > >>// my code > >>foo!(ArcaneType1, DubiousType2)(a, d); > > > >That's why the current object file model doesn't work very well. > > > >You'd have to extend the object file format to include compiler IR > >for templates, then the compiler can instantiate templates from that > >IR without needing access to the source. Which is a feature I've > >brought up several times, but nobody seems to be interested in doing > >anything about it. > > > > > >T > > What information would / could that IR contain besides an AST? It could include additional attributes computed by the compiler that could help in later optimization, such as whether the function escapes references, any inferred function attributes, etc.. The compiler could recompute all this from the IR, of course, but if it's already computed before, why not just reuse the previous results. Also, storing a full AST is probably overkill -- lexing and parsing the source generally doesn't take up too much of the compiler's time, so we might as well just use the source code instead. What makes it more worthwhile is if the AST has already been somewhat processed, e.g., constants have been folded, etc.. Probably after semantic1 and semantic2 have been run (though I'm not sure how far one can get if the template hasn't been instantiated yet). This way, work that has already been done doesn't need to be repeated again. T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Re: Do everything in Java…
On 2014-12-10 18:43, H. S. Teoh via Digitalmars-d wrote: That's why the current object file model doesn't work very well. You'd have to extend the object file format to include compiler IR for templates, then the compiler can instantiate templates from that IR without needing access to the source. Which is a feature I've brought up several times, but nobody seems to be interested in doing anything about it. Can't you just put it in a custom section? Or perhaps that what you're saying. Although, I'm not sure if OMF supports custom sections. -- /Jacob Carlborg
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto wrote: The libraries contain the required metadata for symbol tables and code locations that need to be extracted into the executable/library. Package definition files contain the minimum information the compiler needs to know to search for the remaining information. Example, ... Example shows generics, not templates. Full blown template/mixin support is impossible without anything else but full source access in one form or another.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote: On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote: Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution. You can compile against phobos sources instead of interface files. As far as I understand gdc/ldc problem the way it currently works there is no difference between .di and .d files - if function is not a template its binary is expected to be found in matching object file - and if that object file belongs to prebuild static lib it is completely out of question, even if the sources are completely available. I have never understood exactly what in frontend makes it that much of a problem though
Re: Do everything in Java…
// my code foo!(ArcaneType1, DubiousType2)(a, d); That's why the current object file model doesn't work very well. You'd have to extend the object file format to include compiler IR for templates, then the compiler can instantiate templates from that IR without needing access to the source. Which is a feature I've brought up several times, but nobody seems to be interested in doing anything about it. T What information would / could that IR contain besides an AST?
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 18:16:54 UTC, Paulo Pinto wrote:
On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath
wrote:
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
..
Paulo
I don't see how symbol table information and relocation meta
data is sufficient to produce the correct object code if the
template parameters are unknown.
// library
void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
// my code
foo!(ArcaneType1, DubiousType2)(a, d);
Simple, by dropping C based linker model as I state on my
comment.
--
Paulo
I don't care for the C based linker model. You'll have to
recompile the template, symbol table information and relocation
data is just not enough, in any linker model. So you'll need the
body of foo and you'll need to compile it at "link time".
What advantages of a hypothetical Pascal inspired D linker model
are left now?
If we just want to have binary, because binary, we could share
zipped library source and teach dmd how to unzip.
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
On Wednesday, 10 December 2014 at 14:02:43 UTC, Daniel Murphy wrote: DMD's inliner might be a good place to start. There is a lot to be done there. I am sure that would be interesting. But I gather PR's for DMD are not merged too frequently.
Re: Do everything in Java…
On Wed, Dec 10, 2014 at 06:15:48PM +, Paulo Pinto via Digitalmars-d wrote:
> On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
> Digitalmars-d wrote:
[...]
> >In D, this should be akin to:
> >
> >// Package header
> >module functions;
> >void Swap(T)(out T x, out T y);
> >
> >// Package body
> >module functions;
> >void Swap(T)(out T x, out T y)
> >{
> > // Implementation
> >}
> >
> >// Importing it
> >import functions : Swap;
> >void main()
> >{
> > int x = 1;
> > int y = 2;
> > Swap(x, y);
> >}
> >
> >Iain
>
> But the current object model doesn't support it, right?
>
> At least my understanding is that you need to have the full body
> visible.
[...]
Yeah, the compiler cannot instantiate the template without access to the
full body. It *could*, though, if we were to store template body IR in
object files, perhaps under specially-dedicated object file sections. It
wouldn't prevent reverse-engineering (which is moot anyway when
templates are involved), but it *would* work as an "opaque" library
interface file.
T
--
Food and laptops don't mix.
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 16:17:16 UTC, eles wrote: I believe this is the "Stroustrup curse": " Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I think he is making excuses for himself. Both Java and C++ are rather close to Simula+C as a starting point and have added cruft that should have been predicted in the initial version. Anyway, I think language specs often are too verbose, they probably all hit around 700-1000 pages eventually due to editors cutting it back to that book-like size before it is published (and when the book-sized limit has been reached they feel they have done enough ungrateful and unpaid work so they don't cut more even though they could have).
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 17:19:53 UTC, Tobias Pankrath
wrote:
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
..
Paulo
I don't see how symbol table information and relocation meta
data is sufficient to produce the correct object code if the
template parameters are unknown.
// library
void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
// my code
foo!(ArcaneType1, DubiousType2)(a, d);
Simple, by dropping C based linker model as I state on my comment.
--
Paulo
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 16:56:24 UTC, Iain Buclaw via
Digitalmars-d wrote:
On 10 December 2014 at 14:16, Paulo Pinto via Digitalmars-d
wrote:
On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias
Pankrath wrote:
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto
wrote:
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin
wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
Because you don't really create a template that way but
workaround
broken function behavior. It is not the usage of empty
templates that is bad
but the fact that plain functions remain broken => not
really a solution.
You can compile against phobos sources instead of interface
files.
This cannot be the solution if D aspires to be used in
contexts where
binary libraries are used.
C++ is excused to have template code in headers given the
primitive
tooling, but languages like Ada and Modula-3 support proper
information
hiding for generic code.
--
Paulo
A binary blob requirement makes no sense for a standard
library.
And yet that has been the way it always worked in the Mesa
linage of
languages.
Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal
Would you like to explain how the proper information hiding
support works
for generic code in Ada? I'm really curious how that could
work in D.
The libraries contain the required metadata for symbol tables
and code
locations that need to be extracted into the
executable/library.
Package definition files contain the minimum information the
compiler needs
to know to search for the remaining information.
Example,
-- Package header
generic
type Element_T is private;
package functions is
procedure Swap (X, Y : in out Element_T);
end functions;
-- Package body
package body functions is
procedure Swap (X, Y : in out Element_T) is
begin
-- implementation
end Swap;
end functions;
-- importing it
declare
package functions_Int is new functions (Int);
use functions_Int;
x, y : Int;
begin
x := 1;
y := 2;
Swap(x, y);
end;
Lots of options are possible when the C compiler and linker
model aren't
being used.
In D, this should be akin to:
// Package header
module functions;
void Swap(T)(out T x, out T y);
// Package body
module functions;
void Swap(T)(out T x, out T y)
{
// Implementation
}
// Importing it
import functions : Swap;
void main()
{
int x = 1;
int y = 2;
Swap(x, y);
}
Iain
But the current object model doesn't support it, right?
At least my understanding is that you need to have the full body
visible.
--
Paulo
Re: D3
On Wednesday, 10 December 2014 at 15:53:59 UTC, H. S. Teoh via Digitalmars-d wrote: I find the obsession with small integers (aka version numbers) rather petty. We should start with some random number, like 49183029, What about assigning a prime number to each semantic concept in the language, then calculate the product to get the unique version number? If all languages used the same scheme then you could just factorize the version number to figure out what features a given language-version supports. Another alternatives is just use something more descriptive for versioning, like obscure movie titles: D: http://www.imdb.com/title/tt0287205/?ref_=fn_al_tt_2 D-Train: http://www.imdb.com/title/tt3534602/?ref_=fn_al_tt_5 Tenacious D in The Pick of Destiny: http://www.imdb.com/title/tt0365830/?ref_=fn_al_tt_3 Or perhaps the initial version should be Graham's number, and every following version is obtained by calling the Ackermann function on the previous version number. :-P That'll beat all competitors, for sure. Yes, it is well known that a product does not qualify as mature until the storage requirements for the version number exceeds the requirements for the executable. High resolution versioning is a tremendous benefit for anyone doing modern agile iterative development.
Re: Do everything in Java…
On Wed, Dec 10, 2014 at 05:19:53PM +, Tobias Pankrath via Digitalmars-d
wrote:
> On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto wrote:
>
> >
> >Lots of options are possible when the C compiler and linker model
> >aren't being used.
> >
> >..
> >Paulo
>
> I don't see how symbol table information and relocation meta data is
> sufficient to produce the correct object code if the template
> parameters are unknown.
>
> // library
> void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
>
> // my code
> foo!(ArcaneType1, DubiousType2)(a, d);
That's why the current object file model doesn't work very well.
You'd have to extend the object file format to include compiler IR for
templates, then the compiler can instantiate templates from that IR
without needing access to the source. Which is a feature I've brought up
several times, but nobody seems to be interested in doing anything about
it.
T
--
Real Programmers use "cat > a.out".
Using the TZ Database with Windows
Hello, I'm doing some research with D concerning time zones and I need to be able to handle a single time zone style on both Windows and Linux. That pretty much leaves me with the IANA Time Zone Database. Has anyone around here dealt with compiling the data files for the tz database on Windows? Or is there some easy way to do it for D?
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 14:16:47 UTC, Paulo Pinto
wrote:
Lots of options are possible when the C compiler and linker
model aren't being used.
..
Paulo
I don't see how symbol table information and relocation meta data
is sufficient to produce the correct object code if the template
parameters are unknown.
// library
void foo(T, U)(T t, U u) { t.tee(); u.uuuh(); }
// my code
foo!(ArcaneType1, DubiousType2)(a, d);
Re: Any SIMD experts?
On Wednesday, 10 December 2014 at 15:53:40 UTC, Martin Nowak wrote: On 12/09/2014 05:22 PM, John Colvin wrote: which of course Kenji already has a pull for, less than 3 hours later :) It's right on time, it's right on time Still doesn't work though: https://issues.dlang.org/show_bug.cgi?id=13852 you can't even use core.imd.__simd because it doesn't have PCMPGTQ https://issues.dlang.org/show_bug.cgi?id=8047
Re: D3
On Tuesday, 9 December 2014 at 08:15:02 UTC, Puming wrote: For Chinese it would be "帝" which pronounces the same as 'D' and means Emperor. An interesting coincidence is that Walter also created the game Empire :-) source: I'm Chinese D2 = D二 = 第二 That was an attempt at a pun, but my Chinese is not very good...
Re: Do everything in Java…
On 10 December 2014 at 14:16, Paulo Pinto via Digitalmars-d
wrote:
> On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote:
>>
>> On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto wrote:
>>>
>>> On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>
> Because you don't really create a template that way but workaround
> broken function behavior. It is not the usage of empty templates that is
> bad
> but the fact that plain functions remain broken => not really a solution.
You can compile against phobos sources instead of interface files.
>>>
>>>
>>> This cannot be the solution if D aspires to be used in contexts where
>>> binary libraries are used.
>>>
>>> C++ is excused to have template code in headers given the primitive
>>> tooling, but languages like Ada and Modula-3 support proper information
>>> hiding for generic code.
>>>
>>> --
>>> Paulo
>>
>>
>> A binary blob requirement makes no sense for a standard library.
>
>
> And yet that has been the way it always worked in the Mesa linage of
> languages.
>
> Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal
>
>>
>> Would you like to explain how the proper information hiding support works
>> for generic code in Ada? I'm really curious how that could work in D.
>
>
> The libraries contain the required metadata for symbol tables and code
> locations that need to be extracted into the executable/library.
>
> Package definition files contain the minimum information the compiler needs
> to know to search for the remaining information.
>
> Example,
>
> -- Package header
> generic
> type Element_T is private;
> package functions is
> procedure Swap (X, Y : in out Element_T);
> end functions;
>
> -- Package body
> package body functions is
> procedure Swap (X, Y : in out Element_T) is
> begin
> -- implementation
> end Swap;
> end functions;
>
> -- importing it
> declare
> package functions_Int is new functions (Int);
> use functions_Int;
> x, y : Int;
> begin
> x := 1;
> y := 2;
> Swap(x, y);
> end;
>
>
> Lots of options are possible when the C compiler and linker model aren't
> being used.
In D, this should be akin to:
// Package header
module functions;
void Swap(T)(out T x, out T y);
// Package body
module functions;
void Swap(T)(out T x, out T y)
{
// Implementation
}
// Importing it
import functions : Swap;
void main()
{
int x = 1;
int y = 2;
Swap(x, y);
}
Iain
Re: DIP69 - Implement scope for escape proof references
On Wednesday, 10 December 2014 at 15:15:59 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote: D is already in that landscape and should try hard not to sink deeper into the muddy waters. Funny thing it is that it started exactly as a reaction to those muddy waters. I believe this is the "Stroustrup curse": " Much of the relative simplicity of Java is - like for most new languages - partly an illusion and partly a function of its incompleteness. As time passes, Java will grow significantly in size and complexity. It will double or triple in size and grow implementation-dependent extensions or libraries. That is the way every commercially successful language has developed. Just look at any language you consider successful on a large scale. I know of no exceptions, and there are good reasons for this phenomenon. [I wrote this before 2000; now (2012), the language part of the Java 7 specification is slightly longer in terms of number of pages than the ISO C++11 language specification.] "
Re: D Meetup in SF?
On 12/10/2014 07:30 AM, Shammah Chancellor wrote: I think meetups are a great way to evangelize. And to colaborate
Re: Any SIMD experts?
On 12/09/2014 05:22 PM, John Colvin wrote: which of course Kenji already has a pull for, less than 3 hours later :) It's right on time, it's right on time
Re: Very short anonymous survey
On Wednesday, 10 December 2014 at 15:33:51 UTC, Anonymous wrote: On Wednesday, 10 December 2014 at 15:24:13 UTC, BBaz wrote: On Wednesday, 10 December 2014 at 05:33:20 UTC, Anonymous wrote: Hello all, If I could have a minute of your time for a short anonymous survey regarding D libraries and tools, I'd really appreciate it. http://goo.gl/forms/lMrHRr335C This is explained further in the link above, but for context: I'm a developer working on a library for D that I need for an application I'd like to write in D. I need the community's opinion of paying for builds of open source software, as my library requires extra work to build and cannot be built with just dub. I want to make it as easy as possible for others to use the library, but providing/maintaining builds for different compilers and platforms is time-consuming and costly. Thanks for your time! Hello, sorry for being a kill-joy but your survey table is seriously bugged ! Have you tried it before publishing ? Yes, and others have successfully responded to it. Can you be more specific about the problem you're having? Well...it's just worked now. Previously I could not select 0$ more than once. Dunno what happened.
Re: D3
On Wed, Dec 10, 2014 at 03:35:36PM +, via Digitalmars-d wrote: > On Wednesday, 10 December 2014 at 13:55:22 UTC, Wyatt wrote: > >Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up > >in the version numbering race and call the next one D11. Followed, > >naturally, by D100. ;) > > Som alternatives: > > - Unary notation: D1, D11, D111, D… > > - Roman: DI, DII, DIII, DIV, DV, DVI, DVII… > > D=500, so DI would start off at version 501… Just like Levi's… I find the obsession with small integers (aka version numbers) rather petty. We should start with some random number, like 49183029, and every subsequent release increment it by a random positive increment, TCP sequence number style. So the next version could be 50372948, then the following 59384729, then 73940121, etc.. Or perhaps the initial version should be Graham's number, and every following version is obtained by calling the Ackermann function on the previous version number. :-P That'll beat all competitors, for sure. T -- Doubt is a self-fulfilling prophecy.
Re: D3
On Wednesday, 10 December 2014 at 13:55:22 UTC, Wyatt wrote: Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up in the version numbering race and call the next one D11. Followed, naturally, by D100. ;) Som alternatives: - Unary notation: D1, D11, D111, D… - Roman: DI, DII, DIII, DIV, DV, DVI, DVII… D=500, so DI would start off at version 501… Just like Levi's…
Re: Very short anonymous survey
On Wednesday, 10 December 2014 at 15:24:13 UTC, BBaz wrote: On Wednesday, 10 December 2014 at 05:33:20 UTC, Anonymous wrote: Hello all, If I could have a minute of your time for a short anonymous survey regarding D libraries and tools, I'd really appreciate it. http://goo.gl/forms/lMrHRr335C This is explained further in the link above, but for context: I'm a developer working on a library for D that I need for an application I'd like to write in D. I need the community's opinion of paying for builds of open source software, as my library requires extra work to build and cannot be built with just dub. I want to make it as easy as possible for others to use the library, but providing/maintaining builds for different compilers and platforms is time-consuming and costly. Thanks for your time! Hello, sorry for being a kill-joy but your survey table is seriously bugged ! Have you tried it before publishing ? Yes, and others have successfully responded to it. Can you be more specific about the problem you're having?
Re: Very short anonymous survey
On Wednesday, 10 December 2014 at 08:29:51 UTC, Martin Drašar via Digitalmars-d wrote: Dne 10.12.2014 v 6:33 Anonymous via Digitalmars-d napsal(a): Hello all, If I could have a minute of your time for a short anonymous survey regarding D libraries and tools, I'd really appreciate it. http://goo.gl/forms/lMrHRr335C This is explained further in the link above, but for context: I'm a developer working on a library for D that I need for an application I'd like to write in D. I need the community's opinion of paying for builds of open source software, as my library requires extra work to build and cannot be built with just dub. I want to make it as easy as possible for others to use the library, but providing/maintaining builds for different compilers and platforms is time-consuming and costly. Thanks for your time! Hi, I would like to fill out your survey, but the description makes it too abstract for me to reasonably choose my answers. The price I am willing to pay for a piece of software is always dictated by the prices of other software available and by returns of the software I am programming (be it money or just joy). I understand that. Going into this, I was more concerned with how many people would refuse such an offering in its various forms. You wrote some interesting things: "However, this library has some *very* large generated sources, which makes it difficult (if not impossible) to compile using common D tools (namely, dub). It is using a different build system, which allows it to generate and build quite easily, but would likely create headaches for dub users." These are some strong claims, would you care to back them up with some numbers? These numbers change as I work on the library, and I am being purposeful about remaining as anonymous as possible at this stage in case this offering is the sort of thing that would create a backlash from this community. What I will say is that building the D code itself with rdmd requires more RAM than any of the machines I have access to can offer - it has to be done one module at a time, and required the creation of manually maintained .di files. Also, could you give more details about the library? Or the build system? It may turn out that the library itself is not likely to be a source of your income, but the build system can be. I don't expect either would be. The build system is publicly available, it just isn't common in the D community. Who knows... Unless you give more details, you are not likely to get reasonable answers. I've gotten decent responses so far. I may go into more detail soon, but I've also got a lot more work to do before the library is ready for an initial release, so details I could give would not all necessarily end up being accurate. Just my opinion... And it is appreciated. It doesn't have to be on the form to be valuable input. Martin
Re: Comparing Parallelization in HPC with D, Chapel, and Go
I am author of the paper "A Study of Successive Over-relaxation Method Parallelization Over Modern HPC Languages". The code has been made available for academic use at https://www.academia.edu/9709444/Source_code_of_Parallel_and_Serial_Red-Black_SOR_Implementation_in_Chapel_D_and_Go_Languages Questions and comments can be sent to my email address [although note that use of software does not imply support].
Re: Very short anonymous survey
On Wednesday, 10 December 2014 at 05:33:20 UTC, Anonymous wrote: Hello all, If I could have a minute of your time for a short anonymous survey regarding D libraries and tools, I'd really appreciate it. http://goo.gl/forms/lMrHRr335C This is explained further in the link above, but for context: I'm a developer working on a library for D that I need for an application I'd like to write in D. I need the community's opinion of paying for builds of open source software, as my library requires extra work to build and cannot be built with just dub. I want to make it as easy as possible for others to use the library, but providing/maintaining builds for different compilers and platforms is time-consuming and costly. Thanks for your time! Hello, sorry for being a kill-joy but your survey table is seriously bugged ! Have you tried it before publishing ?
Re: DIP69 - Implement scope for escape proof references
On Tuesday, 9 December 2014 at 21:58:48 UTC, deadalnix wrote: That why i say they are linked. I don't think your way of stating it contradict what I said. scope allow for manipulation of data without owning them. Whatever the owner is (be it the stack frame or anything else) doesn't really matter here. It does when you return parts of it, like if you pass in a binary tree and return a node. Which you have to be able to do for the concept to make sense. When you solve issues in language design you should address the hard issues first, because the easy issues will then tend to resolve themselves if the design is good. If you start with "the low hanging fruit" you end up with pointless special casing… D is already in that landscape and should try hard not to sink deeper into the muddy waters. I posit that if you have a solution for ownership/retaining references then the solution for scope will come from this as a side-effect.
Re: Very short anonymous survey
On Wednesday, 10 December 2014 at 08:02:25 UTC, Kagamin wrote: The form doesn't accept my input. Just provide your cool build system so people could use it to build the library. Yeah, you'll be able to build the library yourself (or download builds other people make, even). The survey is so I can judge if I should bother preparing builds and offering them for a fee. I don't want to put the time into that, then offer it to the community, just to have them reject my work for daring to ask for payment for pre-compiled builds. I don't expect that to happen, but I wanted to be sure.
Re: D3
On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) That's DDD or D³, not D v3.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 12:24:56 UTC, Tobias Pankrath wrote: On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto wrote: On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote: On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote: Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution. You can compile against phobos sources instead of interface files. This cannot be the solution if D aspires to be used in contexts where binary libraries are used. C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code. -- Paulo A binary blob requirement makes no sense for a standard library. And yet that has been the way it always worked in the Mesa linage of languages. Mesa, Modula-2, Modula-3, Ada, Oberon, Object Pascal Would you like to explain how the proper information hiding support works for generic code in Ada? I'm really curious how that could work in D. The libraries contain the required metadata for symbol tables and code locations that need to be extracted into the executable/library. Package definition files contain the minimum information the compiler needs to know to search for the remaining information. Example, -- Package header generic type Element_T is private; package functions is procedure Swap (X, Y : in out Element_T); end functions; -- Package body package body functions is procedure Swap (X, Y : in out Element_T) is begin -- implementation end Swap; end functions; -- importing it declare package functions_Int is new functions (Int); use functions_Int; x, y : Int; begin x := 1; y := 2; Swap(x, y); end; Lots of options are possible when the C compiler and linker model aren't being used. .. Paulo
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
"Stefan Koch" wrote in message news:furihdkmprozoruut...@forum.dlang.org... Hello guys, I want to work on optimisations in the semantic analysis stage. Could you chime in with thoughts about what can only be there and not in llvm-ir for example ? DMD's inliner might be a good place to start. There is a lot to be done there.
Re: D3
On Wednesday, 10 December 2014 at 00:58:59 UTC, Chris Williams wrote: On Monday, 8 December 2014 at 20:21:51 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 12/8/14, Russel Winder via Digitalmars-d wrote: It seems that D3 is already available: https://github.com/mbostock/d3 Guess we'll just have to skip a number and call the next D - D4. :) Powers of two are magic. Cribbing from the dubious wisdom of Mozilla and ISO, we can catch up in the version numbering race and call the next one D11. Followed, naturally, by D100. ;) -Wyatt
Re: Which optimisations are are easier or perhaps only possible in the frontend ?
On Wednesday, 10 December 2014 at 11:07:34 UTC, Stefan Koch wrote: Hello guys, I want to work on optimisations in the semantic analysis stage. Could you chime in with thoughts about what can only be there and not in llvm-ir for example ? Thanks Stefan Well it really depends how descriptive your IR happens to be. Perhaps high-level promises about code that the compiler can't see. E.g. something like @commutative float[] convolve(float[] a, float[] b);
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 10:46:58 UTC, bearophile wrote:
The #[no_std] attribute is used to avoid the runtime in Rust.
Do we have any use for a @noruntime attribute in D?
All @noruntime functions are also @nogc (so you don't need to
put both attributes).
This could give a compilation error:
void foo(int[] a) @noruntime {
int[5] b = a[];
}
I just remembered I had an idea for this specific feature that
would require no special attribute. You simply take all the
hard-coded symbols out of the compiler and put them in a .di
header file. Then you can version out, @deprectate, @disable, or
not import the .di file if you don't want any or all of the
runtime.
I tried to implement this in GDC, but failed. I need to put more
time into it to try and figure it out. Theoretically, though, I
think it should work.
Mike
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 12:50:19 UTC, Mike wrote: I just remembered I had an idea for this specific feature that would require no special attribute. You simply take all the hard-coded symbols out of the compiler and put them in a .di header file. Then you can version out, @deprectate, @disable, or not import the .di file if you don't want any or all of the runtime. I tried to implement this in GDC, but failed. I need to put more time into it to try and figure it out. Theoretically, though, I think it should work. Mike Here's the previous thread where I discussed this: http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org Mike
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 12:04:13 UTC, Daniel Murphy wrote: "bearophile" wrote in message news:pibnlncyjzetohcnw...@forum.dlang.org... The #[no_std] attribute is used to avoid the runtime in Rust. Do we have any use for a @noruntime attribute in D? All @noruntime functions are also @nogc (so you don't need to put both attributes). Why would you ever be writing code at this level and yet somehow not be able to just use the linker errors? That was my thought too. I don't see the value of having a semantic promise for this. bearophile: can you describe a practical use-case where there is an advantage to @noruntime, other than "linker errors aren't pretty to read".
Re: No runtime attribute?
On Wed, 10 Dec 2014 10:46:56 +
bearophile via Digitalmars-d wrote:
> The #[no_std] attribute is used to avoid the runtime in Rust.
>
> Do we have any use for a @noruntime attribute in D?
>
> All @noruntime functions are also @nogc (so you don't need to put
> both attributes).
>
>
> This could give a compilation error:
>
> void foo(int[] a) @noruntime {
> int[5] b = a[];
> }
>
> Bye,
> bearophile
this can be useful if compiler will generate error message with exact
runtime function signatures. i.e. something like:
Error: foo() requires '_runtimeA(void*, size_t)'
or even better: add a command-line switch to generate such reports.
signature.asc
Description: PGP signature
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 10:46:58 UTC, bearophile wrote:
The #[no_std] attribute is used to avoid the runtime in Rust.
Do we have any use for a @noruntime attribute in D?
All @noruntime functions are also @nogc (so you don't need to
put both attributes).
This could give a compilation error:
void foo(int[] a) @noruntime {
int[5] b = a[];
}
Yes, it would be nice to separate *language* from *library*, but
I've proposed such ideas in the past and they've only met
resistance.
Mike
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 12:18:47 UTC, Mike wrote: On Wednesday, 10 December 2014 at 11:15:44 UTC, Stefan Koch wrote: It would be very nice if we could subsitute individual functions of the runtime library by other functions or function pointers. I believe this is already possible with DMD because all druntime functions are compiled as weak symbols. I don't believe this is the case for LDC and GDC, however. If LDC and GDC provided something equivalent to GCC's weak attribute, and the runtime functions were decorated with it, then the same method would work for all compilers. Actually, I just remembered I've done this before with GDC and LDC. You do it with ld's -wrap switch. Example: http://forum.dlang.org/post/gqyzyldgdqhamtouy...@forum.dlang.org LD's documentation: http://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html (see the bottom of the page) Mike
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto wrote: On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote: On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote: Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution. You can compile against phobos sources instead of interface files. This cannot be the solution if D aspires to be used in contexts where binary libraries are used. C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code. -- Paulo A binary blob requirement makes no sense for a standard library. Would you like to explain how the proper information hiding support works for generic code in Ada? I'm really curious how that could work in D.
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 11:15:44 UTC, Stefan Koch wrote: It would be very nice if we could subsitute individual functions of the runtime library by other functions or function pointers. I believe this is already possible with DMD because all druntime functions are compiled as weak symbols. I don't believe this is the case for LDC and GDC, however. If LDC and GDC provided something equivalent to GCC's weak attribute, and the runtime functions were decorated with it, then the same method would work for all compilers. Mike
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 10:48:12 UTC, Walter Bright wrote: On 12/10/2014 2:24 AM, Paulo Pinto wrote: This cannot be the solution if D aspires to be used in contexts where binary libraries are used. C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code. There's no way you can hide the implementation of a function from the user if it is available to the compiler. Quite a few people thought C++ "exported templates" would make this work, but there is no known way to implement it and keep it hidden from the user, not even if it is encrypted since the compiler must decrypt it. My remark had nothing to do with IP. I prefer the model used by the referred languages, where binary libraries and metadata is used, instead of the C toolchain model. For example, just shipping the .TPU/.DCU libraries in the Object Pascal world. -- Paulo
Re: No runtime attribute?
"bearophile" wrote in message news:pibnlncyjzetohcnw...@forum.dlang.org... The #[no_std] attribute is used to avoid the runtime in Rust. Do we have any use for a @noruntime attribute in D? All @noruntime functions are also @nogc (so you don't need to put both attributes). Why would you ever be writing code at this level and yet somehow not be able to just use the linker errors?
Re: No runtime attribute?
On Wednesday, 10 December 2014 at 10:46:58 UTC, bearophile wrote:
The #[no_std] attribute is used to avoid the runtime in Rust.
Do we have any use for a @noruntime attribute in D?
All @noruntime functions are also @nogc (so you don't need to
put both attributes).
This could give a compilation error:
void foo(int[] a) @noruntime {
int[5] b = a[];
}
Bye,
bearophile
In a similar vain.
It would be very nice if we could subsitute individual functions
of the runtime library by other functions or function pointers.
Which optimisations are are easier or perhaps only possible in the frontend ?
Hello guys, I want to work on optimisations in the semantic analysis stage. Could you chime in with thoughts about what can only be there and not in llvm-ir for example ? Thanks Stefan
Re: problem with size_t and an easy solution
On Wed, 10 Dec 2014 10:36:22 + Ivan Kazmenko via Digitalmars-d wrote: > On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via > Digitalmars-d wrote: > > On Tue, 09 Dec 2014 17:28:15 + > > Ivan Kazmenko via Digitalmars-d > > wrote: > > > >> A well-designed language allows to recover from errors with > >> good probability > > if compiler can recover from error, it should not report the > > error at > > all -- 'cause it can fix the code for me. > > > > that is absolutely nonsense, you *CAN'T* "recover" from invalid > > code. > > that is the fact. fact: Earth is not a sphere. fact: you can't > > automatically recover from invalid code. > > That sounds much like an opinion, a lot less like a fact. If you > are willing to convince people, please provide some evidence, > aside from another unrelated fact. the ones who believes that recovery covers most of the cases should bring proofs, not me. it's obvious that guessing on invalid input is unreliable. > In my experience, I find multiple reported compile errors useful > in a number of programming languages and compilers including D. > It allows for somewhat faster error fixing than the > first-error-only reporting strategy - seen that, too, back in the > Borland Pascal MS-DOS IDE and few other compilers. I won't trade > the extra benefit just for philosophical notions. most of the bugs compiler reports can be catched by good IDE without compiling the source at all. what's left is bugs where all hell breaks loose due to things that can't be "recovered" (like missing brackets, for example -- and ah, that can be catched by IDE too!), thus producing a pool of vomit. and with fast compiler there is no sense in vomiting, as you physically can't edit two code fragments simultaneously, thus you *will* fix bugs one by one. and "go to next bug" hotkey can simply invoke fast compiler to get another error message. last, but not least: "recovering" attempts increases parser complexity. signature.asc Description: PGP signature
Re: Do everything in Java…
On 12/10/2014 2:24 AM, Paulo Pinto wrote: This cannot be the solution if D aspires to be used in contexts where binary libraries are used. C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code. There's no way you can hide the implementation of a function from the user if it is available to the compiler. Quite a few people thought C++ "exported templates" would make this work, but there is no known way to implement it and keep it hidden from the user, not even if it is encrypted since the compiler must decrypt it.
No runtime attribute?
The #[no_std] attribute is used to avoid the runtime in Rust.
Do we have any use for a @noruntime attribute in D?
All @noruntime functions are also @nogc (so you don't need to put
both attributes).
This could give a compilation error:
void foo(int[] a) @noruntime {
int[5] b = a[];
}
Bye,
bearophile
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 02:15:04 UTC, ketmar via Digitalmars-d wrote: On Tue, 09 Dec 2014 17:28:15 + Ivan Kazmenko via Digitalmars-d wrote: A well-designed language allows to recover from errors with good probability if compiler can recover from error, it should not report the error at all -- 'cause it can fix the code for me. that is absolutely nonsense, you *CAN'T* "recover" from invalid code. that is the fact. fact: Earth is not a sphere. fact: you can't automatically recover from invalid code. That sounds much like an opinion, a lot less like a fact. If you are willing to convince people, please provide some evidence, aside from another unrelated fact. If you guess the right recovery in, say, 99% of cases, few would care that it's theoretically impossible in the general case. In my experience, I find multiple reported compile errors useful in a number of programming languages and compilers including D. It allows for somewhat faster error fixing than the first-error-only reporting strategy - seen that, too, back in the Borland Pascal MS-DOS IDE and few other compilers. I won't trade the extra benefit just for philosophical notions.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo Pinto wrote: This cannot be the solution if D aspires to be used in contexts where binary libraries are used. For completely opaque libraries one can compile against interface files.
Re: Do everything in Java…
On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote: On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote: Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution. You can compile against phobos sources instead of interface files. This cannot be the solution if D aspires to be used in contexts where binary libraries are used. C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code. -- Paulo
Re: problem with size_t and an easy solution
On Wednesday, 10 December 2014 at 01:21:58 UTC, Mike Parker wrote: So you should be importing core.stdc.stdint directly. Pretend that std.stdint doesn't exist. I am.
Re: Do everything in Java…
On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote: Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution. You can compile against phobos sources instead of interface files.
Re: Very short anonymous survey
Dne 10.12.2014 v 6:33 Anonymous via Digitalmars-d napsal(a): > Hello all, > > If I could have a minute of your time for a short anonymous survey > regarding D libraries and tools, I'd really appreciate it. > > http://goo.gl/forms/lMrHRr335C > > > This is explained further in the link above, but for context: I'm a > developer working on a library for D that I need for an application I'd > like to write in D. I need the community's opinion of paying for builds > of open source software, as my library requires extra work to build and > cannot be built with just dub. I want to make it as easy as possible for > others to use the library, but providing/maintaining builds for > different compilers and platforms is time-consuming and costly. > > Thanks for your time! Hi, I would like to fill out your survey, but the description makes it too abstract for me to reasonably choose my answers. The price I am willing to pay for a piece of software is always dictated by the prices of other software available and by returns of the software I am programming (be it money or just joy). You wrote some interesting things: "However, this library has some *very* large generated sources, which makes it difficult (if not impossible) to compile using common D tools (namely, dub). It is using a different build system, which allows it to generate and build quite easily, but would likely create headaches for dub users." These are some strong claims, would you care to back them up with some numbers? Also, could you give more details about the library? Or the build system? It may turn out that the library itself is not likely to be a source of your income, but the build system can be. Who knows... Unless you give more details, you are not likely to get reasonable answers. Just my opinion... Martin smime.p7s Description: Elektronicky podpis S/MIME
Re: Can we make Throwable an interface?
On Tuesday, 9 December 2014 at 18:07:16 UTC, H. S. Teoh via Digitalmars-d wrote: what is more interesting is "was this failure caused by permission error?". And what if it does? You would create thousands of types and their cartesian products just to check for one of them?
Re: Can we make Throwable an interface?
On Tuesday, 9 December 2014 at 17:06:45 UTC, Dmitry Olshansky wrote: 1. enums are hard to extend for std lib, and absolutely impossible by 3rd party libraries. What's the problem? When you add new functionality to std lib, you add an enum entry in the same pull request. 3rd party libraries define their specific exceptions and enums.
Re: Very short anonymous survey
On Wed, 10 Dec 2014 08:02:22 + Kagamin via Digitalmars-d wrote: > The form doesn't accept my input. Just provide your cool build > system so people could use it to build the library. or even better: provide sh-script to build the thing. it can be suboptimal, but if it accepts at least DFLAGS people will either rewrite it for their build systems or will make a wrapper or something. signature.asc Description: PGP signature
Re: Very short anonymous survey
The form doesn't accept my input. Just provide your cool build system so people could use it to build the library.
