Re: @ctfeonly
On Thursday, 7 December 2017 at 06:33:42 UTC, E.S. Quinn wrote: If all you need is a runtime error, you can already put assert(__ctfe); in your function. For me, a runtime error is exactly what I want to avoid. Mike
Re: @ctfeonly
On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time. Not bad, but that is swaying into the cumbersome category. If that's the best we can do, a @ctfeonly attribute starts looking pretty good. Mike
Re: @ctfeonly
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? Hi Nicholas, I am going to add a feature which will help you in this case; As part of the work I am doing to make templates faster.
Re: @ctfeonly
On Thursday, 7 December 2017 at 05:53:06 UTC, bauss wrote: On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries - Jonathan M Davis I think that's the point of the attribute. You tell the compiler that this function can only be called at compile-time and any attempt to call it during run-time would be an error. If all you need is a runtime error, you can already put assert(__ctfe); in your function.
Re: Adding Markdown to Ddoc
On 12/5/17 9:11 PM, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) I didn't notice anyone pick this up yet. I'm taking a stab at it, writing it mostly from scratch. However if someone else wants to pick it up you're very welcome; my attempt is likely to be slow, especially this time of year :)
Re: @ctfeonly
On Thursday, 7 December 2017 at 04:45:15 UTC, Jonathan M Davis wrote: As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries - Jonathan M Davis I think that's the point of the attribute. You tell the compiler that this function can only be called at compile-time and any attempt to call it during run-time would be an error.
Re: function for inverse relative path?
On Wednesday, December 06, 2017 17:36:04 Timothee Cour via Digitalmars-d
wrote:
> what would be a robust way to do this `inverseRelativePath`, and
> should that be in std.path?
>
> ```
> auto a="/a/b/c.d";
> auto b="b/c.d";
> assert(inverseRelativePath(a, b) == "/a");
> assertThrown(inverseRelativePath(a, "c2.d"));
> ```
I've never heard of inverse relative paths, but it looks like all you're
doing is looking for a substring match at the end and returning the parts at
the front that don't match. If you're doing that, you could simply do
something like
enforce(lhs.length >= rhs.length, "some error message");
if(lhs[rhs.length .. $] == rhs)
return lhs[0 .. rhs.length];
throw new Exception("some error message");
though if you want /a instead of /a/ in your example, some extra code would
have to be added for properly handling trailing slashes, and depending, you
might want to normalize paths first (though typically, that sort of thing is
left up to the caller). It might also need to be enforced that the left-hand
argument is an absolute path.
- Jonathan M Davis
Re: @ctfeonly
On Thursday, December 07, 2017 03:43:42 Nicholas Wilson via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 03:18:57 UTC, Jonathan M Davis > > wrote: > > On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d > > > > wrote: > >> On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson > >> > >> wrote: > >> > I'd like to add an attribute to indicate that the annotated > >> > function is only available at compile time so that in cases > >> > where the operation is invalid at runtime (strings and > >> > concatenation on a GPU for instance) but the result is only > >> > used at compile time (for a mixin) the compiler is free to > >> > not codegen that function. > >> > > >> > I can add this to LDC pretty easily, but does anyone else > >> > have a use for this (e.g. shrinking binary sizes for mixin > >> > heavy codebases) and would benefit having this as a standard > >> > thing? > >> > >> Shouldn't the linker do this already? > >> > >> Once the compiler has CTFE'd the function any call in the code > >> should be replaced with the function evaluation. The linker > >> should then drop the code out of the binary because it really > >> is dead code. > > Unfortunately I don't have a linker to do that for me with > DCompute. > > > Regardless, needing something like an attribute to tell the > > compiler to strip stuff out of the binary seems like a hack to > > me. It may actually be necessary in some cases, but it just > > feels like it should be unnecessary. > > Do you have any other ideas about how to achieve this other than > an attribute? > Having an attribute seems the most simple and straightforward. It may be that an attribute is required in at least some cases, but it seems like it shouldn't be and that if the compiler and/or linker isn't smart enough to strip out stuff that's only used at compile time, then it should be fixed to be smart enough. However, too often, there's some detail that's not obvious that makes it so that things can't work they way that it seems like they should. And of course, I have no clue how whatever you're doing works if you're not using a linker with dcompute, so I don't know how it differs from normal. I've never done anything with GPU programming. - Jonathan M Davis
Re: @ctfeonly
On Thursday, December 07, 2017 03:59:09 Mike Franklin via Digitalmars-d wrote: > Also, I want the > compiler to let me know if my intended-for-compile-time-only > function cannot be used at compile-time because I mistakenly made > it dependent on something that is only available at runtime. The simplest way to do that is to write a unit test that uses a static assertion. As I understand it, with the way CTFE works, it pretty much can't know whether a function can be called at compile time until it tries, but a unit test can catch it if the function no longer works at compile time. - Jonathan M Davis
Re: function for inverse relative path?
how about:
```
string inverseRelativePath(string root, string rel){
while(true){
if(rel.empty || rel==".") {
return root;
}
auto a1=root.baseName;
auto a2=rel.baseName;
enforce(a1==a2, text(root, " ", rel));
root=root.dirName;
rel=rel.dirName;
}
}
unittest{
import std.exception;
auto a="/a/b/c.d";
auto b="b/c.d";
assert(inverseRelativePath(a, b) == "/a");
assertThrown(inverseRelativePath(a, "c2.d"));
}
```
On Wed, Dec 6, 2017 at 5:36 PM, Timothee Cour wrote:
> what would be a robust way to do this `inverseRelativePath`, and
> should that be in std.path?
>
> ```
> auto a="/a/b/c.d";
> auto b="b/c.d";
> assert(inverseRelativePath(a, b) == "/a");
> assertThrown(inverseRelativePath(a, "c2.d"));
> ```
Re: @ctfeonly
On Thursday, 7 December 2017 at 03:43:42 UTC, Nicholas Wilson wrote: ... Do you have any other ideas about how to achieve this other than an attribute? Having an attribute seems the most simple and straightforward. llvm has "Aggressive Dead Code Elimination"- and "Dead Code Elimination"-switches, who I find interesting. https://llvm.org/docs/Passes.html#transform-passes I remember once I actually stripped off kinda 99% of a statically linked phobos-library with that and I got a small executable who was still working
Re: @ctfeonly
ketmar wrote:
Nicholas Wilson wrote:
Also not generating the code in the first place means less I/O for the
compiler and less work for the linker.
this is solvable without any additional flags, tho: compiler should just
skip codegen phase for any function that is not referenced by another
compiled function (except for library case).
p.s.: actually, dmd already creates .a files suitable for smartlinking
(otherwise any binary would include the whole libphobos2.a ;-). but for
"dmd mycode.d" dmd doesn't do this ('cause it is quite compilcated for
non-library case). the whole issue prolly can be solved by "generate smart
object files for linking" flag (which will create .a files for everything,
so linker can do it's smart work).
Re: @ctfeonly
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? I've thought about this in the past, but never really pursued it much to see if there are already existing facilities in the language to accomplish what I want. I want to enforce that a method is only used at compile time. That is I want either the compiler or the linker to throw an error if I've accidentally used a function at runtime when I only intended it to be used at compile-time. Also, I want the compiler to let me know if my intended-for-compile-time-only function cannot be used at compile-time because I mistakenly made it dependent on something that is only available at runtime. That being said, I want D's features to carry their weight. I would first like to prove that facilities don't already exist or that existing facilities are too cumbersome to accomplish said goal before adding such a feature. Also, my primary motivation for using D is so I can program resource-constrained microcontrollers in a more fun and convenient language than C/C++. I've definitely encountered code-size problems in D, but they were mostly due to the compiler's unnecessary coupling to the runtime, and the way the compiler generated code as the linker couldn't prove that the code was dead (Exhibit A: https://issues.dlang.org/show_bug.cgi?id=14758). I don't yet see how @ctfeonly would help with that. Mike
Re: @ctfeonly
Nicholas Wilson wrote: Also not generating the code in the first place means less I/O for the compiler and less work for the linker. this is solvable without any additional flags, tho: compiler should just skip codegen phase for any function that is not referenced by another compiled function (except for library case). I definitely don't want D to become C++. What is smartlinking? any decent linker simply drops anything that is not reveferenced. i.e. any function that is not referenced from another function that is definitely included in the binary, will be skipped. as linker knows program entry point, it is able to build reference tree, and do "smart" linking instead of just putting everything into resulting binary. This is intended for stuff like code that generates strings for mixins. as i said, this is something compiler can do automatically, without user's help. we already have too much attributes, i believe, adding even more won't do any good.
Re: @ctfeonly
On Thursday, 7 December 2017 at 03:18:57 UTC, Jonathan M Davis wrote: On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote: On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: > I'd like to add an attribute to indicate that the annotated > function is only available at compile time so that in cases > where the operation is invalid at runtime (strings and > concatenation on a GPU for instance) but the result is only > used at compile time (for a mixin) the compiler is free to > not codegen that function. > > I can add this to LDC pretty easily, but does anyone else > have a use for this (e.g. shrinking binary sizes for mixin > heavy codebases) and would benefit having this as a standard > thing? Shouldn't the linker do this already? Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code. Unfortunately I don't have a linker to do that for me with DCompute. Regardless, needing something like an attribute to tell the compiler to strip stuff out of the binary seems like a hack to me. It may actually be necessary in some cases, but it just feels like it should be unnecessary. Do you have any other ideas about how to achieve this other than an attribute? Having an attribute seems the most simple and straightforward.
Re: @ctfeonly
On Thursday, 7 December 2017 at 02:33:49 UTC, ketmar wrote: H. S. Teoh wrote: On Thu, Dec 07, 2017 at 01:21:11AM +, Nicholas Wilson via Digitalmars-d wrote: [...] I'd like to have this too. Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctfeonly annotation that tells the compiler not to codegen the (many instantiations of the) function would be greatly welcomed. T this is a hack for something that really should be done in linker, automatically. please, people, let's not turn D into C++! ;-) i mean: this has a short-time benefits, but makes the language more complex, less clear, and completely destroys any incentive to make smartlinking work as intended in case it is broken. Not all of the generated code goes through a linker ;) For dcompute strings aren't even supported yet! Let alone concatenation. Also not generating the code in the first place means less I/O for the compiler and less work for the linker. I definitely don't want D to become C++. What is smartlinking? This is intended for stuff like code that generates strings for mixins.
Re: @ctfeonly
On Thursday, December 07, 2017 02:09:56 lobo via Digitalmars-d wrote: > On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson > > wrote: > > I'd like to add an attribute to indicate that the annotated > > function is only available at compile time so that in cases > > where the operation is invalid at runtime (strings and > > concatenation on a GPU for instance) but the result is only > > used at compile time (for a mixin) the compiler is free to not > > codegen that function. > > > > I can add this to LDC pretty easily, but does anyone else have > > a use for this (e.g. shrinking binary sizes for mixin heavy > > codebases) and would benefit having this as a standard thing? > > Shouldn't the linker do this already? > > Once the compiler has CTFE'd the function any call in the code > should be replaced with the function evaluation. The linker > should then drop the code out of the binary because it really is > dead code. As I understand it, if you're statically linking it should, but it can't with dynamic linking - at least not right now. With the export improvements that Martin Nowak and Benjamin Thaut want to do (where IIUC, export would then be required for anything in a shared library to be accessible outside it), then it would be possible, but right now, everything gets exported (at least on all systems other than Windows), so none of it can be stripped out as unused, since the linker doesn't know what's actually going to be used. Executables should be in the same boat as static libraries though. Also, I think that in some cases, stuff like ModuleInfo ends up referring to stuff and keeping it around even though it isn't necessarily really used, but I'm not sure. Folks have talked about all kinds of template code and stuff being kept around in binaries even though it was only used at compile time (e.g. stuff like isInputRange), but I don't know how much that's actually true. Personally, I don't care much about binary sizes. I certainly agree that having unused symbols stripped out where possible is a good thing, but AFAIK, it doesn't really matter for most of the stuff I do, and having a binary be 5MiB instead of 1MiB doesn't matter much to me, much as I agree that having the binary smaller is good. It just isn't usually enough disk space or memory to matter much in practice. Clearly, some people care quite a bit about that sort of thing, but I don't know how much it actually matters in practice unless you're doing something with embedded systems. Regardless, needing something like an attribute to tell the compiler to strip stuff out of the binary seems like a hack to me. It may actually be necessary in some cases, but it just feels like it should be unnecessary. - Jonathan M Davis
Re: @ctfeonly
H. S. Teoh wrote: On Thu, Dec 07, 2017 at 01:21:11AM +, Nicholas Wilson via Digitalmars-d wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? I'd like to have this too. Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctfeonly annotation that tells the compiler not to codegen the (many instantiations of the) function would be greatly welcomed. T this is a hack for something that really should be done in linker, automatically. please, people, let's not turn D into C++! ;-) i mean: this has a short-time benefits, but makes the language more complex, less clear, and completely destroys any incentive to make smartlinking work as intended in case it is broken.
Re: @ctfeonly
On Thursday, 7 December 2017 at 01:21:11 UTC, Nicholas Wilson wrote: I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing? Shouldn't the linker do this already? Once the compiler has CTFE'd the function any call in the code should be replaced with the function evaluation. The linker should then drop the code out of the binary because it really is dead code. bye, lobo
Re: @ctfeonly
On Thu, Dec 07, 2017 at 01:21:11AM +, Nicholas Wilson via Digitalmars-d wrote: > I'd like to add an attribute to indicate that the annotated function > is only available at compile time so that in cases where the operation > is invalid at runtime (strings and concatenation on a GPU for > instance) but the result is only used at compile time (for a mixin) > the compiler is free to not codegen that function. > > I can add this to LDC pretty easily, but does anyone else have a use > for this (e.g. shrinking binary sizes for mixin heavy codebases) and > would benefit having this as a standard thing? I'd like to have this too. Some of my template-heavy code use a good number of CTFE-only functions that are only called at compile-time. Since they are nested inside the template, they do quickly add up to a lot of dead code in the executable. Having a @ctfeonly annotation that tells the compiler not to codegen the (many instantiations of the) function would be greatly welcomed. T -- Let's eat some disquits while we format the biskettes.
function for inverse relative path?
what would be a robust way to do this `inverseRelativePath`, and should that be in std.path? ``` auto a="/a/b/c.d"; auto b="b/c.d"; assert(inverseRelativePath(a, b) == "/a"); assertThrown(inverseRelativePath(a, "c2.d")); ```
@ctfeonly
I'd like to add an attribute to indicate that the annotated function is only available at compile time so that in cases where the operation is invalid at runtime (strings and concatenation on a GPU for instance) but the result is only used at compile time (for a mixin) the compiler is free to not codegen that function. I can add this to LDC pretty easily, but does anyone else have a use for this (e.g. shrinking binary sizes for mixin heavy codebases) and would benefit having this as a standard thing?
Re: Inheritance from multiple interfaces with the same method name
On Wednesday, 6 December 2017 at 23:56:33 UTC, Q. Schroll wrote:
What is D's position on that? The interface spec [2] does not
say anything about that case.
It seems it's allowed, but the caller is required to disambiguate.
import std.stdio;
interface I { void f(); }
interface J { int f(); }
class A : I, J
{
void f() { writeln("void f()"); }
int f() { writeln("int f()"); return 0; }
}
void main()
{
A a = new A();
// Error: A.f called with argument types () matches both:
A.f() and A.f()
// Yeah, that error message could be better.
//a.f();
(cast(I)a).f(); // prints "void f()"
(cast(J)a).f(); // prints "int f()"
}
https://run.dlang.io/is/lZSblC
Mike
Re: Inheritance from multiple interfaces with the same method name
On Wednesday, 6 December 2017 at 23:56:33 UTC, Q. Schroll wrote:
Say I have two interfaces
interface I { void f(); }
and
interface J { int f(); }
implemented by some class
class A : I, J {
// challenge by the compiler:
// implement f()!
}
VB.NET allows that by renaming the implementation (it does
allow it generally, not only in the corner case).
C# allows that by specifying the target interface when
implementing (can be omitted for exactly one; corner case
handling); the specification makes the implementation private.
(See [1])
Java just disallows the case when two methods are incompatible.
If they are compatible, they must be implemented by the same
method. If they are meant to do different things, you are
screwed.
What is D's position on that? The interface spec [2] does not
say anything about that case.
[1]
https://stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
[2] https://dlang.org/spec/interface.html
Delphi resolves this with below syntax; I think it's clean and
simple
Pham
class A : I, J
{
// Define function for each interface
void I_f() {}
int J_f() {}
// Assign function to interface
I.f = I_f;
J.f = J_f;
}
Inheritance from multiple interfaces with the same method name
Say I have two interfaces
interface I { void f(); }
and
interface J { int f(); }
implemented by some class
class A : I, J {
// challenge by the compiler:
// implement f()!
}
VB.NET allows that by renaming the implementation (it does allow
it generally, not only in the corner case).
C# allows that by specifying the target interface when
implementing (can be omitted for exactly one; corner case
handling); the specification makes the implementation private.
(See [1])
Java just disallows the case when two methods are incompatible.
If they are compatible, they must be implemented by the same
method. If they are meant to do different things, you are screwed.
What is D's position on that? The interface spec [2] does not say
anything about that case.
[1]
https://stackoverflow.com/questions/2371178/inheritance-from-multiple-interfaces-with-the-same-method-name
[2] https://dlang.org/spec/interface.html
Re: Adding Markdown to Ddoc
On 12/6/2017 5:24 AM, Adrian Matoga wrote: This is going to be the right time to deprecate the automatic change of some words that happen to be parameter names into code. :) Let's please keep that as a completely separate discussion, as the issue is orthogonal.
Re: Adding Markdown to Ddoc
On Wed, Dec 06, 2017 at 02:42:49PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 12/06/2017 01:14 PM, H. S. Teoh wrote: > > This "feature" has been the source of countless Phobos and dlang.org > > bugs, leading to time-wasting churn of changing `someword` into > > `_someword`, just to suppress the automatic change. > > Isn't that controlled via a macro? We should just redefine the macro > to return its argument unchanged. -- Andrei Yes, the macro is DDOC_PARAM. However, this macro is emitted from two places in ddmd/doc.d: one in highlightText(), where we'd like to suppress it, and the other in highlightCode(), where we WANT the highlighting. Ergo, there is no way to selectively disable it only in running text without also killing any highlighting it may have had in code snippets, where it is wanted. Perhaps a possible workaround is to use a shim in highlightText(), say, instead of using DDOC_PARAM, have it emit DDOC_PARAM_IN_TEXT, the latter of which passes its argument to DDOC_PARAM. Then to selectively disable it, we simply redefine DDOC_PARAM_IN_TEXT to return the parameter unchanged. (And highlightCode() will continue to emit DDOC_PARAM directly, so the highlighting will still work in code snippets.) This fancy dance seems completely redundant, though. If we wanted to highlight the parameter in running text, we can already use the new backtick syntax `paramName`. There's really no added value in introducing yet another default macro DDOC_PARAM_IN_TEXT with a default definition that, most of the time, people don't even want anyway. T -- They pretend to pay us, and we pretend to work. -- Russian saying
Re: Adding Markdown to Ddoc
On 12/06/2017 01:14 PM, H. S. Teoh wrote: This "feature" has been the source of countless Phobos and dlang.org bugs, leading to time-wasting churn of changing `someword` into `_someword`, just to suppress the automatic change. Isn't that controlled via a macro? We should just redefine the macro to return its argument unchanged. -- Andrei
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 17:17:40 UTC, Luís Marques wrote: Is there a small druntime/object.d implementation that allows basic support for classes, without bringing the whole druntime implementation with it? https://bitbucket.org/timosi/minlibd This is mainly targeted to microcontrollers which do not have any operating system. If this is not suitable for you, at least there are lists of needed files and required changes. It might be possible to reduce this further but I have not yet had need for that. Feel free to ask more info if you are interested.
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 17:52:16 UTC, Eugene Wissner wrote: http://arsdnet.net/dcode/minimal.zip ? I tried that one, but I was having trouble getting it to work (it seems to have bit rotten), and it does much more than I need, which probably is adding to the work to fix it.
Re: Adding Markdown to Ddoc
On Wed, Dec 06, 2017 at 10:32:38AM -0500, Steven Schveighoffer via Digitalmars-d wrote: > On 12/6/17 8:24 AM, Adrian Matoga wrote: > > On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote: > > > On 12/5/2017 8:11 PM, Walter Bright wrote: > > > > (I know this has come up before, and I've been opposed to it, > > > > but I've changed my mind.) > > > > > > Part of this change of mind was driven by the bit of markdown that > > > Ddoc already supports - the backticks to quote code and auto > > > detection of URLs - and how nice that has turned out. > > > > This is going to be the right time to deprecate the automatic change of > > some words that happen to be parameter names into code. :) > > Yes, please! [...] +1000! This "feature" has been the source of countless Phobos and dlang.org bugs, leading to time-wasting churn of changing `someword` into `_someword`, just to suppress the automatic change. The underscore proliferation makes the source code quite unreadable if your module happens to be unfortunate enough to have many symbols that coincide with actual words. It even happens inside URL macros used extensively in Phobos, meaning that you have to mangle your URLs just so DDoc doesn't destroy them by inserting "helpful" macro syntax, but that has the unfortunate side-effect of making DDoc URLs non-copy-pasteable when editing the source code. In short, the "helpful" automatic changing of words into code has turned out to be a total disaster in practice. For every instance where it's actually helpful, there are 99 instances where it's a nuisance. It's time to admit that it was a bad design, and kill it with fire and extreme prejudice. T -- Без труда не выловишь и рыбку из пруда.
Re: minimal object.d implementation that allows classes
On Wednesday, 6 December 2017 at 17:17:40 UTC, Luís Marques wrote: Is there a small druntime/object.d implementation that allows basic support for classes, without bringing the whole druntime implementation with it? http://arsdnet.net/dcode/minimal.zip ?
minimal object.d implementation that allows classes
Is there a small druntime/object.d implementation that allows basic support for classes, without bringing the whole druntime implementation with it?
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 15:08:53 UTC, David Gileadi wrote: On 12/6/17 6:41 AM, Nemanja Boric wrote: On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) These are great news. We are using harbored-mod (https://github.com/dlang-community/harbored-mod) which does this for quite some time, but it feels like a second-class citizen compared to the ddoc. Speaking of that tool, I suspect Ddoc's Markdown support will have to do the same as harboured-mod does with respect to the bits of Markdown syntax that are already claimed by Ddoc [1] [1] https://github.com/dlang-community/harbored-mod#differences-from-vanilla-markdown The markdown lib used in harbored-mod comes from vibe-d (renamed as dmarkdown), so it will likely automatically be the case, see this part of the discussion: https://forum.dlang.org/post/p08kpm$oag$1...@digitalmars.com
Re: (Possibly paid opportunity): PyD - Win 64
On Saturday, 2 December 2017 at 09:12:07 UTC, Thomas Mader wrote: On Friday, 1 December 2017 at 13:30:21 UTC, Laeeth Isharc wrote: Hi. I'd like to get PyD working on Windows 64. I think it's probably just a simple linking / library problem, but don't have time to work on it myself right now. If somebody would be interested in helping, we could pay for help on this. laeeth at kaleidic.io Thanks. Laeeth. Just found https://github.com/ariovistus/pyd/issues/67 https://github.com/ariovistus/pyd/pull/72
Re: Adding Markdown to Ddoc
On 12/6/17 8:24 AM, Adrian Matoga wrote: On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote: On 12/5/2017 8:11 PM, Walter Bright wrote: (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Part of this change of mind was driven by the bit of markdown that Ddoc already supports - the backticks to quote code and auto detection of URLs - and how nice that has turned out. This is going to be the right time to deprecate the automatic change of some words that happen to be parameter names into code. :) Yes, please! -Steve
Re: Adding Markdown to Ddoc
On 12/6/17 6:41 AM, Nemanja Boric wrote: On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) These are great news. We are using harbored-mod (https://github.com/dlang-community/harbored-mod) which does this for quite some time, but it feels like a second-class citizen compared to the ddoc. Speaking of that tool, I suspect Ddoc's Markdown support will have to do the same as harboured-mod does with respect to the bits of Markdown syntax that are already claimed by Ddoc [1] [1] https://github.com/dlang-community/harbored-mod#differences-from-vanilla-markdown
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 04:11:33 UTC, Walter Bright wrote: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) These are great news. We are using harbored-mod (https://github.com/dlang-community/harbored-mod) which does this for quite some time, but it feels like a second-class citizen compared to the ddoc.
Re: Adding Markdown to Ddoc
On Wednesday, 6 December 2017 at 12:13:56 UTC, Walter Bright wrote: On 12/5/2017 8:11 PM, Walter Bright wrote: (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Part of this change of mind was driven by the bit of markdown that Ddoc already supports - the backticks to quote code and auto detection of URLs - and how nice that has turned out. This is going to be the right time to deprecate the automatic change of some words that happen to be parameter names into code. :)
Re: Adding Markdown to Ddoc
On 12/6/2017 3:37 AM, Sönke Ludwig wrote: No problem! Now, just need someone to step up and do the work. :-/
Re: Adding Markdown to Ddoc
On 12/5/2017 8:11 PM, Walter Bright wrote: (I know this has come up before, and I've been opposed to it, but I've changed my mind.) Part of this change of mind was driven by the bit of markdown that Ddoc already supports - the backticks to quote code and auto detection of URLs - and how nice that has turned out.
Re: Adding Markdown to Ddoc
Am 06.12.2017 um 12:34 schrieb Walter Bright: On 12/6/2017 1:33 AM, Sönke Ludwig wrote: This is great news! While I don't have the time to work on this directly, I can offer vibe.d's Markdown module* (re-licensing as necessary): https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d Markdown is a strange thing to parse in the classical way due to its original regex-cascade style of implementation/design, so it was kind of difficult to find representations that allow reasonably efficient and comprehensible processing. * There is also "dmarkdown", which is just a fork of the vibe.d code Thanks! It's always great to be able to leverage existing code. But you'll need to Boost license it! No problem!
Re: Adding Markdown to Ddoc
On 12/6/2017 1:33 AM, Sönke Ludwig wrote: This is great news! While I don't have the time to work on this directly, I can offer vibe.d's Markdown module* (re-licensing as necessary): https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d Markdown is a strange thing to parse in the classical way due to its original regex-cascade style of implementation/design, so it was kind of difficult to find representations that allow reasonably efficient and comprehensible processing. * There is also "dmarkdown", which is just a fork of the vibe.d code Thanks! It's always great to be able to leverage existing code. But you'll need to Boost license it!
Re: Adding Markdown to Ddoc
Am 06.12.2017 um 05:11 schrieb Walter Bright: https://help.github.com/articles/basic-writing-and-formatting-syntax/ Anyone interested in picking up the flag? (I know this has come up before, and I've been opposed to it, but I've changed my mind.) This is great news! While I don't have the time to work on this directly, I can offer vibe.d's Markdown module* (re-licensing as necessary): https://github.com/vibe-d/vibe.d/blob/master/textfilter/vibe/textfilter/markdown.d Markdown is a strange thing to parse in the classical way due to its original regex-cascade style of implementation/design, so it was kind of difficult to find representations that allow reasonably efficient and comprehensible processing. * There is also "dmarkdown", which is just a fork of the vibe.d code
